Incident reviews

Incident reviews holds the blameless write-up of an incident and, more importantly, what changed because of it. The header states review debt before anything else, because nobody notices an unwritten review until an auditor does. Tabs separate reviews in progress, published reviews, follow-up owed, known causes and every review together, and the page opens on Follow-up owed when any action is past due. Follow-up owed gathers overdue actions from every review in one place, because a review is only worth writing if something changes as a result of it. Known causes exists because a failure that wakes somebody a second time has stopped being an incident and become a cause, and a written record of it, with a workaround, is what stops the next occurrence starting from nothing.

• Review debt in the header, so unwritten reviews are visible without scrolling to count them
• Follow-up owed: every overdue action across every review in one list, rather than buried inside each one
• Known causes, so a failure that keeps recurring is recorded once as a cause, with its workaround, rather than written up from scratch each time
• Action items that can be converted into real tasks, so a review produces work rather than a paragraph
• Status shown as an icon and a word rather than a colour, so the meaning survives colour blindness

• A review is blameless by design. It records contributing factors rather than a person, because a review that finds somebody stops finding anything else.
• Converting an action item creates a real task. From that point it is an ordinary task, tracked with everything else rather than in a document nobody reopens.
• Follow-up owed is deliberately across all reviews. An action overdue inside one review is invisible; the same action in a shared list is not.
• Status never relies on colour alone. Each review stage is shown as an icon and a word, so the meaning does not depend on telling two hues apart.

1. 1Open Incident reviews and read the review debt in the header first.
2. 2Write the review once the incident is resolved or cancelled: a summary, who was affected, how it was noticed, what was done, what was learned, and at least two contributing factors rather than one cause.
3. 3Add action items to the review and give at least one an owner, then convert them into real tasks. A converted task carries the owner and the due date of the item.
4. 4Check Follow-up owed regularly. It is where a review stops being a document and becomes work.
5. 5When a failure keeps coming back, record it under Known causes, with a workaround, so the next occurrence does not start from nothing.

Why is the review blameless?

Because a review that identifies a person stops identifying anything else. The useful question is what made the mistake easy to make, and that question produces fixes that prevent more than one incident.

What happens to an action item I convert?

It becomes a real task that carries the owner and the due date of the item, tracked alongside everything else. Actions left inside a document are the reason incidents repeat.

Why is follow-up in its own tab?

Because an overdue action inside one review is invisible. Gathered across every review, it is the clearest signal that the reviews are not producing change.

What counts as a known cause?

A failure that keeps coming back. Open a cause the second time you see the same failure: at that point writing another incident review teaches nobody anything, and what is needed is a record of the cause itself, with the workaround somebody needs at night.