Source: https://guthlabs.ai/docs/project-templates/incident-response/forms/ project template / candidate # Incident response โ€” forms The distinct forms 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**: forms **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. ## Proposed form sections Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth. ### Incident intake Create a bounded incident record with enough context to triage without asserting production state. - incident title - reported by - reporting channel - reportedAt - first observedAt - incident category - severity proposal - affected service or area - current symptoms - known trigger or change - initial customer or internal impact statement - privacy or security sensitivity flag - immediate safety concern flag - source record links - intake owner - intake notes ### Scope and impact Document confirmed, suspected, and unknown boundaries separately. - scope status: confirmed, suspected, or unknown - affected systems or records - affected audience stated without customer indexing - geographic or environment boundary - start and end time estimates with timezone - impact dimensions - known exclusions - evidence supporting scope - assumptions - next scope-check owner - scope review deadline ### Milestones Define ordered response outcomes and accountable owners. - milestone ID - milestone name - milestone purpose - entry criteria - exit criteria - owner - backup owner - planned start - planned finish - actual finish - status - linked dependencies - linked evidence - approval required - approval record link ### Deadlines and workback Turn response obligations into explicit due items and a reviewable schedule. - deadline ID - deadline type - dueAt with timezone - priority - recurrenceCandidate - completion state - responsible owner - reviewer - workback start - workback tasks - late-handling rule - linked milestone - conflict notes - schedule source - revision note ### Dependencies and handoffs Expose blockers, prerequisites, and cross-owner handoffs. - dependency ID - dependent milestone or task - prerequisite - dependency owner - request date - needed by - status - blocking level - handoff instructions - fallback path - evidence of completion - escalation owner - escalation deadline ### Owners and authority Make record ownership and decision authority explicit. - project owner - incident coordinator - technical lead - evidence custodian - communications drafter - approval owner - recovery owner - retrospective owner - backup assignments - decision authority notes - access limitations - human-review boundary ### Response workback Provide an ordered plan from target recovery or review time backward. - target time - timezone - workback anchor - task sequence - task duration estimate - task owner - predecessor task - latest start - latest finish - buffer - completion evidence - replan trigger - replan approver ### Tools and guides Record only named local surfaces, skills, guides, records, or providers and their intended use. - tool or guide name - kind - route or record reference - intended use - canonical owner - input required - output or receipt expected - authority limitation - fallback if unavailable - human review required ### Evidence and custody Preserve source-labelled references without implying protected upload or external storage. - evidence ID - description - evidence type - source locator - source SHA-256 if available - capturedAt with timezone - captured by - canonical record link - attachment or local file reference - revision - provenance - visibility - custody state - integrity check - retention or deletion instruction - evidence review status ### Approvals and decisions Capture proposed decisions and receipts before consequential action. - approval ID - proposal - decision options - decision owner - risk summary - supporting evidence - requestedAt - decision deadline - status: Needs review, Approved, or Held - decisionAt - approver - decision rationale - conditions - receipt or revision link - external effect held confirmation ### Risks and failure states Track uncertainty, response hazards, and what happens when work cannot proceed. - risk ID - risk statement - risk category - likelihood - impact - severity - early signal - mitigation - contingency - risk owner - review date - residual risk - blocker flag - failure state - safe stop instruction - escalation path ### Closure and retrospective Close only when evidence, approvals, unresolved risks, and follow-up work are recorded. - closure proposal - closure owner - service or scope status - recovery evidence - monitoring or observation window - unresolved issues - accepted residual risks - follow-up tasks - follow-up owners - follow-up dueAt values - retrospective date - participants - what worked - what failed - corrective actions - approval record - closure decision - closedAt - closure revision ### Accessible state contract - Every field requires a visible and programmatic label. - Required and optional fields must be stated in text. - Invalid entries require an actionable message linked to the field. - Blocked and Held states remain visible without relying on color alone. ## Supporting documentation fields These fields come from the app_features lane and remain separate from the primary operating form. ### Incident identity Establish the project owner, scope, and current state. - incident title - incident identifier - owner - backup owner - severity - status - detectedAt - last updated - affected service or area - short description ### Detection and assessment Capture the initial signal and bounded assessment without asserting unverified facts. - detection source - detection note - known symptoms - affected scope - confidence label - initial impact note - linked source records ### Response plan Create ordered work for detection, containment, evidence, recovery, and review. - response phase - task title - task owner - priority - dueAt - dependency - completion state - review required - tags - notes ### Evidence and provenance Link source-labelled material and preserve custody information. - file or record reference - source locator - source SHA-256 when available - capturedAt - provenance note - attachment metadata - visibility - linked phase ### Communication and approvals Prepare human-reviewed communication and decisions while holding final sends or writes. - audience or recipient - draft message - source context - approval state - reviewer - decision note - proposed send time ### Retrospective Record outcomes, unresolved questions, and follow-up work. - resolution summary - contributing factors - what worked - what failed - follow-up task - owner - dueAt - retrospective status - linked evidence ## Required or proposed record references No record existence is asserted by this documentation page. - project record - incident intake record - scope and impact record - milestone records - deadline and workback to-dos - dependency records - owner assignments - evidence references - approval records - risk records - closure and retrospective record - project record with canonical ID, lifecycle, owner, severity, status, timestamps, links, and revision history - incident timeline notes with source labels and provenance - containment, recovery, and retrospective to-dos with dueAt and priority - source-labelled file references for logs, screenshots, scans, or reports - draft messages and approval records for proposed external communication or decisions - Agent log records for any bounded assistance or generated proposal ## 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` - `project:incident-response` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Notebook records canonical IDs, origin, source locators, source SHA-256, provenance, revision, lifecycle, tags, links, attachments, and record revisions` - `PointGuard persistent cross-app context surface` - `APP_ROUTES:/app/notebook/projects/` - `APP_ROUTES:/app/notebook/to-dos/` - `APP_ROUTES:/app/notebook/agenda/` - `APP_ROUTES:/app/notebook/files/` - `APP_ROUTES:/app/notebook/approvals/` - `APP_ROUTES:/app/notebook/messages/` - `APP_ROUTES:/app/notebook/agent-logs/` - `APP_ROUTES:/app/pointguard/` - `Notebook records provenance and revision contract`