Fail Safe Default¶

When failure occurs, force the system into the least harmful reachable state rather than allowing uncontrolled continuation.

Solution archetype #: 431
Problem family: Hazard Exposure & Uncontained Harm
Problem subfamily: Unbounded Risky & Impaired Operation

The Diagnostic Story¶

Symptom: When something goes wrong, the system keeps acting — energized, open, outputting — because it was designed to continue rather than to stop. Operators debate what to do under emergency pressure without a pre-defined answer. Alarms fire but nothing in the system changes state. Overrides quietly become routine and the failure mode remains ambiguous to everyone depending on the system.

Pivot: Name the least harmful reachable state and connect detection or uncertainty thresholds directly to a transition into it. Make that transition automatic or procedural, constrain manual overrides, communicate the resulting state clearly, and require explicit recovery criteria before normal operation resumes.

Resolution: Failure severity drops because the system lands in a bounded, unambiguous state rather than continuing to operate unsafely. Emergency response becomes faster and clearer, reliance on perfect human attention under pressure decreases, and recovery discipline prevents the unsafe condition from being quietly re-introduced.

Reach for this when you hear…¶

[industrial safety] “If the sensor fails or goes offline, the valve needs to close — I don't want 'unknown state' to default to open.”

[access control] “When the authentication service is unreachable, the answer has to be deny, not allow — the safe default can't be 'let everyone through while we figure it out.'”

[aviation] “We design for the scenario where the pilot is incapacitated — what does the system do on its own, and is that state one we can survive?”

When This Archetype Applies¶

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

A system can fail in a way that keeps acting, remains energized, permits dangerous access, releases harmful output, traps people, corrupts state, or leaves operators unsure whether continuation is safe.

What this problem means

The structural problem is not merely failure. It is **unsafe continuation under failure**. A system may fail active, fail permissive, fail ambiguous, or fail in a way that leaves dangerous authority in place. A stuck actuator may keep moving. A software workflow may keep writing suspect data. An access-control system may grant privileges because verification is unavailable. A public agency may continue an automated decision process after anomaly signals show that outputs can no longer be trusted.

In each case, the system needs a boundary where ordinary action loses permission. Past that boundary, safety outranks availability, productivity, speed, or convenience.

Show the applicability expression

Applicability expression3 distinct conditions

Failure permits unsafe continuationandDefinable least-harm stateandRestart reintroduces hazard

Algebraic1∧2∧3

groundedpartly groundedopen

3 conditions, all required.

3Required in every casenumbered 1–3

These hold no matter which pattern applies.

1

Failure permits unsafe continuation · grounded

A critical failure can otherwise permit unsafe continuation, energy, access, output, or state.

and — also required

2

Definable least-harm state · grounded

A least-harm state can be named for the relevant failure mode.

and — also required

3

Restart reintroduces hazard · open

Restart or override can recreate the hazard after safe-state entry.

Other requirements and context (2)

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 contextFailure may be ambiguous or fast-moving.
Supporting contextHuman response may be delayed or overloaded.

Coverage

2 of 3 conditions grounded · 1 open.

Read the methodology Download the trigger-logic data

Mechanisms / Implementations¶

Emergency Stop: A user-accessible control that forces immediate stop or safe-state entry when continuation is hazardous.
Dead-Man Switch: A mechanism that requires a continuous human presence signal and enters a safe state when that signal disappears.
Trip Switch or Circuit Trip: A threshold-triggered device that physically disconnects or interrupts energy or flow the moment a limit is crossed, converting abnormal continuation into a bounded safe state.
Automatic Shutdown: Automated control logic that stops or suspends operation when anomalies or hazardous conditions are detected.
Fail-Closed or Fail-Open Design: A design method that chooses whether failure should block or release a boundary based on which default minimizes harm.
Safe Mode: A restricted operating mode that leaves only safe capabilities available for diagnosis, preservation, or recovery.
Watchdog Timer: A timer that expects periodic confirmation from a controller and triggers reset, shutdown, or safe mode when confirmation stops.
Containment on Alarm: A procedure or automation that quarantines, isolates, blocks, or closes off a hazard when an alarm occurs — walling off the affected part while the rest keeps running.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (2)

Boundary: Defines system limits.
Fail-Safe: Default to safe state on failure.

Also references 10 related abstractions

Constraint: Limits possibilities to guide outcomes.
Continuity: Smooth change without jumps.
Controllability: Ability to steer system.
Invariance: Properties unchanged under transformation.
Observability: Infer internal state externally.
Resilience: Absorb shocks and adapt.
Risk Aversion: Preference for certainty.
Robustness: Maintain functionality under stress.
State and State Transition: Captures system condition and evolution.
Threshold: Safe vs harmful levels.

Variants¶

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

Protective Shutdown · risk or failure variant · recognized

A fail-safe variant that deliberately stops operation when continued action would be more dangerous than halting.

Safe Mode Operation · implementation variant · merge review

A restricted operating variant that preserves basic diagnostics, recovery, or essential low-risk function after anomaly while blocking hazardous capabilities.

Fail-Closed Default · implementation variant · recognized

A fail-safe variant in which failure blocks access, flow, action, transaction, or release by default.

Fail-Open Default · implementation variant · recognized

A fail-safe variant in which failure opens, releases, vents, unlocks, or permits passage because blockage would be more harmful.

Passive Safe Default · implementation variant · recognized

A fail-safe variant in which the system naturally returns to a safer state when power, control, signal, or attention is lost.

Editorial Notes¶

Problem Classification¶

Classification: Hazard Exposure & Uncontained Harm → Unbounded Risky & Impaired Operation

Problem kernel: failure leaves dangerous action or energy active

Rationale: The default state permits access, output, corruption, or continuation when operators cannot know that ongoing operation is safe.

Independent corroboration: The earliest necessary condition in the frozen evidence is: A system can fail in a way that keeps acting, remains energized, permits dangerous access, releases harmful output, traps people, corrupts state, or leaves operators unsure whether continuation is safe. That is a unbounded risky and impaired operation problem because Useful but hazardous activity has direct access to the live system, or a fault leaves the system active without a restricted state that contains consequences and supports diagnosis.

Review outcome: Independent reviewer agreement; high confidence.