Failure Mode Anticipation

Identify how a design could fail before implementation and prioritize prevention or mitigation.

Solution archetype #

433

Problem family

Fragility, Failure & Continuity Risk

Problem subfamily

Failure Anticipation & Surprise Readiness

The Diagnostic Story

Symptom: Failure is treated as a generic risk until something specific breaks, at which point everyone recognizes they had seen the signal before. Risk conversations produce probability scores and broad reminders to be careful, but no one names the concrete ways each function could fail, who would detect it, or what would change in the design to prevent it. The same category of incident keeps returning after each launch or handoff.

Pivot: Before implementation, map functions, name specific failure modes and their causes, assess effect severity and how detectable each failure is, prioritize by risk, and assign prevention or mitigation actions — changing design or controls rather than issuing vigilance reminders.

Resolution: Serious design weaknesses surface early enough to fix, and accountability for residual risk is explicit. Downtime, preventable harm, and rework drop because the design changed rather than relying on attention. Past incidents and near misses feed forward into the next anticipation cycle.

Reach for this when you hear…

[manufacturing quality] “Before we release this to the line, I want someone to sit down and write out every way it can fail at step seven, not just the obvious ones.”

[software release] “We always talk about risk in the abstract — I need a list of what specifically breaks and how we'd even know it broke before a user tells us.”

[emergency planning] “The plan assumes communications stay up, power stays on, and the secondary route is clear — what happens when exactly two of those three are wrong at the same time?”

When This Archetype Applies

No catalog groundingNone of the structural conditions is currently represented by an accepted prime or domain-specific abstraction.

Diagnostic problem

Failure is discovered after implementation because likely failure paths were not systematically identified in advance.

What this problem means

The structural problem is late discovery of foreseeable failure. A team moves from idea to implementation while treating failure as a vague possibility rather than a set of concrete paths. Once the solution is built, shipped, funded, institutionalized, or regulated, those paths become harder to remove.

This happens because design attention naturally focuses on intended function. People ask what the system should do, how it should be built, and whether the main path works. Failure Mode Anticipation adds the missing negative-space analysis: how could the function not happen, happen wrongly, happen too late, harm the wrong people, escape detection, or create cascading consequences?

Show the applicability expression

Applicability expression3 distinct conditions

Material failure consequencesandMulti-component dependenciesandConfidence mistaken for assurance

Algebraic1∧2∧3

groundedpartly groundedopen

3 conditions, all required.

3Required in every casenumbered 1–3

These hold no matter which pattern applies.

1

Material failure consequences · open

A failure could cause material harm, outage, rework, exclusion, liability, lost trust, waste, or irreversible effects. more

and — also required

2

Multi-component dependencies · open

The solution depends on multiple components, handoffs, roles, incentives, data flows, assumptions, or environments. more

and — also required

3

Confidence mistaken for assurance · 4 cases · 0 matched

The team treats expertise, enthusiasm, compliance, or standard procedure as proof the design will work. more

Other requirements and context (5)

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.

• Supporting contextA design is about to move from concept, prototype, or plan into committed implementation. more

• Supporting contextPast incidents, near misses, complaints, defects, support tickets, or workarounds suggest recurrent vulnerabilities.

• Supporting contextThe implementation context will vary across sites, users, loads, conditions, jurisdictions, or time.

Supporting context groundings

Past operational evidence suggests a vulnerability capable of recurring.

domainActive Failure— The frontline operator's act at the sharp end that completes a hazard path by aligning with holes latent conditions had pre-positioned in a system's layered defenses — the proximate, visible half of Reason's Swiss cheese model.

domainTiming Risk— The failure mode where a technically sound product, technology, or policy fails not from its own defects but because the surrounding environment is not yet — or is no longer — ready to absorb it, treating environmental readiness as a risk factor independent of execution.

domainHeisenbug— Name the software defect whose failure vanishes under observation because attaching a debugger, adding a print, or disabling optimization perturbs the timing window or interleaving it rides on — so disappearance-under-observation is the diagnostic tell, not evidence the bug is gone.

domainMandelbug— Reclassify a chaotic, irreproducible software defect as deterministic-but-undersampled — triggered by a rare joint configuration of hidden state — so effort shifts from finding the right breakpoint to sampling that joint state until the configuration is caught.

domainMedication Error— Any preventable deviation in the medication-use pipeline that could expose a patient to unintended pharmacologic action, whether or not harm results — a defence-in-depth failure whose harm rate is the product of escape probabilities across every stage, so leverage lies in downstream catch rates, not upstream error counts.

