Source: https://guthlabs.ai/docs/project-templates/incident-response/qualification/ project template / candidate # Incident response โ€” qualification The distinct qualification record for Incident response. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:incident-response **Parent lifecycle**: candidate **Page lane**: qualification **Lane lifecycle**: proposed **Owner**: Not separately recorded **Owner role**: Not separately recorded **Owner status**: Not separately recorded **Qualification result**: NOT RUN ยท held for evidence and human review **Working browser surface:** [Project templates & workflows โ€” overview]() โ€” Create a local project from this template and validate its forms. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held. ## Qualification status **Result**: NOT RUN **Disposition**: HELD **Reviewer**: Not recorded **Receipt**: Not recorded This page defines proposed acceptance criteria for the qualification lane. It does not execute tests, establish compliance, qualify the subject, or authorize an effect. ### Lane-specific instrument aids No verified instrument is assigned to this qualification lane. ## Outcome definitions **Verified**: All stated evidence and acceptance requirements passed for the exact reviewed revision; this still does not authorize deployment or an external effect. **Failed**: One or more deterministic acceptance requirements failed with an inspectable reason. **Needs review**: Evidence or interpretation is incomplete, conflicting, or awaits an identified human reviewer. **Held**: Authority, required evidence, safe execution conditions, or a principal gate is absent. The current record remains NOT RUN / HELD. These definitions describe candidate outcomes only. ## Proposed deterministic acceptance tests Route-resolution and distinct-content checks apply only to the admitted canonical routes in this record. Held source-proposed extensions are non-resolving proposals and are excluded. - Blank required identity, owner, severity, detection source, and authority acknowledgement fields block save and identify each field programmatically. - Invalid severity, visibility, lifecycle, decision state, completion state, or closure state is rejected deterministically. - Whitespace-only text is rejected; bounded text fields enforce declared length limits and preserve entered content without silent truncation. - A target recovery deadline before detectedAt is rejected with an inline, programmatically associated error. - A dueAt without timezone, with an invalid date-time, or outside the declared project schedule is rejected. - A dependency cycle, missing dependency, or completion attempt before dependency completion is rejected and leaves prior state unchanged. - Changing any deadline, owner, severity, scope, or decision creates a new revision and preserves the prior revision and source provenance. - Reloading or navigating away after a failed save does not discard unsaved values without a warning; retry does not duplicate records. - Keyboard-only users can reach every field, dependency control, approval action, revision control, and destructive action in logical order. - Every validation error is announced to assistive technology, linked to its field, not conveyed by color alone, and remains visible until corrected. - Focus moves to the first invalid field after failed submission; status and success messages use an appropriate live region. - The form has visible labels, sufficient contrast, no required field identified by color alone, and usable zoom/reflow without loss of controls. - Destructive actions such as delete, discard revision, remove evidence reference, or close incident require explicit confirmation naming the target and consequence. - Canceling a destructive confirmation makes no mutation; confirming records actor, timestamp, target ID, and resulting lifecycle or deletion state. - A user without recorded authority cannot approve containment, mark recovery verified, close the project, or authorize external send. - Provider, credential, database, customer, publication, and external-send effects remain held; attempted effects show a clear held state and preserve the local draft. - If a referenced record, attachment, or source locator is missing, inaccessible, or hash-mismatched, the project enters Held or Needs review and does not claim evidence completeness. - If saving fails, show a retryable error, retain form values locally for the session, avoid duplicate records, and provide a non-destructive recovery path. - If a deadline conflict is detected, show the conflicting items and require a human choice; do not auto-move deadlines or write to a provider. - Closure is rejected when required recovery evidence, residual-risk disposition, follow-up owner, or retrospective record is missing. - Search and visibility tests confirm private or held records are not exposed through broader indexed views without the declared visibility permission. ## Negative and held-state tests - False closure caused by marking tasks complete without dependency or evidence checks. - Exposure of incident details, personal data, credentials, or sensitive evidence through notes, search, messages, or indexed views. - Destructive deletion or revision replacement without confirmation and an auditable receipt. - Unauthorized containment, recovery, approval, closure, or external communication. - Silent deadline shifts, recurrence, provider writes, or customer-facing effects. - Evidence loss, altered provenance, missing hashes, broken links, or duplicate records after retry. - Accessibility failures that prevent keyboard, screen-reader, zoom, contrast, or error recovery use. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - This is a proposed project template for coordinating incident-response records. - The template can specify local records, deadlines, dependencies, approvals, evidence references, revisions, and held actions. - The observed Notebook contract includes project collections, to-do deadline fields, record provenance and revisions, and a PointGuard context surface. ### Still held - deployment or production qualification - provider, credential, database, customer, or publication connection - external calendar writes or message sends - complete evidence custody or incident containment - security, regulatory, legal, or operational compliance - qualification of any live incident ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:incident-response` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Notebook records provenance and revisions` - `PointGuard persistent cross-app context surface` - `/app/notebook/projects/` - `/app/notebook/to-dos/` - `/app/notebook/agenda/` - `/app/notebook/approvals/` - `/app/notebook/messages/` - `/app/notebook/files/`