Turn an Incident Into a Blameless System Fix

A postmortem that ends with one person promising to be more careful has not changed the system. The next similar incident will find the same opening.

This guide belongs to reel R095. Comment POSTMORTEM for the matching module and runnable starter.

Define the boundary before building

Input: incident events, alerts, logs, customer impact, responder notes, deployed changes, contributing conditions, and current owners.

Output: a sourced timeline, impact statement, contributing conditions, detection gaps, corrective actions, owners, due dates, and verification plan.

The starter keeps exact checks in code and gives Claude only the reviewable drafting work. Dry-run is the default. Live mode can call Anthropic's Messages API, but it still returns a draft and performs no external action.

Paste this boundary into Claude Code before asking for implementation:

Workflow: Turn an Incident Into a Blameless System Fix
Input: incident events, alerts, logs, customer impact, responder notes, deployed changes, contributing conditions, and current owners
Output: a sourced timeline, impact statement, contributing conditions, detection gaps, corrective actions, owners, due dates, and verification plan

Map the trigger, strict input fields, deterministic code checks, Claude drafting step, approval gate, failure queue, and saved evidence. Use null for missing facts. Do not change code or call an external service yet.

The modules that matter

Build the timeline first

Use alerts, logs, deploy records, tickets, and responder notes. Record timestamps and source links. Keep interpretation out until the sequence is agreed.

Describe contributing conditions

Separate trigger, impact path, detection gap, response friction, and recovery. Name decisions and constraints without turning one human into the root cause.

Close actions with proof

Every action needs an owner, due date, failure step it addresses, and verification method. Prefer tests, limits, automation, and observability over reminders.

Rules worth keeping beside the code

Build the timeline from evidence before writing causes.
Describe conditions and decisions without assigning personal blame.
Give every corrective action an owner and verification method.
Prefer controls that change the system over reminders to be careful.

The dangerous version is inventing a root cause, exposing private customer data, naming a person as the failure, or closing actions without testing the original failure path. The pack deliberately stops at a draft so a person can inspect those boundaries before enabling anything real.

Test the ugly paths

Timeline entries have sources.
Customer impact has a measured window.
Each action maps to a failure step.
The original path is replayed safely.
Closed actions include verification evidence.

The final verification is concrete: Replay the failure safely, confirm each corrective action blocks or detects a specific step, and review the timeline with the responders.

Use this prompt to turn the evidence into acceptance tests:

Design tests for Turn an Incident Into a Blameless System Fix using only the attached fictional fixtures.
Cover the normal path, missing input, malformed input, a repeated event, a permission failure, a dependency failure, and the named safety boundary.
For each test return: input, expected state, prohibited side effect, and evidence to save.
Do not execute external actions.

Run the pack locally

The ZIP is a complete Node 22 starter with no third-party npm dependency. It includes an importable n8n webhook, Docker Compose, GitHub Actions validation and manual-run workflows, deterministic samples, and tests.

npm test
npm run validate
npm run sample
cp .env.example .env
docker compose up --build

Only set WORKFLOW_MODE=live, ANTHROPIC_API_KEY, and ANTHROPIC_MODEL after the dry-run output and tests make sense for your system. Keep real secrets in the environment, never in the n8n export.

Download the runnable pack

Start with the fictional dry-run. It validates the input and returns a reviewable draft without changing code, production data, customer accounts, or an external service.

Before enabling a real action

Replace every fictional fixture, assign the approval owner, define the duplicate key, set a timeout and retry rule, and save the original evidence. Then test one failure on purpose. If the workflow cannot stop visibly and replay safely, it is not ready to act.