AND both parts required

context guardThe medication error or near miss has been observed in operation.

suppliesOperational evidence has already been observed in the focal system or process.

The same implementation will face varying deployment contexts.

domainProgressive-Disclosure Failure— Diagnose an interface's usability breakdowns as a single mistuning between its staging schedule and the readiness of the users and tasks it actually meets, read off by whether too much is hidden or too much exposed.

AND both parts required

context guardThe staged interface will continue to serve its heterogeneous user-and-task population in future implementation.

suppliesThe context variation is expected in future implementation.

Coverage

0 of 3 conditions grounded · 3 open.

Read the methodology · Download the trigger-logic data

Mechanisms / Implementations

• Failure Modes and Effects Analysis: A tabular method that scores each failure mode on shared severity and detectability scales — combined with an occurrence input — into a single ranked priority, so many heterogeneous failures can be triaged by a common number.
• Hazard Analysis: Enumerates the hazards a control leaves behind — including the ones it displaces — and holds each residual against an explicit tolerance rather than against whatever the current design happens to achieve.
• Premortem Workshop: A facilitated session that imagines a future failure and works backward to causes and prevention actions.
• Fault Tree Analysis: Decomposes a single system-level harm downward through logical gates until the transfer path — and the exact boundary where risk crosses out of the controlled unit — becomes explicit.
• Risk Register: A living table of what could go wrong — each adverse event tagged with its likelihood, its impact, an owner, and the trigger that fires its response — so downside uncertainty stays visible and assigned instead of remembered by whoever happened to worry about it.
• Safety Case: A structured, evidence-backed argument that a system is acceptably safe to operate in a defined context — stating the safety claim, citing the controls and evidence behind it, and judging the residual risk acceptable, valid only until the context changes.
• Design Review: A milestone gate where a proposed design is presented and challenged for failure paths, and cleared to proceed only once each serious weakness carries an assigned, owned mitigation that changes the design.
• Failure Scenario Review: A structured walkthrough of a single failure as a story — the mode, the chain of causes that triggers it, and the cascade of effects it produces across time, actors, and dependencies.
• Incident Pattern Review: A method that mines past incidents, near misses, tickets, and defects for recurring failure patterns, turning real base rates into likelihood estimates and observed precursors into detection signals for a new design.

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)

• Failure Mode and Effects Analysis (FMEA): Identify failure modes.
• Robustness: Maintain functionality under stress.
• Uncertainty: Incomplete knowledge.

Also references 11 related abstractions

• Causality: Cause-effect relationships.
• Complexity: Measures system intricacy.
• Constraint: Limits possibilities to guide outcomes.
• Controllability: Ability to steer system.
• Cost–Benefit Analysis: Evaluate decisions.
• Counterfactual Reasoning: Hypothetical alternatives.
• Feedback: Outputs influence inputs.
• Observability: Infer internal state externally.
• Probability: Quantifies uncertainty and likelihoods.
• Resilience: Absorb shocks and adapt.

▸ Show 1 more

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

FMEA-Style Failure Analysis · method family · recognized

Uses a structured failure-mode, effect, cause, scoring, and action record to anticipate design weaknesses before release or operation.

Hazard Path Analysis · subtype · recognized

Anticipates failures by tracing how a hazardous state could arise, what exposure paths it creates, and which barriers can interrupt the path.

Premortem Failure Anticipation · method family · recognized

Imagines that the solution has already failed, then reasons backward to plausible causes, warning signs, and preventive changes.

Operational Failure Mode Mapping · subtype · recognized

Maps how a workflow, service, or operating process can fail at handoffs, dependencies, staffing constraints, data flows, and exception paths.

Policy Failure Mode Anticipation · domain variant · recognized

Applies failure-mode anticipation to policy designs, administrative rules, incentives, enforcement paths, equity effects, and implementation constraints.

Editorial Notes

Problem Classification

Classification: Fragility, Failure & Continuity Risk → Failure Anticipation & Surprise Readiness

Problem kernel: likely failure paths remain unidentified before implementation

Rationale: Design proceeds without systematic examination of modes, causes, effects, and detection, so predictable faults first appear in operation.

Independent corroboration: The earliest necessary condition in the frozen evidence is: Failure is discovered after implementation because likely failure paths were not systematically identified in advance. That is a failure anticipation and surprise readiness problem because Hidden failure paths and unmodeled disruptions remain untested because preparation is tied too narrowly to ordinary variance and named scenarios.

Review outcome: Independent reviewer agreement; high confidence.