Common Mode Failure Analysis¶
Identify shared dependencies that could cause supposedly independent backups or safeguards to fail together.
The Diagnostic Story¶
Symptom: The system has redundancy built in — multiple backups, alternative paths, separate vendors, parallel safeguards — but when a real failure arrives, several of them disappear at once. The resilience plan listed resources but not whether those resources were actually independent. Identical design lineage, shared upstream dependencies, or common training quietly turned many protections into one hidden point of failure.
Pivot: Make independence assumptions explicit, map shared dependencies across redundant elements, identify which failure modes could defeat multiple paths simultaneously, rate correlated exposure, and then act — through diversity, isolation, hardening, sequencing, monitoring, or explicit residual-risk governance.
Resolution: Redundancy investments become more credible because the independence claims behind them have been tested. Surprising correlated failures decrease and diversification priorities become visible. Residual shared risk is governed explicitly rather than discovered in a crisis.
Reach for this when you hear…¶
[data center operations] “We have two power feeds but they come out of the same transformer — that is not redundancy, that is the same failure in two colors.”
[aviation safety] “All three flight computers came from the same production batch with the same firmware defect — the redundancy was real on paper but not in the failure mode.”
[financial risk] “We thought we were diversified across six counterparties until the credit event hit and it turned out four of them had the same underlying exposure.”
When This Archetype Applies¶
Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.
Diagnostic problem
A system relies on multiple components, backups, suppliers, channels, teams, safeguards, or pathways as if they were independent, but they may share a cause that can make them fail at the same time.
What this problem means
The structural problem is that **nominal redundancy can hide a single point of failure**. A system may have many apparent backups, but those backups can be coupled through a shared dependency. That coupling can be technical, physical, institutional, economic, social, or cognitive.
For example, two data centers may be in different places but rely on the same identity provider. Two suppliers may have different names but source the same subcomponent. Two clinical workflows may appear separate but require the same record system login. Several institutional safeguards may be formally independent but rely on the same budget authority or information pipeline.
The deeper tension is between efficiency and independence. Standard platforms, common vendors, common training, centralized authority, and shared infrastructure make systems easier to manage. They also create the possibility that one cause will defeat many protections at once.
Show the applicability expression
Applicability expression3 distinct conditions
groundedpartly groundedopen
3 conditions, all required.
3Required in every casenumbered 1–3
These hold no matter which pattern applies.
Redundant safety claim · grounded
Functionally equivalent redundant components or paths are used to support a safety or continuity claim.
The source archetype describes the situation as follows: Redundancy is being used as a safety or continuity claim. The normalized requirement above isolates the load-bearing portion used in this condition set.
Assumed failure independence · open
Failure independence among redundant paths is assumed rather than demonstrated.
The source archetype describes the situation as follows: Independence is assumed rather than demonstrated. The normalized requirement above isolates the load-bearing portion used in this condition set.
Shared-cause redundancy failure · open
One shared dependency or cause can defeat several nominally independent paths at once.
The source archetype describes the situation as follows: A shared cause could defeat several paths at once. The normalized requirement above isolates the load-bearing portion used in this condition set.
Other requirements and context (2)
Why these sit outside the expression
Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.
Solution feasibility — it describes whether the intervention can work, not whether the diagnostic problem exists.
Supporting contextConsequences of correlated failure are high.
Use this archetype when a system says, in effect, “we have a backup,” “we have two suppliers,” “we have multiple channels,” “we have separate safeguards,” or “we have redundant controls,” and the consequences of simultaneous failure would matter. In this archetype, the relevant contextual consideration is: Consequences of correlated failure are high. It helps interpret the situation or strengthens the practical case for examining the archetype.
Solution feasibilityDiversification, isolation, or explicit risk acceptance is possible.
Coverage
1 of 3 conditions grounded · 2 open.
Mechanisms / Implementations¶
- Common-Cause FMEA: Extends failure mode and effects analysis by asking which single causes could defeat multiple redundant elements or controls at once.
- Fault Tree with Common-Cause Branching: Decomposes a top-level failure through logic gates to its basic causes, then adds shared-cause branches so a single event feeding several 'independent' paths becomes visible.
- Dependency Mapping Workshop: A dependency mapping workshop brings together people who see different parts of the system.
- Backup Independence Test: Exercises backup paths under a shared dependency outage or simulated common cause to verify whether they are genuinely independent.
- Supply-Chain Dependency Review: Traces whether alternate suppliers, logistics routes, components, or raw materials share sub-tier vendors, regions, infrastructure, labor constraints, or regulatory chokepoints.
- Diverse Vendor Review: Assesses whether vendor diversity is real across ownership, infrastructure, code lineage, hosting, support, credentials, and failure response capability.
- Correlated Risk Register: Records shared exposures, affected redundant paths, severity, mitigation owner, test evidence, and residual risk acceptance.
- Tabletop Cascade Exercise: Simulates a shared failure cause and asks how redundant paths, teams, authorities, and recovery plans respond when they are stressed together.
- Credential and Infrastructure Dependency Audit: Checks whether backup systems, emergency roles, and alternate channels still depend on the same identity provider, network, power source, cloud region, or access authority.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Coupling: Interdependence among subsystems.
- Functional Redundancy (Degeneracy): Multiple pathways fulfill same function.
- Redundancy: Duplicate critical components.
Also references 9 related abstractions
- Boundary: Defines system limits.
- Failure Mode and Effects Analysis (FMEA): Identify failure modes.
- Fault Tolerance: Continue operating under failure.
- Observability: Infer internal state externally.
- Relation: Describes associations or dependencies.
- Resilience: Absorb shocks and adapt.
- Risk Aversion: Preference for certainty.
- Robustness: Maintain functionality under stress.
- Uncertainty: Incomplete knowledge.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Common-Cause Failure Analysis · risk or failure variant · recognized
A causal form of common-mode review that asks which single cause could defeat multiple redundant paths or safeguards.
Backup Independence Analysis · implementation variant · recognized
A backup-focused variant that tests whether alternate capacity, suppliers, records, channels, or roles remain available under the same stress that disables the primary path.
Shared Dependency Review · implementation variant · candidate
A dependency-centered review that looks for upstream resources, controls, or conditions shared by multiple protections.
Correlated Risk Analysis · risk or failure variant · candidate
A quantitative or portfolio-style variant that analyzes whether risks assumed to offset or diversify one another actually fail together under stress.
Editorial Notes¶
Problem Classification¶
Classification: Fragility, Failure & Continuity Risk → Dependency Concentration & Common-Mode Loss
Problem kernel: nominally independent safeguards share one failure cause
Rationale: Backups, suppliers, channels, or teams can fail together because common upstream dependencies invalidate the assumed redundancy.
Independent corroboration: The earliest necessary condition in the frozen evidence is: A system relies on multiple components, backups, suppliers, channels, teams, safeguards, or pathways as if they were independent, but they may share a cause that can make them fail at the same time. That is a dependency concentration and common mode loss problem because Nominally plural providers, paths, backups, or pooled exposures share enough concentration or correlation that one cause can remove them together.
Review outcome: Independent reviewer agreement; high confidence.