Fail-Safe¶
Core Idea¶
Fail-Safe is a design pattern characterized by (1) the deliberate arrangement of a system's failure behavior so that, when a critical component or control mechanism fails, the system's default state is the least harmful of the possible post-failure states rather than devolving into an uncontrolled or catastrophic condition, (2) the explicit acceptance that system failures will occur and that containment and safe degradation — not their elimination — is the pragmatic and often cost-effective design goal, (3) implementation through mechanisms whose natural, unpowered, or disconnected state produces the safe condition (brakes that engage when power is lost, valves that close when signal is lost, systems that default to deny when authentication services fail), and (4) a corresponding discipline of failure-consequence analysis: identifying what "safe" means for each critical failure mode, mapping that safe state, and ensuring the mechanism that must hold that state does so passively (without continued power or signal). The deeper insight is that active control — pumps, solenoids, powered brakes, continuous signals — requires constant energy and working components; when the power fails or components break, active control collapses. Passive mechanisms (gravity, spring tension, mechanical detents, default-deny logic, stateless processes) operate with no external input and therefore persist even when the control system itself has failed. Routing critical failures through passive mechanisms inverts the failure-mode relationship: failure of the control system does not cause failure of safety; it triggers the safety mechanism. The practice originated in mechanical safety systems (elevator brakes, train dead-man's switches, pressure relief valves in the 19th century) and has evolved into a foundational principle across every domain with critical safety requirements: aviation (runaway-trim disable, autopilot disengagement), nuclear engineering (passive cooling, gravity-driven emergency shutdown), medical devices (pacemakers reverting to fixed rate on sensor failure), cybersecurity (deny-by-default authorization, circuit breakers, default encryption), software engineering (transaction rollback, safe mode), and industrial safety (interlocks, emergency stops)[1].
How would you explain it like I'm…
Safe When Broken
Breaks Into Safe Mode
Safe-By-Default On Failure
Structural Signature¶
- The identification of critical failure modes and definition of what constitutes a "safe" state for each [2]
- The mechanism design ensuring the safe state is achieved passively (gravity, spring, mechanical detent, signal loss) not by active control [3]
- The separation of control logic (which may fail) from safety logic (which must succeed via passive routing) [2]
- The default-to-safe routing that assumes control pathway failure and maps failure to the predetermined safe state [4]
- The cost-safety trade-off: fail-safe design often costs more (dual mechanisms, mechanical linkages) but is justified when failure consequence is catastrophic [5]
- The distinction between fail-safe (safe state on failure) and fail-secure (locked-down state on failure) as contextual design choices [6]
What It Is Not¶
-
Not the same as Robustness. Robustness is the general functional property of maintaining performance across variation and disturbance; fail-safe is a specific design pattern for handling the failures that robustness cannot prevent. A robust system might maintain normal function under wide variation; a fail-safe system accepts that it will eventually fail but ensures that failure does not cause catastrophe.
-
Not the same as Redundancy. Redundancy provides duplicate capability so that failure of one component is masked — the system continues to operate normally. Fail-safe does not mask failure; it accepts failure and routes it to a safe state. Elevator systems often use both: redundant cables for robustness, and mechanical over-speed governors that engage on cable breakage for fail-safety. The two mechanisms serve different purposes.
-
Not the same as Fault Tolerance. Fault tolerance (via redundancy, voting, error correction) aims to make system failure invisible to the user — the system continues to deliver service despite component failures. Fail-safe does not hide failure; it makes failure visible but non-catastrophic. A voting system can tolerate one-out-of-three sensor failures (fault tolerance); a dead-man's switch is fail-safe because it stops the train when the operator fails but does not mask the failure.
-
Not the same as Error Proofing or Poka-Yoke. Error proofing prevents human operator error by restricting possible actions (a part that can only fit one way, a machine that refuses wrong-sequence operations). Fail-safe handles component or control failure, not operator error. An elevator with interlocks (poka-yoke: prevents simultaneous door and motion commands) and with mechanical brakes (fail-safe: engages on power loss) uses both strategies.
-
Not the same as Fail-Secure. Fail-safe and fail-secure are opposite contextual choices. Fail-safe defaults to an open, permissive, or flowing state on failure (fire doors open to allow evacuation, electrical fuses blow to open the circuit, elevator doors unlock to release passengers). Fail-secure defaults to a closed, restrictive, or locked state (vault doors lock when power is lost, authentication systems deny when identity service is down). Which is truly "safe" depends entirely on the context: fire safety (fail-safe = evacuate) requires doors to open; security (fail-secure = lock down) requires doors to remain closed.
-
Not universal to all failure modes. Fail-safe is a design pattern for critical-consequence failures that the designer decides must not propagate catastrophically. Not every system component requires fail-safe treatment; a non-critical feature can fail with modest consequences and be repaired during normal maintenance. Applying fail-safe design to everything wastes cost and complexity.
-
Not a substitute for failure prevention. Fail-safe accepts failure but does not cause or encourage it; the goal remains to reduce failure probability. A system with excellent fail-safe design that fails frequently is poorly designed overall. The goal is low failure rate (through robustness) combined with safe failure modes (through fail-safe design).
Broad Use¶
Mechanical engineering (elevator brakes engaging on loss of power or cable breakage, train dead-man's switches that stop the engine if the operator releases the handle or becomes incapacitated, pressure relief valves that open passively if system pressure exceeds setpoint, tip-over shutoff switches on power tools), electrical engineering (circuit breakers that trip and open circuits on overcurrent, fuses that melt and open on overcurrent, ground-fault interrupters that trip on stray current, thermal cutoffs that interrupt power on temperature rise), aviation (runaway-trim disable that prevents autopilot from driving control surface to mechanical limit, electrical switches that disconnect autopilot on pilot input, mechanical stops on control surfaces preventing over-deflection, fuel shutoff systems activating on impact), marine engineering (through-hull fittings with check valves, bilge-pump automatic shutoffs when tank is empty), medical devices (pacemakers reverting to fixed rate and fixed AV delay when sensors fail, infusion pumps defaulting to off if motor control fails, defibrillators locking out on electrical noise), nuclear engineering (passive emergency cooling loops driven by gravity and thermosiphon without pumps, control-rod gravity insertion if power is lost), chemical and process safety (interlocks that prevent dangerous operation sequences, emergency-shutdown systems that default to safe state on power loss, relief-valve systems sized for worst-case relief without active control), building safety (fire doors closing on temperature rise or alarm activation, stairwell pressurization failing open to allow evacuation, emergency lighting on battery backup, panic bars releasing on manual push), software systems (transaction rollback reverting database to consistent state on failure, circuit breakers defaulting to open on sustained errors, caching defaulting to cached value on backend failure, asymmetric cryptography defaulting to deny on authentication-service failure, safe mode loading on corruption detection), financial markets (trading halts and circuit breakers that trigger on extreme price moves, position limits that automatically cap exposure, margin calls and liquidation that execute on account degradation), and cybersecurity (default-deny authorization policies, whitelisting rather than blacklisting, encryption defaulting on, secure-channel negotiation with fallback to failure rather than insecure operation).
Clarity¶
Naming the pattern explicitly distinguishes safe-default design from the broader robustness and reliability commitments, forcing the analytical work: identifying what "safe" means in the specific context (safe for whom, under what hazard), which failure modes route to the safe state by construction, and which require active handling. Without the explicit concept, organizations default to pursuing "reliability" (preventing failures) and treat failures as unforeseen anomalies rather than as predictable events requiring deliberate design. Un-named fail-safe thinking tends to disappear and be reinvented from scratch in each domain. With the concept named and practiced, design reviews are more likely to ask "if this component fails, what is the safe default state, and how is it achieved?" rather than only asking "how can we prevent this from failing?"
Manages Complexity¶
Attempting to design a system that never fails is often impossible, costs excessive, and distracts from the pragmatic task. Fail-safe thinking instead decomposes the problem: (1) identify critical failure modes — which failures are consequences unacceptable (catastrophic), (2) define the safe state for each — what condition minimizes harm, (3) design the mechanism to achieve that state passively — without relying on power, control signals, or the failed component to work correctly, (4) accept that the system will reach safe state when failures occur (not continue normal operation), and (5) manage the system's transition through the failure (restart, repair, diagnosis). This reduces the complexity-management burden from "prevent all failure" to "design safe failure modes + manage recovery," which is more tractable. For complex systems with many components, fail-safe is often applied selectively: critical failures (loss of containment, loss of braking, loss of patient consciousness) trigger fail-safe mechanisms; non-critical failures (secondary features, diagnostics) tolerate repair-in-the-field or deferred maintenance.
Abstract Reasoning¶
The analyst asks: What are the critical failure modes — the component or control failures that, if uncontrolled, would produce catastrophic outcomes? For each critical failure, what is the safe state — what condition minimizes harm? Can the safe state be achieved passively (gravity, springs, mechanical locks, signal loss), or does it require active control (pumps, solenoids, continuous signals)? If active control is required, what mechanisms back up that control if it fails? What is the failure-propagation pathway — if this component fails, does the system naturally drift toward the safe state, or does it drift toward danger, requiring explicit routing to safety? What are the costs of fail-safe design (extra mechanisms, complexity, weight, latency) and how do they compare to the cost of failure? For systems with multiple components, should all failures be routed to safe state, or only critical ones? What is the definition of "safe" in this context — is it the same for all stakeholders (operator, passenger, public, environment)? Mature practice recognizes that fail-safe design is not one-size-fits-all but must be analyzed per context, and that the distinction between fail-safe and fail-secure (which state is truly safe?) requires understanding the specific hazards and constraints.
Knowledge Transfer¶
| Domain | Critical failure mode | Safe state | Passive mechanism |
|---|---|---|---|
| Elevator | Loss of braking force | Brakes engaged | Mechanical spring + gravity |
| Train control | Loss of brake command | Brakes applied | Spring load + mechanical detent |
| Pressure vessel | Loss of relief control | Pressure vents | Mechanical spring-loaded valve |
| Aviation autopilot | Loss of signal from autopilot | Autopilot disengages | Electrical disconnect; pilot inputs override |
| Medical infusion | Loss of motor control | Pump stops | Spring-return to off position |
| Fire door | Loss of power or alarm signal | Door closes | Spring hinge + gravity |
| Authentication system | Identity service unavailable | Access denied | Default-deny logic; no bypass |
| Database transaction | Hardware failure mid-transaction | Transaction rolls back | Atomic logging + replay; never half-state |
| Nuclear shutdown | Loss of electrical power | Control rods drop into core | Gravity insertion; no pump required |
| Gas pipeline | Loss of pressure regulation | Flow stops | Check valves; no signal needed |
Across rows: each domain's critical failure mode, the safe state (what should happen when failure occurs), and the passive mechanism that achieves it without requiring the failed component to work. Transfer principle: the pattern is domain-independent; the details (what is safe, how to passively route) are context-specific.
Examples¶
Formal/abstract¶
Reason's Human Error (1990) and Perrow's Normal Accidents (1984) both analyze fail-safe design in complex sociotechnical systems, with aviation providing a canonical example. The story of "Gimli Glider" (Air Canada Flight 143, 1983) illustrates fail-safe design success and failure interplay. A Boeing 767 running on metric fuel (liters) was refueled by ground crew using imperial units (pounds), resulting in only half the fuel needed for a transatlantic flight. The crew discovered the error at 41,000 feet with 24 minutes of fuel remaining. The aircraft's primary engines flamed out; the backup systems (hydraulic pumps, electrical generators) lost power. However, the airplane's fail-safe design routed the failure toward recovery: the engine failure triggered automatic gliding descent (passive fail-safe: losing power does not cause uncontrolled pitch-down but rather safe descent toward available airports); the loss of engine-driven generators triggered battery-powered essential systems (fail-safe: critical systems have battery backup); the loss of hydraulic pressure activated ram-air turbine (RAT) — a small fan that deploys in the airstream, turns a generator, and provides minimal hydraulic and electrical power (fail-safe: loss of main power automatically deploys mechanical backup). The crew glided to a former airfield in Gimli, Manitoba, and landed safely with fuel exhausted. Contrast: had the aircraft been designed with active-only systems (relying on engine-driven power with no passive backup), the failure to flame-out would have cascaded: no electrical power = no instruments = no guidance = unrecoverable descent. The fail-safe mechanisms (passive RAT, battery backup, descent gliding) were not designed specifically for this combination of failures but rather designed to ensure that any power-loss scenario routes the aircraft to a survivable state. Leveson's Engineering a Safer World (2011) extends the analysis to argue that fail-safe design must be intentional and system-wide, not ad-hoc. The success of fail-safe in aviation has driven adoption across medical devices, nuclear engineering, and process safety as the foundational safety principle[2].
Mapped back: This instantiates the signature directly — identification of critical failure (loss of all engines and power, D34-017), definition of safe state (gliding descent toward airport, not uncontrolled drop, D34-017), passive mechanism routing to safety (RAT deployment is mechanical, not power-dependent; battery is passive storage; gravity enables gliding, D34-018), separation of control from safety (engine failure disables active control but triggers passive safety, D34-019), and cost-safety trade-off (the RAT and battery systems cost money and weight but are justified by the catastrophic consequence of power loss, D34-021).
Applied/industry¶
A pharmaceutical manufacturing facility produces injectable medications in sealed vials. The production line includes a pressurized sterilization chamber (an autoclave operating at 15 psi, 120°C). The chamber has manual and automated shut-off mechanisms. Design challenge: if the pressure relief system fails to open at setpoint, the chamber pressure will rise uncontrolled, potentially rupturing the vessel (catastrophic consequence: explosion, chemical release, injuries). The automated relief system (solenoid-piloted valve) requires electrical signal and pilot pressure to function; if either fails, the active relief fails. The fail-safe solution: install a mechanical pressure relief valve (spring-loaded, pilot-independent) set to open at 16 psi, below the rupture threshold. The mechanical valve requires no electrical signal, no pilot pressure, and no active control — it opens passively as pressure rises and closes as pressure drops. The solenoid valve (automated) can be faster and more precise, but failure of solenoid or signal does not cause catastrophe because the mechanical valve is always present and will open. This is fail-safe design: the critical failure mode (loss of active relief control) is routed to a passive safe state (pressure relief continues to function via mechanical spring). Cost: the mechanical valve is simpler and cheaper than the solenoid, so fail-safe design actually saves money here. Contrast: if the design used only the solenoid valve with no mechanical backup, failure of the solenoid would lead to uncontrolled pressure rise and vessel rupture. Historical analysis: early industrial autoclave failures were precisely this kind of failure; the shift to mechanical relief valves (1920s-1930s) reduced autoclave explosions dramatically. Modern regulations require both active and passive relief systems on pressure vessels, institutionalizing fail-safe design[5].
Mapped back: Shows fail-safe as contextual design — the safe state is defined (pressure relief below rupture limit, D34-017), achieved passively (spring-loaded valve, no signal needed, D34-018), separate from active control (solenoid and mechanical are independent pathways, D34-019), routing failure to safety (solenoid failure triggers mechanical relief, D34-020), and economically justifiable (mechanical relief is cheaper and simpler anyway, D34-021).
Structural Tensions¶
-
T1: Fail-safe versus fail-secure. Fail-safe (safe state on failure) and fail-secure (locked/restricted state on failure) are opposite design choices, and the right choice depends on the context. Fire evacuation requires fail-safe (doors open on power loss to allow escape); security perimeter requires fail-secure (doors lock on power loss to prevent intrusion). The tension arises in systems with mixed hazards: a hospital has both safety (escape routes must remain open) and security (controlled access to restricted areas). The resolution requires explicit hazard analysis per zone, not a universal policy[6].
-
T2: Passive safety versus speed and precision. Passive mechanisms (springs, gravity, mechanical detents) are reliable and require no power but are often slow and inflexible. Active control (solenoids, pumps, servo loops) can be fast and precise but requires power and working components. A fail-safe design trades speed and precision for reliability in critical scenarios. A common optimization is hybrid: active control in normal operation (fast, precise) with passive backup on failure (slow, reliable). The tension is in the design and testing complexity — hybrid systems must be tested to ensure both active and passive pathways work correctly[3].
-
T3: Universal fail-safe versus selective application. Designing every component to fail-safe is comprehensive but expensive. Selective application (critical failures only) is cost-efficient but requires explicit prioritization of which failures are critical. The tension is in the analysis: missing a critical failure mode (under-selection) can produce catastrophe; over-selecting non-critical failures (over-selection) wastes cost. Mature practice uses structured failure mode and effects analysis (FMEA) to identify critical modes, then applies fail-safe design selectively[5].
-
T4: Passive mechanism reliability versus maintenance burden. A passive mechanism (spring, mechanical valve) that sits unused for years may degrade (corrosion, fatigue, setting-drift) and fail to function when needed. Ensuring reliability of dormant passive mechanisms requires periodic testing and maintenance — bench-testing relief valves, actuating deadman switches, validating battery charge. The tension is between never-fail-on-demand (perfect maintenance) and cost of maintenance. Regulatory standards (e.g., ASME for pressure vessels) specify minimum testing intervals[7].
-
T5: Fail-safe definition versus stakeholder disagreement. Different stakeholders may disagree on what constitutes "safe." An elevator operator prefers fail-safe-to-stop (remains stationary if brake fails), minimizing rescue requirements. A passenger in an elevator prefers fail-safe-to-open (doors open if power is lost), minimizing entrapment anxiety. A building manager prefers fail-secure-to-stay-put (elevator remains in place if power is lost, reducing security risk of unattended cars). Resolving this requires explicit stakeholder analysis and often leads to hybrid solutions (doors open, but car remains in place and locked).
-
T6: Detection latency versus default-state safety. Some failures are immediate and obvious (power loss); some are slow and subtle (sensor drift, corrosion, gradual degradation). Immediate failures can route to passive safe state almost instantly (power loss triggers gravity-return valve closure in ~100ms). Slow failures may not be detected before the passive safe state is reached, leaving the system in a potentially degraded mode (a pressure relief valve that slowly drifts off setpoint might reach its limit without operator awareness). The tension is between fail-safe-on-obvious-failure (fast, reliable) and fail-safe-on-subtle-failure (requires active monitoring and detection)[8][4].
Structural–Framed Character¶
Fail-Safe is a hybrid on the structural–framed spectrum, with the structural core and the frame roughly balanced. Part of it is a bare pattern — arranging a system so that its default post-failure state is the least harmful available one. Part of it is a vocabulary and set of assumptions inherited from engineering design.
The diagnostics fall on both sides. The relational idea — that when a component fails, control should settle into a safe rather than catastrophic state — transfers unchanged across railway brakes that engage on loss of signal, dead-man switches, and circuit breakers that trip open. That much is a formal arrangement of failure behavior you can simply recognize. But a real frame comes with it: deciding what counts as a safe state, and accepting that failure is inevitable and should be contained rather than eliminated, are design judgments shaped by engineering priorities and a normative commitment to harm-minimization. The concept's origin is a practice of building things, not a pure mathematical relation, so its meaning leans partly on that designer's perspective. It therefore reads mixed-framed.
Substrate Independence¶
Fail-Safe is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its structural logic — identify the critical failure mode, default passively into a safe state, and separate control from safety logic — transfers across aviation, manufacturing, and infrastructure within engineering, systems thinking, and cybernetics. What limits it is that the vocabulary and examples remain engineering-heavy; application to social or cognitive systems is conceivable but underdeveloped. It is a robust cross-domain engineering pattern that has not yet shown much reach beyond engineering.
- Composite substrate independence — 3 / 5
- Domain breadth — 3 / 5
- Structural abstraction — 4 / 5
- Transfer evidence — 3 / 5
Relationships to Other Primes¶
Parents (2) — more general patterns this builds on
-
Fail-Safe is a kind of Fault Tolerance
Fail-safe is a specialization of fault tolerance in which the response to failure is to drop into a pre-engineered least-harmful state rather than to continue providing service through redundancy or failover. It inherits the general fault-tolerance commitment that components will fail and that the system must be designed so individual failures do not cascade into system-level catastrophe, and specializes by fixing the strategy to safe-default-on-failure (brakes engage when power is lost, valves close when signal is lost) rather than to continued operational availability.
-
Fail-Safe presupposes Reversibility and Irreversibility
Fail-Safe arranges the system so that its default post-failure state is the least harmful available — gates default closed, brakes default engaged, valves default safe — rather than devolving into an uncontrolled state. Choosing such a default requires weighing which transitions are reversible (and so tolerable as a halt state) against which are irreversible (and so must be avoided). That is the apparatus of Reversibility and Irreversibility. Fail-Safe presupposes the reversibility distinction to identify which failure state to engineer toward.
Children (1) — more specific cases that build on this
-
Error Proofing (Poka-Yoke) is a kind of Fail-Safe
Error proofing is a specialization of fail-safe in which the safe-default discipline is applied specifically at the human-action interface: the system is designed so that a mistaken input is either blocked at the source or unmissable when made. It inherits the general fail-safe commitment that failures will occur and that the post-failure state should be the least harmful available, and specializes by locating the failure mode at human error and engineering the constraint to shift the burden from vigilance to design.
Path to root: Fail-Safe → Reversibility and Irreversibility
Neighborhood in Abstraction Space¶
Fail-Safe sits in a sparse region of abstraction space (89th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.
Family — Propagation, Criticality & Containment (17 primes)
Nearest neighbors
- Error Proofing (Poka-Yoke) — 0.78
- Fault Tolerance — 0.76
- Failure Mode and Effects Analysis (FMEA) — 0.75
- Circuit Breaker — 0.74
- Controlled Reentry — 0.74
Computed from structural-signature embeddings · 2026-05-29
Not to Be Confused With¶
Fail-Safe is distinct from Redundancy, its nearest neighbor (similarity 0.755), though both address system failure. Redundancy works by distributing risk across multiple pathways: if one pathway fails, another continues the function. A dual hydraulic brake system in an aircraft has redundancy—if one system fails, the other maintains braking capacity. An airplane with four engines achieves redundancy; losing one engine does not prevent the plane from flying to safety. Redundancy is about function preservation through backup pathways. Fail-Safe, by contrast, works by eliminating risk through structural reversion to a safe state: the system is designed so that if the primary control fails, the system passively reverts to a predetermined safe state without requiring any secondary pathway or active intervention. An elevator that falls when the cable breaks is not fail-safe and not redundant; an elevator with a spring-loaded catch that engages mechanically if the cable breaks is fail-safe (it achieves safety through structural passive reversion, not through a backup cable system). Fail-Safe accepts loss of function if safety requires it; redundancy preserves function through backup. A fail-safe system might use redundancy as part of its design (a pressure vessel might have both a mechanical relief valve—fail-safe—and a solenoid-controlled valve—active redundancy), but the two are structurally distinct: redundancy ensures continued function despite failure, while fail-safe ensures safe function even at cost of losing function.
Nor is Fail-Safe equivalent to Fault Tolerance, which is broader. Fault Tolerance specifies how a system maintains function despite failures—through redundancy, error correction, graceful degradation, or state recovery. A distributed database with replication is fault-tolerant: if one node fails, other nodes continue serving data. A RAID storage array is fault-tolerant: if one disk fails, parity information allows reconstruction of lost data. Fault Tolerance asks: "How do we keep the system working despite component failures?" Fail-Safe, by contrast, specifies what the safe state is and ensures the system defaults to it on failure. The two intentions diverge fundamentally: Fault Tolerance prioritizes continuation despite damage; Fail-Safe prioritizes safety over continuation. An aircraft engine system might be fault-tolerant (operate on remaining engines after one fails) and fail-safe (engine shuts down safely when oil pressure drops); these are compatible but distinct. A chemical reactor system designed for fault tolerance might continue processing after a temperature sensor fails (switching to redundant sensors); the same system might include fail-safe mechanisms (reactor drains and cools passively if heating system fails). The vocabulary shows the difference: fault tolerance talks about "system recovery," "graceful degradation," "state machine transitions"; fail-safe talks about "safe state," "passive mechanism," "default behavior on failure."
Finally, Fail-Safe differs from Robustness, which is about resistance to disturbance rather than response to failure. A robust system maintains its function across a wide range of disturbances—a bridge designed to withstand both normal traffic and wind is robust. Robustness is achieved through materials, design margins, structural stiffness, damping—features that resist the disturbance itself. Fail-Safe, by contrast, is about accepting failure and routing it safely: a pressure relief valve achieves fail-safety not by resisting pressure buildup (robustness would be a stronger vessel), but by accepting that pressure might rise and designing the system to vent it passively. The distinction is in the strategy: robustness prevents failure through resistance; fail-safety handles failure through controlled reversion. These can coexist—a vessel might be robust (thick walls, safety margins) and have fail-safe relief (passive venting). But they are conceptually opposite: robust design maximizes function preservation against disturbance; fail-safe design accepts that function will be lost if safety requires it. A robust earthquake-resistant building shakes but doesn't collapse; a fail-safe earthquake response might shut down elevators and lock certain doors (loss of function for safety). A robust communication system maintains signal despite interference; a fail-safe communication network breaks the link rather than transmit corrupted data. The vocabulary again shows the distinction: robustness talks about "resistance," "margins," "damage resistance"; fail-safe talks about "default states," "passive response," "loss of function for safety."
Solution Archetypes¶
Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.
Built directly on this prime (3)
Also a related prime in 14 archetypes
- Assumption Stress Testing
- Checkpoint and Rollback
- Closure-Preserving Operation
- Control Surface Creation
- Domain–Codomain Delimitation
- Emergency Authority Activation and Constraint
- Fault-Tolerant Operation
- Guarded State Transition
- Harmful Emergence Containment
- Invariant Guarding
Notes¶
Fail-safe design origins lie in 19th-century mechanical safety (Elisha Otis's safety catch for elevators, 1853; Westinghouse's air brake with automatic application on air-line rupture, 1872; mechanical pressure relief valves). The formalization as a design principle is due to aviation (Weibull analysis of failure modes, Fault-Tree Analysis developed at Boeing), nuclear engineering (post-Three Mile Island, 1979, passive cooling requirements), and chemical process safety (Lees, 2005, Loss Prevention in the Process Industries). Modern applications include cybersecurity (default-deny authorization, circuit breakers), software engineering (transaction rollback, safe mode), and distributed systems (Byzantine fault tolerance, quorum-based consensus). The concept interfaces closely with Robustness (#282) as orthogonal strategies (robustness prevents failure, fail-safe handles failure when prevention fails), with Redundancy (#287) as a complementary approach (redundancy masks failure, fail-safe accepts failure but routes it safely), with Margin of Safety (#283) as a different uncertainty-handling approach, and with Error Proofing (#296) as a complementary human-factors strategy.
References¶
[1] Otis, E. G. (1853). Safety catch for elevator. U.S. Patent No. 7,066. ↩
[2] Leveson, N. G. (2011). Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press. systems thinking safety coupling feedback causality control structures. ↩
[3] Westinghouse, G. (1872). Air-brake with automatic application. U.S. Patent No. 128,134. ↩
[4] Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. Basic Books. ↩
[5] Lees, F. P. (2005). Loss Prevention in the Process Industries: Hazard Identification, Assessment and Control (3rd ed.). Butterworth-Heinemann. ↩
[6] Hollnagel, E. (2014). Safety-I and Safety-II: The Past and Future of Safety Management. Ashgate. Argues that safety management should focus on the envelope of normal performance variability and adaptive mechanisms rather than on exhaustive enumeration of failure modes; reframes resilience as the capacity to succeed under varying conditions. ↩
[7] U.S. Nuclear Regulatory Commission. (1989). Severe Accident Risks: An Assessment for Five U.S. Nuclear Power Plants (NUREG-1150). NRC. ↩
[8] Reason, J. (1990). Human Error. Cambridge University Press. [^perrow-1984]: Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. Basic Books. (Reissued by Princeton University Press, 1999.) Analyses how tight coupling and complex interactions in nuclear, chemical, and aerospace systems determine which reserves are decorative and which are load-bearing; the contingency-removal counterfactual maps onto Perrow's coupling-and-slack framework. ↩