A tool built to explain accidents after the fact strains when used to design defenses upfront

What it is

The Swiss cheese model is a retrospective explanatory tool: it excels at taking an accident that has already happened and unpacking it into a coincidental stack of failures across several layers, helping investigators understand why this particular event wasn't caught. It is not a prospective design method — the model itself never tells a designer how many layers a new system needs, where to put them, or how thick each one should be. Translating the model directly into a design checklist — "we already have three layers, that matches the cheese model, so we're safe enough" — misreads what the model is for. This boundary deserves its own treatment, because it decides what role the model should actually play in a design process, rather than being treated as a compliance box to tick.

Why it happens

The boundary traces back to where the model's evidence comes from. The cheese model was generalized from a large body of retrospective narratives about accidents that had already occurred — the accident happens first, and investigators work backward to find which layers failed and how the holes lined up, then draw that trajectory as a diagram. That kind of narrative can always be constructed after the fact, because any outcome can be traced back to some chain of contributing factors. But the reverse doesn't hold: the model provides no method for a designer to predict, before an accident, which layers of a new system will develop holes or whether those holes will ever align. It gives no quantitative relationship between the number of layers and the resulting risk reduction, and no criterion for judging whether two layers are truly independent — and those are exactly the questions a design phase most needs answered. Using a model that can only narrate after the fact, and cannot predict beforehand, to guide design decisions breeds false confidence: a team ends up feeling safe because it has drawn three layers on a diagram, without ever verifying whether those three layers share a failure cause or actually cover the kinds of holes the system will really produce.

Studying it

Safety science has leveled a clear critique at this boundary: scholars in the tradition of Erik Hollnagel argue the cheese model offers a linear, static picture of stacked failures that struggles to capture how components in a complex system adjust to one another in real time and stretch or compress their performance with circumstance. That critique gave rise to alternative frameworks such as the Functional Resonance Analysis Method (FRAM), built specifically to handle the question the cheese model can't answer: how a system drifts into failure through ordinary variability rather than through a lined-up set of discrete holes. The methodological takeaway: if the goal is to explain an accident that has already happened, the cheese model and its narrative structure are the right tool; if the goal is to predict or generate what safeguard configuration a new system needs, the work has to shift to methods that actually output layer counts, independence criteria, or failure probabilities — fault tree analysis, failure mode and effects analysis — because the cheese model itself produces none of these.

Where it stops holding

Even used purely as an after-the-fact analytic tool, the cheese model depends on a narrative the investigator reconstructs after the outcome is known, which makes it vulnerable to hindsight bias — once the result is known, almost any step can be redescribed as a layer that could have caught the failure but didn't. That leaves the number of layers and the placement of holes considerably more subjective than the diagram suggests; different investigators reviewing the same accident can draw different pictures of it. Used as a design method, that subjectivity is amplified further: with no accident outcome to anchor against, how many layers are needed and where they go rests entirely on the designer's imagination, with nothing to verify it against.

Applying it

Confine the model's use to two situations: reviewing an error or accident that has already happened, where it works as a framework for organizational narrative and communication, helping a team see that this wasn't one person's fault but several layers of defense failing at once; and during design review, as a qualitative sanity check — if this layer were bypassed, is there another layer behind it that would actually catch it — rather than as a way to decide exactly how many layers to build or what each one's technical spec should be. Real design-phase decisions should switch to methods that produce concrete criteria: run a fault tree or failure mode and effects analysis on high-consequence operations, enumerate the possible failure paths and their probabilities, and decide the number and independence of safeguards from that. Verification: check any place in a design review record where the phrase "consistent with the Swiss cheese model" appears, and see whether it's backed by an actual failure-path analysis and an independence argument. If a few layers sketched on a diagram is all that closes out the safety conclusion, the model is being asked to play a role it can't actually fill.

Related

• Same group: A10.07.1 layered defenses and hole alignment · 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
• Nearby: A10.16 accident investigation and error reporting · A10.06 error-proofing design
• Search terms: Swiss cheese model limitations · FRAM · hindsight bias