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. Two tabs carry the point of the surface. 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 the fourth time the same failure wakes somebody at night it has stopped being an incident and become a cause, and a written record of it is what stops the fifth time 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 recurs is recorded as a cause rather than written up a fifth time from scratch
• 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 high contrast and 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. Only six semantic tones exist, one is overridable per workspace, and nothing here styles for high contrast, so a hue on its own could not carry meaning.

1. 1Open Incident reviews and read the review debt in the header first.
2. 2Write the review for an incident: a factual timeline, the impact in numbers, and the contributing factors rather than one cause.
3. 3Turn the preventive actions into real tasks, each with an owner and a date.
4. 4Check Follow-up owed regularly. It is where a review stops being a document and becomes work.
5. 5When a failure recurs, record it under Known causes 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 with an owner and a date, 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 has recurred. At that point writing another incident review teaches nobody anything, and what is needed is a record of the cause itself.