The distinction between active failures and latent conditions

What it is

The Swiss cheese model splits the factors behind an accident into two kinds. An active failure happens right at the sharp end, close in time to the accident — the wrong key pressed, a number misread, a step skipped — usually committed by the front-line operator, with consequences that show up almost immediately. A latent condition is a design decision, a resourcing choice, or a management arrangement buried in the system long before the accident — a procedure written ambiguously, training compressed to meet a deadline, a default setting that was never actually tested. On its own, a latent condition causes nothing; it lies dormant in the system, sometimes for years, waiting to meet an active failure. The distinction matters because asking "who pressed the wrong key" only ever turns up the active failure; asking "why was that key easy to press wrong, and why wasn't it caught afterward" is what surfaces the latent condition.

Why it happens

Active failures get treated as the whole story because they sit closest to the outcome in time and space — an investigator naturally sees them first. But the rate at which active failures actually turn into accidents is itself set by the latent conditions underneath: the same slip, in a system with clear procedures, well-differentiated controls, and solid training, gets caught by the next layer of defense; in a system where latent conditions have already worn several layers thin, the same slip sails straight through to a bad outcome. A condition stays "latent" precisely because, unlike an active failure, it has no clear moment of triggering — it's the accumulated residue of design decisions and organizational choices made over time, and it's usually only noticed, for the first time, once an accident forces someone to trace back and find it already sitting there.

Studying it

The standard way to surface latent conditions in an investigation is to work upstream from the active failure: why was this action even possible, why wasn't it stopped by an earlier layer, what did the procedures and resourcing look like at the time. This kind of inquiry typically produces a timeline with several nested layers of "why," not a single causal arrow. Methodological caveat: identifying latent conditions depends heavily on how far back the investigator can actually pull records and decision history. When organizational decisions leave no trace — a verbal call, a budget cut nobody documented — latent conditions get systematically missed, and the resulting accident report ends up looking more operator-centric than the situation really was. That's a bias introduced by what evidence happens to be retrievable, not evidence that latent conditions genuinely play a smaller role than active failures.

Where it stops holding

The line between active failure and latent condition isn't absolute: a decision may have been an explicit, attributable choice by a specific person at the time it was made, but once it settles into a procedure or a default configuration, it turns into a latent condition from the system's point of view. This distinction also doesn't mean active failures don't need attention — real, directly fixable problems like inadequate training or misallocated attention do occur at the sharp end. The point of the distinction is to stop an investigation from closing the book once the active failure has been dealt with, not to deny that active failures exist.

Applying it

When reviewing any error or incident, log not just what happened at the sharp end but also the earlier decisions that left that operating point unprotected: who approved the current default configuration, when the procedure was last checked against reality, whether current training predates the system's last change. Put these items side by side in the review record rather than leaving a single operator's name in a "direct cause" field. Verification: sample recent incident records and check how the "direct cause" and "root cause" fields are actually filled in. If most records only note operator behavior and the root-cause field is habitually blank or filled with generic phrases like "reinforce training" that point to no concrete system change, the latent-condition tracing step isn't actually running.

Related

• Same group: A10.07.1 layered defenses and hole alignment · 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.09 human reliability and blame culture · A10.16 accident investigation and error reporting · Y7.01 systemic causes
• Search terms: active failure · latent condition · root cause