Each safety layer has its own gaps, and an accident needs them all to line up

What it is

The Swiss cheese model describes a system's safety as several independent layers of defense stacked together — training, procedures, interface constraints, oversight, automatic interlocks. Each layer is like a slice of cheese, carrying its own holes of varying size and position. A system stays safe most of the time precisely because the holes in different layers rarely line up on the same path; an accident happens when several layers' holes happen to align along a single trajectory at the same moment, letting a hazard punch through every barrier meant to stop it. The question the model answers isn't "which layer failed" but "why a bad outcome is almost never one link's fault, and is instead a coincidental lineup of several independent weak points at a particular moment."

Why it happens

Layered defense works on the assumption that the holes are independent of one another. One layer's weakness might be transient — a moment of operator fatigue, a delayed maintenance check. Another's might be structural — an untested edge case, a long-standing design flaw that has simply never been exercised. As long as these holes have unrelated causes, the odds of them showing up on the same path at the same time drop sharply as the number of layers grows — this is exactly why stacking defenses beats reinforcing a single point. But the protection quietly breaks down in one specific case, and it does so without anyone noticing: if two or more layers share a common trigger — they all depend on the same person's judgment, run the same piece of code, come from the same vendor — they stop being statistically independent. What looks like "multiple layers" on paper delivers only the protective strength of one, because a single common-cause failure punches through every layer that appeared independent at once.

Studying it

The evidence for this model comes mainly from retrospective analysis of major accident investigations: incident databases in aviation, nuclear power, and healthcare repeatedly show that the large majority of serious events involve the simultaneous failure of more than one independent element, not a single textbook cause. A typical study pulls a set of closed accident reports and tallies the number and type of contributing factors each one names, then compares the proportion of single-factor to multi-factor accidents. Methodological caveat: this kind of tally is inherently bounded by how thorough the underlying investigations were — deeper investigations tend to surface more contributing factors, so the finding that "most accidents are multi-causal" is partly an artifact of investigative depth. It needs to be cross-checked against that depth rather than read directly as a count of how many holes a given system actually has.

Where it stops holding

The model describes layers as independent or not in hindsight — it doesn't let you measure independence beforehand. Whether two defenses share a failure cause usually can only be confirmed after they've failed together; at design time it's rarely possible to enumerate every possible common-cause pathway in advance. The model also assumes the layers are more or less static physical barriers laid out in fixed positions. For systems where roles reorganize dynamically as an event unfolds and people compensate for each other in real time — an experienced team improvising a new division of labor mid-incident — the boundary between "layers" is itself fluid, and describing it with a fixed layer count distorts what's actually happening.

Applying it

When designing a defense system, actively check whether layers share a common failure cause: do they all depend on the same person's judgment at the same moment, run on the same code or the same configuration, draw data from the same external dependency? Any two layers with a shared trigger point should be treated as one layer for the purpose of computing redundancy, not added up at face value. For high-consequence operations, give adjacent layers different detection principles — one relying on manual confirmation, another on an independent sensor reading, a third on automatic system interception — rather than stacking multiple checkpoints of the same kind, which only manufactures a false sense of safety. Verification: list the failure precondition for every defense in the system and draw the dependency graph between them; check whether a single point — one person, one piece of code, one vendor — shows up in the failure precondition of two or more defenses at once. If it does, those layers aren't truly independent redundancy.

Related

• Same group: A10.07.2 the distinction between active failures and latent conditions · A10.07.3 a single layer of protection can't carry high-consequence risk · A10.07.4 the model was built for accident analysis, and using it directly as a design method has limits
• Nearby: A10.06 error-proofing design · A10.14 forcing functions and interlocks · Y7.01 systemic causes
• Search terms: Swiss cheese model · defense in depth · common-mode failure