A brilliant investigation and a perfunctory one converge on the same three weak fixes. The analysis explains the last failure. Only the tracker, and the engineering it forces, gets a vote on the next one.
In 2017, a team of patient-safety researchers led by Kathryn Kellogg published a study in BMJ Quality & Safety with a title that asks the question this essay is about: “Our current approach to root cause analysis: is it contributing to our failure to improve patient safety?” They had reviewed 302 root cause analyses conducted over eight years at a major academic medical center. A root cause analysis is medicine's post-mortem: a serious adverse event happens, a team convenes, and a structured investigation produces a documented account of what went wrong and why.
Here is the number to sit with: “In 106 RCAs, solutions were proposed.”
One hundred six. Out of 302. Roughly two-thirds of these completed investigations, each triggered by a real patient coming to real harm, each conducted in full by people who cared, produced no proposed fix at all. The analysis ran to completion. The document was filed. The recommendation section, where the future was supposed to change, was empty.
And when solutions were proposed, look at what they were. Of 731 proposed solutions across the studies that had them, the most common types were “training (20%), process change (19.6%) and policy reinforcement (15.2%).” More than half of all proposed remedies fell into those three categories: teach people harder, adjust the procedure, remind everyone of the rule. The authors' conclusion was that the most frequently recommended solutions were weaker interventions, less likely to prevent recurrence. And the recurrence came: “Multiple event types were repeated in the study period, despite repeated RCAs.” The same classes of harm, happening again, at an institution that had already investigated them. Sometimes more than once.
A companion paper the same year, by Mohammad Farhad Peerally and colleagues, cataloged the structural problems with root cause analysis as practiced and gave the phenomenon a name better than any I could coin: “organisational forgetting.” Not the absence of analysis. Analysis, followed by forgetting, followed by the same event, followed by more analysis. The institution remembers everything in its documents and nothing in its systems.
If you build software, you have felt the shape of this. The two-hour incident review with the timeline accurate to the second. The five-whys that actually goes five levels down. The beautifully written document, bookmarked in three channels, linked from the onboarding wiki. And the bug, or its sibling, back in production within the quarter. The title of this essay is the feeling. But the title makes a claim, an inverse correlation between analysis quality and fix likelihood, that I should be honest about up front, because the evidence supports something more precise and more useful.
Nobody has measured, as far as I can find, that better post-mortems produce worse follow-through. What the patient-safety literature documents is decoupling: the quality of the analysis and the strength of the remedy vary independently, and the remedy distribution is pulled hard toward weak interventions no matter how good the analysis was. A brilliant investigation and a perfunctory one converge on the same three outputs: training, process tweak, policy reminder. A better post-mortem does not buy you a better fix. It buys you a better document.
There is a plausible psychological mechanism for why thoroughness might even work against follow-through, and it deserves its one paragraph, labeled as hypothesis. Organizational responses to failure do double duty: they repair systems, and they discharge anxiety. Rituals demonstrably reduce the response to failure; there is experimental work showing structured ritual lowers anxiety and even the neural response to performance errors. An incident review has ritual structure: prescribed sequence, assigned roles, formal vocabulary, a defined end. When the analysis is fully satisfying, when every thread is tied off, the anxiety that was driving the work resolves. The organizational need was for a response, and the excellent document is the response. But treat that as a candidate explanation, not a finding. The structural explanation below needs no psychology at all, which is exactly what makes it useful.
Sort remedies the way safety engineering sorts them and the pattern stops looking like a mystery or a moral failure. Occupational safety's standard ranking of hazard controls puts elimination and physical engineering changes at the top, and puts training, procedures, and policy, the administrative tier, fourth out of five, because they depend on human behavior at the moment of hazard. This connection between the RCA findings and the control hierarchy is my synthesis rather than either literature's claim, but once stated it is hard to unsee: training, process change, and policy reinforcement, the three commonest RCA outputs at 55% of all proposed solutions, are all administrative controls. The completed investigations were overwhelmingly recommending interventions from the weakest tier that recommends anything.
Why would smart, motivated investigators converge on weak remedies? Because of what an investigation is. Its deliverable is a document, and a document's native outputs are words: instructions, procedures, reminders, lessons. A report can tell people to be careful. It cannot install an interlock, separate a development environment from production, add a hard constraint to a database, or remove a hazardous step from existence. Those stronger remedies require a budget holder, an engineering change, an owner with authority over the system, none of which is summoned by the act of analysis. The strength of the remedy is capped by the form of the artifact. However good the thinking, a document emits instruction, and instruction is the control class that decades of safety engineering rank just above hoping.
This is why the failure survives good intentions. Nobody in the room is cynical. The investigators investigate honestly, the writers write carefully, and the artifact they hand back is structurally capable of carrying only the weakest class of fix. The medical field's own corrective, a framework literally named RCA² (“RCA squared: RCA plus action”), exists because the field recognized that the action half was the missing half. When a discipline has to rename its core practice to smuggle the word “action” into it, the diagnosis has been accepted.
If the story ended there, the conclusion would be that post-incident investigation is theater, and that conclusion is refutable, because one industry runs investigations that famously do change systems.
The National Transportation Safety Board investigates aviation accidents and issues safety recommendations. Here is what makes it the perfect test case: the NTSB has no power whatsoever to force implementation. It carries, at any given time, more than a thousand open, unimplemented recommendations. By the logic above it should be the purest documentation theater in government. Instead, per Government Accountability Office reporting, roughly 78% of its safety recommendations were implemented over a five-year window (a figure as of 2011; date it accordingly). Set that against the RCA baseline, where only about 35% of investigations even proposed something. The comparison is illustrative rather than controlled, different hazard rates, different regimes, different denominators, but the gap is not subtle.
What does aviation have that hospital RCA lacks? Not smarter analysts, and not enforcement power. Four structural features: the investigator is independent, not an arm of the organization being investigated; the findings and recommendations live in a public docket; every recommendation has tracked status, including an explicit classification for “unacceptable action” by the recipient; and external actors, Congress, the press, post-accident hearings, consult that status and apply pressure. A rejected NTSB recommendation does not vanish into a wiki. It sits in public, labeled unacceptable, waiting to be read aloud at the hearing after the next crash.
Which yields the reframe this whole essay has been walking toward, offered as my synthesis of the two literatures: the post-mortem was never the control. The tracker is. An investigation closes the loop only when something outside the investigated team watches whether the remedy landed, and has standing to make noise when it does not. The analysis produces knowledge. The tracker produces consequences for inaction. They are different machines, and organizations that run only the first one get organisational forgetting at industrial scale.
Software's own canon quietly agrees, and it is worth noticing where the emphasis falls when you reread it with this lens. Google's SRE book, the document that taught the industry blameless post-mortems, spends its real energy on machinery: every action item gets an owner and a due date, completion is tracked in a system separate from the document, follow-up reviews are scheduled before the meeting ends, delays escalate to someone with standing to care. If the organization that wrote the book on post-mortem culture needs explicit anti-forgetting machinery bolted onto the culture, the machinery, not the culture, is doing the work. And note what blamelessness actually solved: honesty. In the blameful old regime, the binding constraint on learning was that people hid what happened. Blameless review fixed that, brilliantly, and left implementation untouched, because it was never aimed at implementation. We solved the input problem and declared victory on the output problem.
The practical move is a self-audit that takes one afternoon and stings in a useful way. Pull your last ten post-mortems and score two things.
First, the Kellogg question: what fraction proposed any concrete remedy at all? The medical baseline to beat is about one-third. You will likely beat it; most engineering post-mortems do produce action items. Then the harder cut: classify each action item by control strength. “Add a warning to the runbook,” “remind the team in standup,” “update the onboarding doc”: administrative, the 55% tier, words instructing future humans to behave differently under stress. “Add a lint rule that blocks the deploy,” “split the credentials,” “make the dangerous operation require a second key”: engineering controls, changes to what the system permits. Count honestly. The ratio is your organization's true post-mortem output, and for most teams it is heavily administrative, for exactly the structural reason above: the meeting that produces the document cannot spend money or merge code.
One structural note on why the tracker must be a separate system, rather than a better section of the same document or a longer version of the same meeting. The review meeting is doing knowledge work: reconstructing, explaining, teaching. Commitment work runs on a different clock with different participants; it needs the budget-holder who was not in the room, the prioritization fight against next quarter's roadmap, and a check-in cadence measured in weeks rather than one cathartic afternoon. Asking the same ninety minutes to do both jobs reliably produces the document and starves the commitment, because the document completes inside the meeting and the commitment, by its nature, cannot. Split them on purpose. Analysis closes when the document publishes. The incident closes when the tracker says the system changed.
Then fix the loop, not the documents. Three moves, in increasing order of courage. Give every action item an owner and a date, and track completion in a system that is not the post-mortem doc itself; the doc is where action items go to be remembered fondly. Second, report the completion rate somewhere visible and slightly uncomfortable, a dashboard, a monthly review, anywhere outside the team that wrote the items; you are building a small NTSB docket, and the visibility is the mechanism. Third, adopt a one-line rule for the review itself: every incident's action list must contain at least one non-administrative item, one change to what the system permits rather than what people are told, or must state explicitly why none is possible. That last rule is the RCA² insight compressed: force the conversation about control strength while the budget-holders are still in the room.
None of this makes the beautiful document less valuable. Write the great post-mortem; it transfers knowledge, and knowledge compounds. Just stop asking it to do a job documents cannot do. The analysis explains the last failure. Only the tracker, and the engineering it forces, gets a vote on the next one.
The post-mortem was never the control. The tracker is.
The same split applies to an AI agent's decisions: the reasoning is the document, and a document forgets. What closes the loop is a durable, tamper-evident record of what the agent actually did and decided, kept in a system separate from the agent, that an outside party can read and check the status of. That is what Chain of Consciousness is: not a prettier write-up of the agent's intent, but the tracked, inspectable trail of its actual actions and their outcomes, the NTSB docket for your agents rather than the wiki page nobody re-reads. Analysis produces knowledge; the record produces consequences for inaction.
See Hosted Chain of Consciousness · Read the Theory of Agent Trust
pip install chain-of-consciousness · npm install chain-of-consciousness
Or the whole trust stack at once: pip install agent-trust-stack / npm install agent-trust-stack