> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.

# common-mode-failure

> Multiple protections meant to fail independently fail together because they share a dependency, vulnerability, or exposure; one cause crosses the nominal redundancy boundary.

<Badge>agriculture</Badge> <Badge>computer-science</Badge> <Badge>engineering-and-technology</Badge>

# Common-mode failure

## Description

Common-mode failure is the collapse of *nominal independence*. A system has several replicas, backups, or protective layers and therefore appears able to survive the loss of any one. But those protections share something load-bearing — a power supply, physical location, design assumption, genetic trait, specification, operator, or environmental tolerance. One cause reaches that shared feature and disables several protections together.

The diagnostic is not simply “how many backups are there?” but “along which dimensions are their failure domains actually different?” Two servers in one availability zone, three programs derived from one ambiguous specification, and thousands of distinct crop hybrids carrying the same susceptible cytoplasm can each be numerous without being independent. Counting components overstates reliability when the relevant probability is conditioned on their shared exposure.

Reliability literature often distinguishes a *common cause* (the shared initiating condition) from a *common mode* (the correlated way multiple components become unavailable). The catalog keeps the broader, transferable structure under one concept: the reliability case assumes independent protection, while a shared dependency or exposure couples the failures.

## Triggers

**User-initiated:** The user says “we have multiple backups,” “it would take everything failing at once,” or “these were developed independently,” without identifying independent failure domains. Vocabulary cues include “shared dependency,” “same region,” “common cause,” “correlated failures,” and “all the backups failed.”

**Agent-initiated:** The agent sees a reliability argument multiply protection counts while leaving substrate, location, specification, or vulnerability shared. Candidate inference: “What single condition could reach all of these protections, and which proposed backup changes that condition rather than merely adding another copy?”

**Situation-shape signals:** Multiple safety layers colocated below the same flood line; replicas sharing power, identity, deployment, or control planes; organizationally separate reviewers using the same flawed requirement; portfolio or biological diversity whose members share the same underlying exposure.

## Exclusions

* **Only one component fails** — a common-mode failure requires one cause to defeat multiple nominally independent protections or alternatives. An ordinary component failure may reveal weak redundancy, but it is not itself the shared-failure shape.
* **Failures are genuinely independent** — two components can happen to fail near the same time without a shared dependency, exposure, or vulnerability. Temporal coincidence alone does not establish a common mode.
* **Failure propagates sequentially** — in a cascade, one component's failure becomes the next component's cause. Common-mode failure instead has one upstream cause reach several protections through a shared exposure, though the two shapes can co-occur.
* **The components were never meant to provide the same protection** — several affected systems do not constitute defeated redundancy unless they were alternatives or layers protecting a shared function.

## Structure

<img src="https://mintcdn.com/agentconcepts/WXnwdfXcRMGaLeDf/concepts/_assets/common-mode-failure-slots.svg?fit=max&auto=format&n=WXnwdfXcRMGaLeDf&q=85&s=949cb7a5feef66f8cd2d03c019c7db8d" alt="Internal structure of common-mode-failure: a table of its component slots and the concepts that fill them." style={{ width: "100%" }} width="941" height="340" data-path="concepts/_assets/common-mode-failure-slots.svg" />

1. **Protected function** — the property the system must preserve.
2. **Nominally independent protections** — multiple components, replicas, or layers intended to preserve it.
3. **Shared dependency or exposure** — a feature present across those protections.
4. **Common cause** — a condition that reaches the shared feature.
5. **Coupled failure** — the protections become unavailable together, invalidating the assumed reliability multiplication.

## Nearest-neighbor review

`common-mode-failure` is not an alias for [redundancy](/concepts/redundancy): redundancy names the robustness investment, while this concept names the hidden correlation that nullifies it and projects a different action — diversify failure domains rather than add copies. It is not [bulkhead](/concepts/bulkhead), which is the boundary-forming remedy, or [defense-in-depth](/concepts/defense-in-depth), which is the layering strategy. It also differs from [cascade](/concepts/cascade) and [contagion](/concepts/contagion): those move failure from node to node, while a common mode lets one cause reach several nodes through a shared exposure. The new entry therefore fills a repeatedly named exclusion in the existing reliability cluster rather than splitting one of its concepts by vocabulary alone.

