Correlated Versus Independent Failure: The Central Distinction
This lesson is the conceptual spine of the whole course, so we will slow down and make it explicit, because nearly every large infrastructure failure you will ever investigate turns on getting this one distinction right, and nearly every organization gets it wrong in the same direction.
Two failures are independent when the occurrence of one tells you nothing about the likelihood of the other. Two failures are correlated when they share a cause, so that one happening makes the other more likely — or, in the worst case, makes it certain. The entire mathematics of redundancy and reserve margin rests on independence. When failures are independent, probabilities multiply, and multiplication of small numbers produces reassuringly tiny risks. Provide two independent backups each with a one-in-a-thousand chance of failing, and the chance of both failing is one in a million. This is why redundancy works, and it genuinely does work, against independent failures.
Correlation breaks the multiplication. If a single common cause can fail both backups, then the chance of both failing is not one in a million; it is simply the chance of that common cause occurring, which might be one in fifty. Your reliability did not improve by a factor of a thousand when you added the second backup. It barely improved at all, because you defended against the wrong kind of failure. You bought insurance against a risk that was never the real threat, and the accounting told you that you were safe.
Everything in the previous modules is an instance of this one principle. The cold snap that fails a quarter of the generating fleet at once is a common cause overriding the assumed independence of individual plant outages. The heat wave that derates generation, transmission, and transformers simultaneously is a common cause. The flood that drowns both redundant generators in one basement is a common cause. In every case, planners built defenses sized for independent failures and were defeated by correlation, and in every case the defeat looked, from inside the organization, like extraordinarily bad luck — a thousand-year event, a perfect storm, a confluence nobody could have foreseen. It was none of those things. It was a common cause that the model had assumed away.
Why do organizations make this error so reliably? Partly because independence is mathematically convenient and correlation is not — modeling correlated failure requires you to enumerate common causes, estimate their frequency, and trace their reach through the system, which is hard, tedious work with no clean answer. Partly because the components of a redundant system are often bought, maintained, and audited separately, so no single person ever sees that the two generators share a basement, or that three plants share a pipeline, or that the primary and backup cooling both depend on the same river. And partly because correlation is invisible on ordinary days. The common cause has not fired, so the system looks robust, the redundancy tests pass, and the false confidence compounds year over year until the day the common cause arrives and collects everything at once.
The practitioner's method for defeating this is disciplined and can be stated as a habit. For any system you rely on for reliability, do not ask 'how many backups do I have.' Ask 'what single event could disable my primary and my backup together.' Enumerate the shared dependencies: shared power source, shared fuel supply, shared cooling, shared physical location, shared control system, shared network, shared vendor, shared weather exposure. Each shared dependency is a common cause, and each common cause converts your independent redundancy back into a single point of failure. The number of backups is nearly irrelevant; the number of shared common causes is everything. A system with five backups and one shared common cause is, against that cause, a system with one backup.
This reframing changes what 'resilience' means. Resilience is not the quantity of redundancy. It is the absence of shared common causes among your redundant elements. Two modest, genuinely independent systems will outperform five elaborate, secretly coupled ones every time the coupling is triggered — and the coupling is always triggered eventually, because common causes are exactly the large, rare, correlated events that infrastructure exists to survive.
Faraday's read: redundancy counts boxes; resilience counts common causes. If you only ever learn one thing from this course, learn to look at any pair of backups and immediately ask what they secretly share — because whatever they share is the thing that will take them both, on the same afternoon, for the same reason, while your reliability spreadsheet insists it cannot happen.