What Postmortems Get Wrong: Writing a Case File That Actually Helps

Opening Scene

A detective pulls an old case file from the archive, hoping it will help her make sense of a pattern she’s seeing now, and finds three pages of vague summary, a list of names with no clear roles attached, and a conclusion that reads more like a legal disclaimer than an actual account of what happened. The case was, technically, closed. It just wasn’t written up in any way that helps the next detective who needs it. That gap between “closed” and “actually useful to someone later” is where most data ethics postmortems quietly fail too.

In Plain English

A postmortem that genuinely helps future decisions looks different from one written primarily to close a file: it names a specific, falsifiable timeline, states root causes rather than surface symptoms, assigns concrete and trackable action items rather than vague commitments, and gets revisited later to confirm those action items actually happened. Most postmortems fall short on at least one of these, often because they’re written under the same institutional pressure that caused the incident in the first place: the pressure to move on quickly and look competent while doing it.

The Old Way

Before rigorous postmortem practice was widely adopted for data and AI incidents:

• Reports were often written defensively, optimized for legal and reputational protection rather than genuine internal learning.
• There was no standard template or expected depth, so the quality of any given postmortem depended entirely on whoever happened to be assigned to write it.
• Action items, where they existed, were rarely tracked to completion, so a postmortem’s recommendations frequently went nowhere.

Writing a case file specifically to be useful to someone else later, rather than to close the matter now, is exactly the shift this kind of case study argues for.

What’s Changing (and Why AI Is the Reason)

1. Blameless postmortem culture, borrowed from site reliability engineering, is increasingly being adopted for data ethics incidents specifically, separating accountability from public blame.
2. This connects to the root-cause discipline covered earlier in this series, and to the standards this content library’s dedicated data governance frameworks series applies to any organizational documentation meant to outlast the person who wrote it.
3. AI incidents move fast enough, and recur often enough across an industry, that a postmortem written only for internal legal comfort provides far less protective value than one written to genuinely prevent recurrence.

The Metaphor, Fully Extended

The Case File	The Postmortem Concept
A file that reads like a legal disclaimer, not an account	A postmortem written to protect the company, not to inform anyone
A case with no clear timeline anyone else could follow	A report with no clear, falsifiable sequence of events
Recommendations filed and never checked again	Action items assigned and never tracked to completion
The veteran who reopens an old case and finds it actually useful	The team that reads an old postmortem and finds it actually prevents a repeat

Quick Recap

• A genuinely useful postmortem has a clear timeline, real root causes, trackable action items, and gets revisited later.
• Reports written mainly for legal protection often fail every one of those tests even while technically closing the matter.
• Blameless postmortem culture, borrowed from site reliability engineering, is a proven fix worth adopting directly.
• Tracking action items to actual completion is what separates a useful postmortem from a filed one.

Where This Fits in the Series

Article 12 argued for documenting near misses with real rigor; this article argues for writing the postmortems that do get produced with that same rigor, rather than defensive vagueness. Article 14 builds on both, moving from the quality of any single case file to the patterns that only become visible once enough well-written case files exist to compare.