Incident Review Without the Blame

When to use it

Something went wrong: a wrong price live for a day, a payroll run with errors, an email to the wrong list, a delivery missed, a system down. It is over, or contained, and someone has to write it up for the people who decide what changes. The user has the raw material: the chat thread, the emails, the ticket, their own notes. One incident in, one review out, in one sitting.

Not for an incident still running (that needs a holding note and a fix, not a review) and not for a plan that has not started yet; the Project Pre-Mortem Move does that. Not a disciplinary document. If the aim is to decide what happens to a person, say so and stop: that is a different document with different rules.

What it asks you

Ask for everything in one numbered message.

1. What happened, in one line, and what the customer or the business saw.
2. The raw material: the chat thread, emails, ticket notes, alerts. Paste it with the timestamps if you have them. Times matter more than tidiness.
3. If the thread does not show them: when it started, when someone noticed, when it was contained, when it was fully fixed.
4. Who was involved, by role. Names are optional; the review uses roles.
5. What should have happened: the process, checklist or standard that applies, if there is one. "There isn't one" is a useful answer.
6. The impact figures you have: orders, customers, money, hours. Only what you can show.
7. Who reads the review, and what they will decide with it.

Work from what comes back. A time the user does not have is written as "not known" in the timeline and listed as a gap; it is never estimated. An impact figure the user does not have is "not measured". Never fill a gap with a plausible guess, and never name a person as a cause.

What comes back

Plain text. Headings in capitals.

INCIDENT One line: what happened, when, what the customer or business saw.

SUMMARY FOR THE READER Three lines: the trigger, the condition that mattered most, the first action and its date.

IMPACT The user's figures only. "Not measured" where none.

TIMELINE Time, what happened, source. The four marks labelled.

DURATIONS Detection, containment, recovery, total, each with its two times.

TRIGGER One event, one sentence.

CONDITIONS Numbered, each tagged start, spread, detection or fix, each one sentence about the system.

WHAT WORKED One or two lines.

ACTIONS One row per condition: action, condition number, owner, date, done when.

GAPS Times not known, figures not measured, questions only someone in the room can answer.

Next: one line naming the single most useful next step.

• 00_START_HERE.pdf: the two-minute set-up for each AI.
• 1 - Skill: incident-review-without-blame.zip, one upload to Claude, ChatGPT, Gemini, Grok or Microsoft 365 Copilot. It switches on by itself when this job comes up.
• 2 - Text file for any AI: the same Move as one .txt. Attach it to any chat, on any plan, and type "Follow this file".

It drafts, you read and send. It never contacts anyone for you and never invents a fact, a number or proof.

A Move is a single play. The whole function in a box is an agent pack.