Common-Mode Failure
Redundancy only buys reliability in proportion to the independence of the redundant parts. A common-mode (or common-cause) failure is one that defeats multiple redundant components simultaneously because they share a hidden dependency — a shared flaw, environment, input, or assumption. Nominal redundancy with correlated failure is a false sense of security: the system has N components and effectively fewer than N chances to survive.
The canonical experiment: Knight & Leveson (1986)
N-version programming — the software analog of redundant hardware — proposes building N independent implementations of the same specification, running them in parallel, and voting on the outputs. The scheme’s reliability math depends entirely on one axiom: independently developed programs fail independently. Knight (UVA) and Leveson (UCI) tested the axiom directly: 27 program versions written independently by graduate/senior students at two universities from one (sanitized aerospace anti-missile) specification, each acceptance-tested, then all subjected to one million randomly generated test cases against a trusted oracle.1
Results: the programs were individually excellent — 6 of 27 never failed; 23 of 27 were correct on >99.9% of cases. But they did not fail independently. There were 551 test cases where exactly two programs failed together; one input class defeated eight programs at once (twice). The independence hypothesis was rejected at α = 0.01 (z = 100.55) — an overwhelming statistical margin.2
Why do independent developers produce correlated bugs? Because they share everything except their independence: the same specification (with its ambiguous or counterintuitive corners), the same training and cultural toolkit, the same problem “hard spots.” Faults cluster where the problem is hard, not where the programmer is careless. (The seminar summary notes the sly corollary: if common errors came from the students being amateurs, that too would prove faults aren’t independent.)3
The general shape
- Hardware: redundant power supplies sharing one circuit; triple-redundant flight computers running the same software build (hence Airbus/Boeing use dissimilar redundancy — different processors, different code, sometimes different laws of control).
- Software: N-version voting, recovery blocks, and microservice “redundancy” where all replicas share one upstream database, one DNS provider, one TLS CA.
- Infrastructure markets: fallback API providers that are secretly the same provider — aggregators fronting one upstream. See llm-inference-provider-landscape for the LLM-inference instance, where “primary + fallback” can both be raccoons in the same trench coat.
- Epistemics: a room of independent analysts who read the same sources converges on the same blind spot — the filter-bubble as a common-mode failure of attention, and scientific-idea-diffusion-decline as the field-scale version (homogenized training → correlated research agendas).
Design consequences
- Count dependencies, not components. The reliability question is never “how many fallbacks?” but “what single thing kills all of them?”
- Diversity is the only real lever. Independent implementations, independent vendors, independent model families, independent physical paths — each removes a shared-cause class.
- Correlated failure is the default, not the exception. Knight & Leveson is the standing empirical warning: even deliberately independent construction correlates. Assume correlation; design against it explicitly.
- Test the independence, not just the redundancy. A failover you haven’t exercised against a shared-cause scenario is a hypothesis.
Sources
- Knight & Leveson (1986) — KTH course seminar summary — KTH course-hosted seminar summary of Knight & Leveson, “An Experimental Evaluation of the Assumption of Independence in Multiversion Programming,” IEEE Trans. Software Engineering SE-12(1):96–109, 1986 (IEEE original paywalled; abstract + design + results reproduced)