Skip to content

Post-Incident Recurrence Review

Post-incident review — instantiates Eventual-Occurrence Containment Design

After an occurrence actually happens, makes affected parties whole and traces the shared root cause so the same event cannot recur the same way.

Every other mechanism here acts before the event or during it; Post-Incident Recurrence Review is the one that acts after. Once the inevitable occurrence has actually happened, it does two things nothing else does: it makes the affected parties whole — notifying them, remedying the harm, meeting the obligations the event created — and it traces the occurrence back to the shared cause that let it through, so the fix removes a whole class of future occurrences rather than patching the single instance. Its defining stance is that one occurrence is a sample of a population: the point is not to close the ticket but to ensure this exact failure, and its siblings, cannot recur.

Example

A packaged-food manufacturer discovers that a batch of product reached shelves carrying an undeclared allergen. The occurrence is real and already out in the world, so the review's first job is the affected parties: issue the recall, notify retailers and consumers, and remedy the harm (refunds, and medical-cost coverage where owed). Its second job is recurrence. Rather than stopping at "this batch was mislabelled," the review traces the common cause and finds that a single shared labelling template feeds three production lines — so the same defect could surface on any of them at any time.

The durable fix therefore targets the template and the verification step around it, protecting all three lines at once, and the review closes only when that fix is verified in place, not when the recall ends. One occurrence has been converted into the removal of a shared failure path — which is the only kind of fix that lowers the odds of the next occurrence rather than just cleaning up this one.

How it works

  • Trigger on a real occurrence, not a hypothetical — this review is retrospective by definition and fires once the event has happened.
  • Discharge obligations to those affected first: notify, remedy, and meet legal or contractual duties on the clock the event started.
  • Trace to the common cause, not the proximate one: ask what shared dependency, template, component, or process let this through, and where else it is present.
  • Convert the finding into a durable, verified change that removes the class of occurrence — and hold the review open until that change is confirmed, not merely assigned.

Tuning parameters

  • Blame stance — blameless (focused on the system that permitted the event) versus individual accountability. Blameless reviews surface far more honest causal detail; the trade is a perception of leniency.
  • Root-cause depth — stop at the proximate fault, or push to the shared common-mode cause. Deeper analysis removes whole classes of recurrence but costs time and can over-generalise from one event.
  • Remedy generosity — the threshold for notifying and compensating affected parties. Broader remedy rebuilds trust and lowers liability but costs more and can over-notify.
  • Action-item enforcement — whether findings are advisory or gate future operation until closed. Enforced closure prevents "filed and forgotten," at the cost of flexibility.
  • Scope of "recurrence" — just this failure, or the family of failures sharing its cause. Wider scope prevents more but risks boiling the ocean.

When it helps, and when it misleads

Its strength is that it is the archetype's learning loop and its conscience: it honours the duty to the people the occurrence harmed, and it turns a single bad event into a permanent reduction in future events by attacking the shared cause rather than the instance. Done well, each occurrence makes the next one less likely.

Its failure modes are cultural. A review run to assign blame drives the causal truth underground and teaches people to hide the next event; a review that produces a tidy document and a list of action items nobody closes is theatre that changes nothing. The classic misuse is shaping the narrative to exonerate — writing the review to justify the decisions already made rather than to find what actually let the event through. The discipline that guards against all three is the blameless postmortem[^blameless]: separate the person from the system, insist on the common cause, and treat an action item as open until the change is verified — measuring the review by recurrences prevented, not reports filed.

How it implements the components

  • affected_party_notification_and_remedy — the review owns the after-the-fact duty to those harmed: notifying them, remedying the harm, and meeting the obligations the occurrence created.
  • common_mode_dependency_check — its analytical core: tracing the occurrence to the shared cause and finding everywhere else that cause is present, so the fix removes a class of recurrence.

It acts only after the fact. Detecting the occurrence is Sentinel Event Monitoring's; proving the recovery worked is Recovery Drill and Restore Test's; and modelling the residual risk before anything happens is Probabilistic Safety Assessment's.

Notes

The common-mode check here and the one inside Probabilistic Safety Assessment look alike but run in opposite directions: PSA hunts shared causes prospectively, from a model, before any event; this review finds them forensically, from a real occurrence that already exposed one. The forensic find is often the very input that corrects the prospective model.

References

The blameless postmortem — an incident-review discipline (widely used in site-reliability engineering and aviation safety) that examines the system and conditions that allowed a failure rather than punishing the individuals nearest to it, on the premise that blame suppresses the information needed to prevent recurrence.