February 2026. Part of an ongoing series on aviation risk methodology.
In the previous exciting instalment, I promised we'd get to the flapping of the butterfly's wings in the Amazon and why Root Cause analysis is in itself a systemic risk. I appreciate your patience. If you've been holding your breath since the last update you're probably no longer in a fit state to appreciate the torrent of wisdom about to be released. However, if you've taken a more pragmatic path then prepare to be surprised by risk industry heresy.
And so here we are. The butterfly has been flapping distractedly in the Amazon, and Root Cause Analysis — that beloved pillar of nearly every 'thinking firmly inside the box' safety management system, investigation report, and corporate post-mortem — is about to meet some actual risk reduction causality.
The Butterfly in the Amazon
In 1961, the mathematician and meteorologist (at least one, an honest pursuit) Edward Lorenz was running a numerical weather simulation on a Royal McBee LGP-30 computer (a machine with roughly the same processing power as a modern greeting card). He re-entered an intermediate value from a previous run, but due to numeric truncation in the printout it was rounded from 0.506127 to 0.506. The result was a completely divergent forecast and completely different weather pattern.
From this observation, Lorenz developed what became known as sensitive dependence on initial conditions — the idea that in complex, nonlinear systems, infinitesimally small differences in starting conditions can produce vastly different outcomes. It was later popularised as the Butterfly Effect: the notion that a butterfly flapping its wings in the Amazon could, through an extraordinarily long chain of atmospheric causation, contribute to a tornado in Texas.
Whether or not the butterfly is actually culpable for the tornado is debatable. What is not debatable is the implication for anyone attempting to trace a chain of causation backwards through a complex system to find the one thing that 'caused' an event. The chain doesn't end. It never ends. You can always go one step further back.
The Problem with 'Root'
The word Root in Root Cause Analysis carries a dangerous implication: that there exists a single, fundamental, bottom-of-the-tree cause from which the entire sequence of failure grew. Find the root, treat the root, and the problem is solved. It is a satisfying concept. It is also, in any system of meaningful complexity, unhinged fiction.
Consider a hypothetical aircraft incident. An engine fails on takeoff. The investigation reveals that a turbine blade fractured due to a fatigue crack that had been growing for several hundred cycles. The crack was not detected at the last shop visit because the inspection method used was inadequate for that failure mode. The inadequate inspection method was specified in a maintenance programme that hadn't been updated to reflect a revised Service Bulletin. The Service Bulletin update wasn't incorporated because the engineering team was understaffed following a budget reduction. The budget reduction was a consequence of a commercial downturn. The commercial downturn was precipitated by a pandemic. The pandemic originated from — well, let's not go there.
So what was the Root Cause? The turbine blade? The inspection method? The maintenance programme? The staffing decision? The budget cut? The pandemic? A bat in a cave?
The answer, inevitably, is whichever link in the chain best serves the purposes of whoever is writing the report. And that is precisely the problem.
The Politics of Root Selection
In practice, the selection of a 'root cause' is often less an exercise in engineering rigour than an exercise in organisational politics. The root cause selected tends to be the one that is:
- Sufficiently far removed from senior management to avoid uncomfortable accountability.
- Sufficiently specific to allow a corrective action to be written.
- Sufficiently plausible to satisfy the regulator.
Notice that none of these criteria include 'most likely to prevent recurrence.' This is not because investigators are incompetent or dishonest — most are neither. It is because the framework itself demands a single root, and a single root is almost always a simplification of reality to the point of unrecognisable distortion.
In aviation, James Reason's Swiss Cheese Model made excellent progress in moving us away from single-cause thinking by illustrating how accidents typically result from the alignment of multiple failures across multiple barriers. And yet, even in organisations that teach the Swiss Cheese Model in their human factors courses, the investigation report still concludes with a box labelled Root Cause. The cognitive dissonance is astonishing (Gell-Mann amnesia anyone?).
A More Productive Question
If the chain of causation tends towards infinite length and the selection of a 'root' is inherently arbitrary, what should we do instead? Abandon investigation altogether? Obviously not.
I'd argue that the far more productive approach is to stop asking 'what was the root cause?' and start asking 'where were the missed intervention opportunities, and why didn't they work?'
In any incident or mishap, there are typically multiple points along the causal chain where an existing control, process, or human decision should have interrupted the sequence but didn't. These are the missed interventions. They are not hypothetical — they are often places where the organisation had already identified a risk and had already put some mitigation in place. And yet the event occurred regardless.
Understanding why the intervention didn't work or didn't occur is vastly more useful than arguing about which link in the chain deserves the label 'root cause.' It shifts the focus from blame to learning. It respects the complexity of the system rather than pretending it doesn't exist. And critically, it produces corrective actions that address real systemic weaknesses rather than whichever convenient cause happened to land in the human-controlled crosshairs.
Returning to our hypothetical engine failure: instead of arguing about whether the root cause was the turbine blade, the inspection method, or the staffing decision (or chiropteran vichyssoise for that matter), the missed intervention approach might ask:
- The maintenance programme should have incorporated the revised Service Bulletin. Why didn't it? What was the process for tracking SB revisions, and where did it break down?
- The shop visit inspection should have detected the fatigue crack. Why didn't it? Was the technique inappropriate, or was it applied incorrectly, or was the crack genuinely undetectable at that stage?
- The engineering staffing reduction presumably went through some form of risk assessment or management review. Did anyone flag the downstream impact on maintenance programme efficacy? If not, why not? If so, what happened to that flag and its mitigation?
- Were there adequate intervention opportunities, or do we need to redesign for increased systemic resilience/robustness?
Each of these questions leads to a specific, actionable improvement. None of them requires the fiction of a single root cause, a single thing to blame. All of them treat the organisation as the complex system that it actually is. And all lead to increased organisation resilience when appropriately addressed.
Root Cause Analysis as Systemic Risk
Here's the uncomfortable conclusion. An organisation that relies on Root Cause Analysis as its primary investigative methodology is, paradoxically, introducing a systemic risk into its own safety management system. By demanding a single root for every event, it systematically oversimplifies complex failures, misdirects corrective actions, and — perhaps worst of all — provides false assurance that the problem has been 'fixed' when in reality only one arbitrary link in a much longer chain has been addressed. Denial is not just a river in Egypt!
The butterfly doesn't care that you've identified a root cause. It's still flapping.
In complex systems, the honest answer to 'what caused this?' is almost always 'many things, interacting in ways that were difficult to predict.' The useful question is not 'which one thing do we blame?' but 'which of our existing defences failed, and how do we make the whole system more resilient?'
Lorenz demonstrated rounding three decimal places in a complex computation caused unexpected and divergent outcomes. Root Cause Analysis attempts something even more lofty: it tries to explain the weather by pointing at a single cloud and saying 'It's definitely that one!'.