## Relationships

<img src="https://mintcdn.com/agentconcepts/WXnwdfXcRMGaLeDf/concepts/_assets/common-mode-failure-neighborhood.svg?fit=max&auto=format&n=WXnwdfXcRMGaLeDf&q=85&s=7f9f1f93832aacd74586453c7798d770" alt="Relationship neighborhood of common-mode-failure: a graph of the concepts it connects to and the concepts it is a part of." style={{ width: "100%" }} width="804" height="957" data-path="concepts/_assets/common-mode-failure-neighborhood.svg" />

* [redundancy](/concepts/redundancy) — common-mode failure is the principal falsifier of a redundancy claim: component count does not buy robustness when failure domains remain coupled.
* [bulkhead](/concepts/bulkhead) — bulkheads deliberately separate failure domains; a common mode is a path that crosses or bypasses those boundaries.
* [cascade](/concepts/cascade) — a cascade passes failure from one element to the next, while a common mode fans one cause into several nominal protections.
* [defense-in-depth](/concepts/defense-in-depth) — depth is real only when successive defensive layers do not inherit the same defeat condition.
* [quietly-load-bearing](/concepts/quietly-load-bearing) — the shared dependency is commonly invisible during normal operation and becomes legible only under the rare disturbance the protections were built to survive.

## Examples

<AccordionGroup>
  <Accordion title="International Atomic Energy Agency. (2015). *The Fukushima Daiichi Accident: Report by the Director General*. STI/PUB/1710. https://www.iaea.org/publications/10962/the-fukushima-daiichi-accident · engineering-and-technology" defaultOpen={true}>
    The IAEA's accident report describes the March 2011 tsunami at Fukushima Daiichi as defeating multiple provisions needed to maintain electrical power. The earthquake caused the loss of off-site power, while inundation caused the loss of emergency diesel generation, switchgear, and much of the direct-current supply. Protections that were redundant at the component level shared a physical exposure: critical equipment was vulnerable to a tsunami beyond the plant's design assumptions. The result was station blackout and the loss of capabilities needed to cool the reactors.

    **Inference**: A reliability diagram that shows several parallel power sources can still describe one physical failure domain. Test redundancy against hazards at the level where they couple — elevation, flood protection, cooling-water access, control plane, or location — rather than treating each component box as an independent probability.
  </Accordion>

  <Accordion title="Knight, J. C., & Leveson, N. G. (1986). &#x22;An experimental evaluation of the assumption of independence in multiversion programming.&#x22; *IEEE Transactions on Software Engineering*, SE-12(1), 96-109. https://doi.org/10.1109/TSE.1986.4310637 · computer-science" defaultOpen={true}>
    Knight and Leveson commissioned 27 independently developed versions of the same program and evaluated them across a large test set. Failures were correlated: some inputs caused multiple versions to fail together more often than an independence model predicted. Separate teams and separate implementations did not guarantee independent failure behavior when every version still solved the same problem from the same specification.

    **Inference**: Organizational independence is not automatically failure-mode independence. When diverse implementations form a safety case, test them on shared edge cases and ambiguous requirements; otherwise the specification or problem representation can remain the common exposure across nominally independent code.
  </Accordion>

  <Accordion title="National Research Council, Committee on Genetic Vulnerability of Major Crops. (1972). *Genetic Vulnerability of Major Crops*. National Academy of Sciences. https://doi.org/10.17226/27600 · agriculture" defaultOpen={true}>
    The National Research Council's post-epidemic study traced the severity of the 1970 southern corn leaf blight to genetic uniformity across the U.S. crop. Many outwardly distinct commercial hybrids carried Texas male-sterile cytoplasm because it simplified hybrid-seed production. That shared cytoplasmic trait also carried susceptibility to Race T of the blight pathogen, so a single biological threat reached a large fraction of nominally diverse plantings through the same inherited exposure.

    **Inference**: Diversity must be measured on the dimension the hazard attacks. Different product names, lineages, or surface phenotypes do not provide resilience when the population shares the same load-bearing genetic, technical, or institutional substrate.
  </Accordion>
</AccordionGroup>
