Fail-Safe Default

batch: First Iteration/Batch 16

aliases:
fail-safe default
safe default
safe default state
fail-to-safe posture
least harmful default
fail-safe state
safe failure posture
fail-safe design

related_primes: threshold controllability observability state_and_state_transition invariance constraint robustness resilience risk_aversion continuity

slug: boundary

slug: threshold

slug: controllability

slug: observability

slug: invariance

slug: robustness

slug: resilience

slug: continuity

components:
Hazardous Failure Mode
Safe Default State
Failure Detector
Shutdown or Isolation Rule
Manual Override
Recovery Policy
Status Indicator
Override Authorization Boundary
Diagnostic Access Path
Fail-Safe Test Case

mechanisms:
Emergency Stop
Dead-Man Switch
Trip Switch or Circuit Trip
Automatic Shutdown
Fail-Closed or Fail-Open Design
Safe Mode
Watchdog Timer
Containment on Alarm

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

compression_statement: When uncontrolled failure could cause harm, exposure, irreversible action, ambiguous state, or unsafe continuation, define a fail-safe default that detects or assumes loss of control, transitions to a safer state, and prevents return to normal operation until the hazard has been cleared.

core_intuition: Not every failure should be survived by continuing to operate. Sometimes the wisest design is to make the default outcome boring, bounded, and harmless when ordinary control disappears. Fail-safe design asks what state the system should fall into when signals are missing, components are impaired, authority is uncertain, or operators are under stress.

canonical_formula: hazardous failure mode + safe default state + failure detector + transition rule + constrained override + recovery policy -> least harmful reachable state under failure

structural_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.

condition: Unsafe continuation is possible

description: After a fault, anomaly, loss of signal, or operator incapacity, the system may continue acting in a way that creates more harm than stopping, isolating, opening, closing, or restricting it.

condition: The least harmful state can be named

description: Designers can identify a reachable state that reduces hazard relative to uncontrolled continuation, even if that state sacrifices service, speed, access, or convenience.

condition: Failure may be ambiguous or fast-moving

description: Waiting for perfect diagnosis would let harm accumulate, so the design needs a conservative default when evidence is missing, late, or uncertain.

condition: Human response may be delayed or overloaded

description: Operators may not notice, interpret, or act quickly enough, so the system needs automatic, procedural, or highly salient routes into the safe state.

condition: Restart or override can recreate the hazard

description: Returning from the safe state requires rules because an immediate reset can re-enable the same dangerous condition.

symptom: The system fails active rather than failing harmlessly

meaning: A loss of power, signal, control, permission, or operator attention leaves the system moving, releasing, granting, executing, or energizing when it should not.

symptom: Operators debate safety under emergency pressure

meaning: The system lacks a predefined safe default, so people must improvise while hazard is accumulating.

symptom: Alarms reveal hazards but do not change state

meaning: The system can observe danger but still relies on delayed or optional human action to stop the harmful continuation.

symptom: Overrides quietly become normal operations

meaning: A fail-safe response exists, but users bypass it because it is inconvenient, too frequent, poorly tuned, or not accountable.

symptom: Failure state is ambiguous to users or dependents

meaning: Other actors cannot tell whether the system is safe, stopped, restricted, isolated, or still operating normally.

symptom: Recovery repeatedly reintroduces the unsafe condition

meaning: The system enters a safe state, but the reset path does not verify that the cause of failure has been cleared.

root_tension: Systems are often designed to keep functioning, but in some failure conditions continued function is the hazard. Fail-Safe Default resolves the tension by prioritizing harm minimization over availability whenever the system crosses a boundary where normal action can no longer be trusted.

anti_signatures: The main goal is to continue critical function despite local faults; use fault_tolerant_operation.

anti_signatures: The core intervention is reducing service quality or scope while still serving users; use graceful_degradation.

anti_signatures: The central move is switching to already-provisioned alternate capacity; use failover or redundant_backup_provisioning.

anti_signatures: The problem is overload spreading through a dependency and the response is to interrupt calls or demand; use circuit_breaker or load_shedding.

anti_signatures: The core need is staged restoration from failure back to normal operation; use controlled_reentry or graceful_recovery_pathway.

anti_signatures: There is no identifiable safe default state, or every default is as harmful as continued operation.

anti_signatures: The intervention is only a device such as an emergency stop, watchdog timer, or trip switch with no broader default-state policy.

structural_intervention: Identify hazardous failure modes, define what state is safest when normal control is lost, connect detection or uncertainty thresholds to an automatic or procedural transition, constrain overrides, communicate the state clearly, and require recovery criteria before resuming normal operation.

step: Name the hazardous failure mode

logic: Specify the concrete hazard created by uncontrolled continuation, such as motion, heat, pressure, privilege, release, data write, clinical dose, financial trade, public instruction, or procedural authority.

step: Choose the least harmful reachable state

logic: Decide whether safety requires stopping, opening, closing, isolating, venting, locking, unlocking, denying, quarantining, freezing, or entering restricted mode.

step: Define failure detection and assumption rules

logic: Identify signals, missing signals, thresholds, alarms, heartbeats, operator actions, or diagnostic results that should trigger the safe default. Include loss of signal as a possible trigger when silence is unsafe.

step: Make the transition reliable under stress

logic: Design the transition so it works during power loss, control failure, attention loss, overload, panic, or partial impairment, not only during clean laboratory conditions.

step: Limit the scope of continued capability

logic: Disable or isolate the capabilities that create hazard while preserving only the functions needed for safety, diagnosis, communication, or controlled recovery.

step: Expose status and prevent hidden bypass

logic: Make the safe state legible and make overrides explicit, bounded, and accountable so protection does not silently disappear.

step: Require recovery criteria before restart

logic: Define inspection, reset, verification, authorization, and monitoring rules before normal operation resumes.

step: Test failure behavior, not only nominal behavior

logic: Exercise loss of power, missing signals, stuck controls, false positives, false negatives, operator error, override behavior, and restart after safe-state entry.

rule: Choose safe over live when the two conflict.

rationale: Fail-safe design is appropriate only where preserving availability is less important than preventing harm under failure.

rule: Define safety relative to the hazard, not as a universal state.

rationale: Some systems should fail closed, others fail open, and others fail into restricted mode. The safe default depends on what continuation would harm.

rule: Treat missing critical signals as meaningful when silence is dangerous.

rationale: A system that waits for explicit proof of failure may continue dangerously after the detector, communication channel, or operator has failed.

rule: Make override harder than protection but not impossible when human rescue is required.

rationale: Overly easy override normalizes bypass; impossible override can trap people or prevent context-sensitive rescue.

rule: Restart only after clearing the cause, not merely resetting the symptom.

rationale: The safe state protects against immediate harm; the recovery policy protects against repeated activation and unsafe normalization.

rule: Test the default under degraded conditions.

rationale: A fail-safe that depends on the failed subsystem to enter safety may be only nominally safe.

invariant: Harm minimization

description: The transition should reduce expected harm relative to uncontrolled continuation, even if it interrupts normal function.

invariant: Unambiguous safety state

description: Operators, users, and dependent systems can tell whether the system is normal, safe-stopped, isolated, restricted, or awaiting recovery.

invariant: Hazard containment

description: Energy, flow, motion, access, release, decision authority, or data mutation that creates the hazard is bounded or disabled.

invariant: Override accountability

description: Any bypass or manual reset is intentional, visible, time-bounded or condition-bounded, and attributable.

invariant: Recovery discipline

description: Normal operation resumes only after verification that the trigger condition has been cleared or the risk has been deliberately accepted.

invariant: Contextual appropriateness

description: The chosen safe default reflects domain-specific harm: fail-open may be safer for escape, while fail-closed may be safer for unauthorized release.

outcome: Reduced severity of failures

description: Failures become bounded interruptions, locked states, quarantines, or restricted modes rather than uncontrolled harmful continuations.

outcome: Faster emergency response

description: The system does not wait for lengthy interpretation before entering a defined safe posture.

outcome: Clearer operational authority

description: People know when safety rules outrank ordinary service, productivity, speed, or access goals.

outcome: Lower reliance on perfect human attention

description: The default behavior protects against delayed detection, distraction, incapacity, panic, or ambiguous responsibility.

outcome: More trustworthy recovery

description: The system has a path back to operation that does not simply reset and repeat the hazardous condition.

prose_essence:
Fail-Safe Default is the pattern of deciding, in advance, what a system should do when normal control can no longer be trusted. Instead of letting a failed system keep moving, granting, releasing, deciding, heating, pressurizing, writing, or exposing by accident, the design sends it to the least harmful reachable state. That state may be stopped, open, closed, isolated, quarantined, denied, unlocked, locked, or restricted, depending on which option minimizes harm in context.

The key word is **default**. A fail-safe design does not wait for heroic interpretation during a crisis. It makes the failure behavior part of the structure.

prose_when_to_use:
Use this archetype when continued operation after failure is itself dangerous. The pattern is especially useful when a system can keep acting after losing good information, power, control, authorization, operator attention, or state integrity. It also applies when ambiguity is dangerous: if nobody can tell whether normal operation is safe, the system should not be allowed to proceed as if nothing happened.

Good use cases have a nameable hazard, a reachable safer state, and a recovery rule. Weak use cases occur when no state is clearly safer, when total shutdown would be more harmful than continued operation, or when the real need is continuity rather than safety.

prose_structural_problem:
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.

prose_intervention_logic:
The intervention begins by naming the hazardous failure mode. Designers then choose the least harmful reachable state for that hazard. The state may be fail-closed, fail-open, stopped, isolated, read-only, quarantined, or restricted. Next, the design connects detection or conservative assumption rules to the transition into that state. It makes the state visible, constrains manual override, and defines how recovery or restart can happen without reintroducing the hazard.

This logic is different from simply adding a safety device. An emergency stop, watchdog timer, or trip switch is useful only when embedded in a larger policy: what hazard does it address, what state does it enter, who can override it, how is the state communicated, and what must be true before restart?

prose_key_components:
### Hazardous Failure Mode

This component prevents fail-safe design from becoming a vague safety slogan. It asks: what
exactly becomes dangerous when ordinary control is lost? Defines the specific way failure can create harm if the system continues, remains energized,
keeps acting, exposes assets, or leaves state ambiguous.

### Safe Default State

The state may stop operation, remove energy, deny access, release a lock, isolate a flow,
quarantine data, or restrict capabilities. The right default depends on which outcome minimizes
harm in context. Specifies the least harmful reachable state the system should enter when failure, anomaly, or
loss of control is detected or strongly suspected.

### Failure Detector

Detection may be automatic, manual, procedural, or hybrid. Fail-safe logic must also handle loss
of the detector signal itself when silence is dangerous. Observes signals, thresholds, missing heartbeats, abnormal states, operator actions, or
environmental cues that indicate the system should leave normal operation.

### Shutdown or Isolation Rule

The rule is the operational hinge of the archetype. It must be explicit enough to act under
stress without a prolonged debate over whether safety or availability comes first. Defines the transition from normal operation to the safe default state, including which actions
stop, which flows isolate, and which authority can interrupt continuation.

### Manual Override

Overrides must be bounded, visible, reversible where possible, and accountable. An easy silent
override often becomes the failure mode of the fail-safe itself. Provides a controlled human path to override, sustain, or reset the fail-safe response when
context requires judgment beyond the automated rule.

### Recovery Policy

A fail-safe default is incomplete if it prevents immediate harm but leaves no disciplined path
for inspection, reset, repair, restart, or escalation. Defines how the system returns from the safe default state to normal or restricted operation
without reintroducing the hazard that caused the transition.

### Status Indicator

A clear indicator reduces panic, repeated reset attempts, unsafe workarounds, and accidental
reactivation while the hazard remains unresolved. Makes the current safety state legible to operators, users, dependent systems, or affected
people so the default is not mistaken for normal operation.

prose_common_mechanisms:
### Emergency Stop

Provides an immediate human-triggered interruption that forces machinery, workflow, or action
into a safer stopped state when continuation is hazardous. This is an implementation mechanism: it helps instantiate Fail-Safe Default, but it is not the archetype by itself.

### Dead-Man Switch

Requires continuing confirmation, pressure, presence, or heartbeat; if the signal disappears,
the system assumes loss of control and enters the safe state. This is an implementation mechanism: it helps instantiate Fail-Safe Default, but it is not the archetype by itself.

### Trip Switch or Circuit Trip

Disconnects, interrupts, or isolates energy, flow, or action when a threshold is crossed,
converting abnormal continuation into a bounded safe state. This is an implementation mechanism: it helps instantiate Fail-Safe Default, but it is not the archetype by itself.

### Automatic Shutdown

Uses embedded logic, monitoring, or control software to stop or suspend operation when defined
anomalies, limits, or missing signals occur. This is an implementation mechanism: it helps instantiate Fail-Safe Default, but it is not the archetype by itself.

### Fail-Closed or Fail-Open Design

Selects a physical, procedural, or access-control default that either blocks continuation or
releases passage depending on which state is safer. This is an implementation mechanism: it helps instantiate Fail-Safe Default, but it is not the archetype by itself.

### Safe Mode

Keeps only tightly bounded capabilities active for diagnostics, preservation, or recovery while
preventing the risky parts of full operation. This is an implementation mechanism: it helps instantiate Fail-Safe Default, but it is not the archetype by itself.

### Watchdog Timer

Detects a stuck, unresponsive, or stalled controller by requiring periodic check-ins, then
triggers reset, shutdown, or safe-mode entry. This is an implementation mechanism: it helps instantiate Fail-Safe Default, but it is not the archetype by itself.

### Containment on Alarm

On alarm, closes compartments, quarantines suspect data, isolates a hazard, pauses release, or
blocks propagation until the condition is cleared. This is an implementation mechanism: it helps instantiate Fail-Safe Default, but it is not the archetype by itself.

prose_failure_modes: Common failure modes include choosing the wrong safe state, tuning triggers so poorly that people bypass protection, relying on a detector that fails with the hazard, leaving the safe state ambiguous, allowing casual reset, and creating secondary harm elsewhere in the system. Another serious failure mode is symbolic safety: adding a visible stop button, policy, or alarm while leaving normal operations free to continue dangerously.

prose_neighbor_distinctions:
Fail-Safe Default is distinct from Fault-Tolerant Operation. Fault tolerance asks how function can continue despite partial failure; fail-safe design asks when function should stop or restrict because continuation is hazardous. It is distinct from Graceful Degradation because graceful degradation preserves service at lower quality, while fail-safe behavior may sacrifice service entirely. It is distinct from Failover because failover activates alternate capacity; fail-safe behavior chooses a least-harmful state. It is distinct from Circuit Breaker and Load Shedding because those interrupt flows to prevent overload or cascade, while fail-safe default is a broader default-state pattern.

Protective Shutdown is best treated here as a shutdown-oriented variant unless review shows it needs its own full entry. Safe Mode Operation remains a merge-review variant because it may become distinctive when restricted diagnostic operation, capability limits, and exit criteria dominate the structure.

prose_cross_domain_examples: In rail operations, uncertain signal state defaults to stop or restricted movement rather than ordinary speed. In industrial machinery, emergency stop or guard interlock removes hazardous motion or energy. In cybersecurity, privileged access fails closed when authorization cannot be verified. In building safety, exit paths may fail open under fire alarm or power loss. In data systems, suspect records are quarantined instead of published or used in automated decisions. In organizational governance, a risky automated process may pause to human review when anomaly thresholds are crossed.

prose_non_examples: A backup generator is not Fail-Safe Default when its purpose is to keep a critical function running; that is redundant backup provisioning or fault-tolerant operation. A website that lowers quality under load is graceful degradation. A chaos exercise is not the archetype, though it may test fail-safe behavior. A warning label with no state transition is not a fail-safe default. An emergency stop button that is untested, undocumented, and easy to ignore is a mechanism-shaped artifact, not a complete fail-safe design.

prose_tradeoffs: Fail-safe defaults trade availability for harm reduction. They may interrupt service, deny access, freeze outputs, or stop production. They can also create false positives, operational frustration, and incentives to bypass. The fail-open versus fail-closed choice is often politically and ethically charged: security, privacy, escape, accessibility, continuity, and life safety can point to different defaults. The strongest designs make these tradeoffs explicit rather than hiding them inside technical defaults.

prose_invariants_to_preserve: The first invariant is harm minimization: the safe state must reduce expected harm relative to uncontrolled continuation. The second is unambiguous state: affected people and dependent systems should be able to tell whether the system is normal, safe-stopped, isolated, restricted, or awaiting recovery. The third is hazard containment: energy, motion, flow, data mutation, release, access, or decision authority should not continue in the hazardous form. The fourth is accountable override. The fifth is recovery discipline: reset should not be easier than understanding why the system entered the safe state.

prose_target_outcomes: A good fail-safe default turns catastrophic or ambiguous failure into bounded interruption, containment, or restricted operation. It reduces reliance on perfect human attention, clarifies authority during emergencies, prevents accidental continuation, and makes recovery safer. In mature systems it also generates learning: every safe-state entry becomes evidence about thresholds, hazards, bypass pressure, and recovery design.

prose_parameter_dimensions:
- **Safe-state choice:** The most important tuning decision is whether the system should stop, open, close, isolate, deny, release, quarantine, or restrict. There is no universal answer; the safe default depends on the hazard.
- **Trigger sensitivity:** Sensitive triggers protect earlier but can create nuisance trips. Insensitive triggers preserve availability but may allow harm to accumulate.
- **Automation level:** Fully automatic transitions are fast, but human judgment may be needed for ambiguous contexts. Hybrid designs often combine automatic entry with governed override.
- **Override friction:** Override should be possible when rescue or context requires it, but difficult enough that it does not become normal operating practice.
- **Recovery strictness:** Restart criteria can range from simple reset to inspection, second approval, cooldown, test pass, or staged controlled reentry.
- **Scope of restriction:** A fail-safe can disable a component, a pathway, a whole system, a privilege class, a data pipeline, or a decision authority.

prose_variants_and_near_names:
Important variants include Protective Shutdown, Safe Mode Operation, Fail-Closed Default, Fail-Open Default, and Passive Safe Default. Near names include fail-safe design, safe default, fail-to-safe, emergency stop, dead-man switch, trip switch, watchdog timer, and controlled shutdown. The near names should not all become standalone archetypes: many are mechanisms or narrower subtypes.

The fail-open/fail-closed distinction is especially important. In access control, failing closed may prevent unauthorized entry. In evacuation or pressure relief, failing open may prevent trapping people or building dangerous pressure. The archetype does not choose one default universally; it forces context-specific default-state reasoning.

Protective Shutdown

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

distinctive_feature: The safe default is primarily a stop, halt, trip, or shutdown rather than a restricted continuation state.

distinct_from_parent: The parent archetype covers any least-harmful default; protective shutdown is the narrower case where stopping is the safe default.

still_same_parent_because: The underlying intervention is still defaulting to a safer state under failure rather than optimizing continuation.

use_when: Continuation under abnormal conditions can create unacceptable physical, operational, financial, clinical, or legal harm.

use_when: A stopped or isolated state is safer than a degraded continuation mode.

use_when: Restart should require inspection, reset, or authorization.

Shutdown or Isolation Rule

role: Defines the stopping action and what must be isolated or de-energized.

notes: The rule should distinguish emergency stop, orderly shutdown, and maintenance lockout when those require different actions.

Recovery Policy

role: Prevents casual restart before the hazard is inspected or cleared.

notes: Shutdown without disciplined restart can either strand the system or encourage unsafe reset attempts.

Emergency Stop

role: Gives operators a direct interrupt path when the hazard is visible before automated detection acts.

Trip Switch

role: Converts a measured unsafe condition into an automatic stop or isolation action.

example_domains:
industrial equipment
utilities
financial controls
clinical devices

domain: Industrial equipment

example: A saw or press stops when an emergency-stop control is hit.

domain: Finance

example: A trading system halts a strategy when loss or anomaly limits are breached.

failure_modes: Nuisance shutdowns become so frequent that operators bypass the protection.

failure_modes: Restart criteria are vague, causing repeated reactivation while the hazard remains present.

Safe Mode Operation

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

distinctive_feature: The safe default is not a complete stop; it is a bounded mode with explicitly limited capabilities.

distinct_from_parent: The parent chooses a least-harmful state; this variant emphasizes restricted continued operation for diagnosis or recovery.

still_same_parent_because: Its entry logic and boundary are still fail-safe: block hazardous behavior first, then allow only safe capabilities.

use_when: Full operation is unsafe, but total shutdown would block inspection, preservation, communication, or controlled recovery.

use_when: The system can separate safe diagnostic capabilities from risky production capabilities.

use_when: Exit criteria can be defined so safe mode does not become an unbounded degraded state.

Diagnostic Access Path

role: Allows investigation while risky functions remain disabled.

notes: Without this component, safe mode either becomes full shutdown or hidden degraded operation.

Capability Limit

role: Names the specific actions disabled in safe mode.

notes: Capability limits keep safe mode from becoming an excuse to run normally while impaired.

Read-Only Mode

role: Allows inspection or retrieval while blocking writes, actuation, release, or irreversible changes.

Maintenance Mode

mechanism_type: workflow

role: Restricts normal use while preserving controlled access for repair or diagnosis.

example_domains:
software systems
medical devices
public agencies
vehicles

domain: Software

example: A service enters read-only mode after detecting data-integrity risk.

domain: Vehicle systems

example: A device enters limp or diagnostic mode after detecting abnormal operation.

failure_modes: Safe mode becomes a persistent degraded service without review or exit criteria.

failure_modes: Restricted capabilities are too broad, so the mode still exposes users to the hazard.

Fail-Closed Default

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

distinctive_feature: The safe state is closure, denial, blocking, or non-release.

distinct_from_parent: The parent does not require closure; some contexts are safer when they fail open.

still_same_parent_because: Closure is one way of implementing the least-harmful reachable state under failure.

use_when: Unauthorized continuation, release, entry, movement, or write action is more dangerous than denial or stoppage.

use_when: Blocking action does not trap people, prevent escape, or create a worse physical hazard.

Safe Default State

role: Defines what closure means in the domain.

notes: Closure may block access, prevent release, halt a transaction, or stop flow.

Default-Deny Rule

mechanism_type: protocol

role: Denies requests, privileges, or releases unless valid permission or safe conditions are confirmed.

example_domains:
access control
data release
industrial valves
payment systems

domain: Data governance

example: Unvalidated data is quarantined rather than published.

domain: Security

example: Access is denied if authorization cannot be verified.

failure_modes: Fail-closed logic can create lockout, denial of needed service, or trapped actors if life-safety escape is ignored.

Fail-Open Default

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

distinctive_feature: The safe state is opening, venting, releasing, unlocking, or allowing escape.

distinct_from_parent: The parent includes both fail-open and fail-closed defaults; this variant names the release-oriented branch.

still_same_parent_because: The intervention is still a contextual choice of the least-harmful default state under failure.

use_when: Blocking, locking, or containing under failure would trap people, build pressure, block evacuation, or create a more severe hazard.

use_when: The risk of release is lower than the risk of confinement or denial.

Hazardous Failure Mode

role: Identifies when trapped, pressurized, or denied states are the actual hazard.

notes: This prevents security-style closure from overriding life-safety or pressure-release logic.

Spring-Return Open Valve

role: Uses mechanical bias so loss of control energy returns the device to an open or venting state.

example_domains:
fire safety
pressure systems
evacuation design
public facilities

domain: Building safety

example: An exit unlocks during fire alarm or power failure.

domain: Process safety

example: A relief path opens to reduce dangerous pressure.

failure_modes: Fail-open can expose assets, people, data, or environments if release is safer locally but harmful systemically.

Passive Safe Default

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

distinctive_feature: The safety transition depends on passive bias rather than a complex active controller.

distinct_from_parent: The parent can use active detection and control; passive safe defaults reduce dependence on the very systems that may fail.

still_same_parent_because: The core is still selecting a least-harmful default under failure.

use_when: Active control may be unavailable at exactly the moment safety is needed.

use_when: Gravity, springs, physical geometry, default permissions, or simple procedural rules can bias the system toward harmless behavior.

Safe Default State

role: Names the state the system drifts or snaps toward without active control.

notes: The state must remain safe under foreseeable loss-of-control conditions.

Spring-Return Mechanism

role: Uses physical bias to return a switch, valve, lever, or gate to its safe position when active force is removed.

example_domains:
mechanical design
interface design
access control
organizational procedure

domain: Interface design

example: A destructive action requires deliberate hold-to-confirm rather than remaining armed by default.

domain: Mechanical systems

example: Loss of actuation returns a component to a harmless rest position.

failure_modes: Passive defaults can be mistaken for sufficient safety when detection, recovery, or override governance is still needed.

near_names:
Fail-Safe Design
Safe Default
Safe Default State
Emergency Stop
Dead-Man Switch
Safe Mode
Controlled Shutdown


Failover

type: archetype

slug: failover

related_primes: redundancy fault_tolerance resilience robustness flow coupling observability state_and_state_transition transaction data_integrity resource_management threshold boundary

essence_one_line: Switch a protected function from a failed primary path to a prepared alternate so continuity is preserved.

prose_failure_modes:
Common failure modes include:

- **False failover** — The system switches away from a viable primary due to misleading signals.
- **Failover loop** — The system repeatedly switches between paths, creating instability.
- **Split-brain** — Primary and alternate both act as authoritative, causing conflict or corruption.
- **Stale backup state** — The alternate lacks current state and produces incorrect behavior.
- **Shared failure domain** — The alternate fails for the same reason as the primary.
- **Untested standby** — Backup capacity exists on paper but fails when activated.
- **Partial switchover** — Some flows move to the alternate while others remain on the failed primary.
- **Lost in-flight work** — Work underway at the moment of failure is duplicated, dropped, or corrupted.
- **Failback corruption** — Returning to the primary overwrites or conflicts with state created during failover.
- **Backup capacity exhaustion** — The alternate cannot handle the transferred load.
- **Ambiguous ownership** — Actors do not know who or what is responsible after transfer.
- **Cascading failover** — Failover load overwhelms the alternate and spreads failure.

These failure modes should be treated as part of the archetype's design space.

prose_tradeoffs:
Failover accepts preparation, duplication, and coordination costs in order to preserve continuity.

Typical tradeoffs include:

- **Duplicated capacity cost** because alternate capacity must exist.
- **Synchronization overhead** because state, data, context, or authority may need to be kept current.
- **Switchover complexity** because failure detection and transfer rules must be reliable.
- **Split-brain risk** when primary and alternate both believe they own the function.
- **Stale-state risk** if the alternate is not fully current.
- **Underused backup resources** when standby capacity sits idle.
- **Testing and maintenance burden** because failover mechanisms must be exercised.
- **False failover risk** if the system switches unnecessarily.
- **Failback complexity** when returning to the original primary.

The archetype is therefore a continuity strategy, not a free resilience upgrade.

prose_invariants_to_preserve:
Failover should preserve explicit invariants:

- **Protected function continues or fails cleanly** — The system should not enter ambiguous half-service.
- **State integrity is preserved** — Failover should not corrupt, duplicate, or silently lose critical state.
- **Ownership is unambiguous** — There should not be two primaries acting independently unless the system is designed for that.
- **In-flight work is handled safely** — Work should be completed, retried, rolled back, or cleanly rejected.
- **Trigger is observable and auditable** — Operators or mechanisms should know why failover occurred.
- **Alternate readiness is maintained** — Backup capacity should be sufficiently current, tested, and reachable.
- **Recovery does not corrupt state** — Returning to the primary should not overwrite, duplicate, or fork state.

If these invariants cannot be preserved, failover may be more dangerous than outage.

Primary / Secondary Switchover

short_definition: Switch from a primary component, route, or actor to a prepared secondary alternative when the primary fails.

distinctive_feature: The distinctive feature is a prepared primary-secondary role structure.

distinct_from_parent: Failover is general alternate-path activation; this variant uses a primary/secondary standby design.

still_same_parent_because: It remains failover because the intervention is switching function to an alternate path.

use_when: A secondary path exists and can assume function.

example_domains:
SRE
power systems
operations
governance

failure_modes: Split-brain or conflicting active paths occur.


Failure Mode Anticipation

source: generated

batch: First Iteration/Batch 46

aliases:
Failure Mode Discovery
Anticipatory Failure Analysis
Prospective Failure Analysis
Pre-Implementation Failure Analysis
Failure Path Mapping
Failure Scenario Anticipation

source_primes: fmea robustness uncertainty

related_primes: causality observability feedback constraint counterfactual_reasoning controllability complexity probability resilience cost_benefit_analysis scenario_planning

slug: fmea

slug: uncertainty

slug: causality

slug: feedback

slug: constraint

slug: complexity

slug: probability

components:
Function or Requirement
Failure Mode
Failure Cause
Failure Effect
Risk Priority
Mitigation Action
Detection Signal
Residual Risk Decision
Severity Scale
Likelihood Estimate
Detectability Estimate
Failure Owner
Review Trigger

mechanisms:
Failure Modes and Effects Analysis
Hazard Analysis
Premortem Workshop
Fault Tree Analysis
Risk Register
Safety Case
Design Review
Failure Scenario Review
Incident Pattern Review

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

compression_statement: When a solution could fail in multiple ways, anticipate failure modes, causes, and effects early enough to redesign or mitigate the most serious risks.

core_intuition: Failure is easier to prevent when it is named before the system has hardened around it. By separating what can fail, why it could fail, what would happen, how it would be noticed, and what action is justified, a team converts vague anxiety into accountable design change.

canonical_formula: function or requirement → failure mode → cause → effect → priority → mitigation action → detection signal → residual-risk decision

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

condition: A design is about to move from concept, prototype, or plan into committed implementation.

why_it_matters: Early commitment makes future redesign more expensive; failure review is most valuable before decisions harden.

condition: Failure could produce harm, outage, rework, exclusion, liability, loss of trust, wasted resources, or irreversible downstream effects.

why_it_matters: The cost of discovering failure only after launch is high enough to justify systematic anticipation.

condition: The solution depends on multiple components, handoffs, roles, incentives, assumptions, data flows, or environmental conditions.

why_it_matters: Interactions create failure paths that are invisible when each element is considered alone.

condition: Past incidents, near misses, complaints, defects, support tickets, or workarounds suggest recurrent vulnerabilities.

why_it_matters: Existing patterns can reveal plausible future failure modes before they recur in the new design.

condition: The team is relying on expertise, enthusiasm, regulatory compliance, or standard procedure as proof that the design will work.

why_it_matters: Formal correctness and expert confidence can hide context-specific failure modes.

condition: The implementation context will vary across sites, users, loads, conditions, jurisdictions, or time.

why_it_matters: Variation can turn a locally sound design into a brittle design when conditions change.

symptom: Design discussion treats failure as a generic risk instead of naming concrete ways the function can fail.

interpretation: The team has concern without a structured unit of analysis.

symptom: Risk conversations focus on probability scores before causes, effects, or detection paths are understood.

interpretation: The analysis is prematurely quantifying uncertainty instead of making failure logic inspectable.

symptom: Mitigations are broad reminders, training, or vigilance demands rather than changes to design, controls, monitoring, or operating conditions.

interpretation: The system still depends on perfect attention and has not absorbed the failure insight.

symptom: Important failure concerns are raised informally but disappear because no owner, priority, or decision record exists.

interpretation: The organization lacks a traceable path from concern to action.

symptom: The same category of incident repeats after each launch, handoff, policy revision, or process change.

interpretation: Learning from prior failure has not been converted into anticipatory design review.

symptom: Teams disagree about whether a risk is acceptable because severity, likelihood, detectability, reversibility, and ethical thresholds are implicit.

interpretation: Residual-risk decisions are being made without shared criteria.

root_tension: Design requires committing to a path despite uncertainty, but implementation exposes hidden assumptions, dependencies, and edge cases. The archetype resolves this tension by making likely failure paths explicit early enough for redesign, prevention, detection, or deliberate acceptance.

case: The issue is already an active incident requiring immediate containment.

why_not: Use incident response, containment, triage, or recovery first; failure-mode anticipation may be used afterward for prevention.

case: The question is choosing among already-characterized options under uncertainty rather than discovering how one design can fail.

why_not: Robust solution selection, cost-benefit analysis, or decision analysis may be more appropriate.

case: The only concern is predictable user error at a point of action.

why_not: Error-Proofing Design may be the more direct archetype, though failure anticipation can identify which errors deserve proofing.

case: The system is simple, low-stakes, reversible, and cheap to correct after launch.

why_not: A lightweight prototype or feedback loop may be sufficient; heavy failure analysis can create unnecessary delay.

case: The analysis is being used to rationalize inaction, spread blame, or create compliance theater.

why_not: The archetype requires mitigation, residual-risk decisions, and ownership, not paperwork that protects decision makers from accountability.

structural_intervention: Map functions, identify failure modes and causes, assess effect severity and detectability, prioritize risk, and assign prevention/mitigation actions.

action: Define the function, requirement, workflow step, control, policy promise, or design assumption to be protected.

rationale: Failure must be anchored to what the solution is supposed to do.

output: A bounded unit of analysis.

action: Name concrete failure modes for that unit under realistic operating conditions and stressors.

rationale: Specific failure modes make vague risk inspectable and debatable.

output: A list of possible ways the unit can fail.

action: Analyze causes, contributing conditions, dependencies, and interaction paths for each failure mode.

rationale: Causes point toward prevention, constraint, redesign, or monitoring.

output: A causal explanation or scenario path.

action: Describe effects from the viewpoint of users, operators, systems, affected parties, obligations, resources, and downstream dependencies.

rationale: Effects determine why the failure matters and who bears its cost.

output: A consequence description with relevant scope and severity.

action: Prioritize failure modes using severity, likelihood, detectability, reversibility, equity, evidence quality, and strategic importance as appropriate.

rationale: Not every possible failure can receive equal attention; prioritization directs effort.

output: Risk priority or treatment category.

action: Assign prevention, mitigation, detection, contingency, escalation, or explicit residual-risk acceptance actions.

rationale: The analysis becomes real only when it changes design or operating control.

output: Action record with owner and decision status.

action: Verify that mitigations actually reduce the failure path and set review triggers for future change.

rationale: Controls can fail too, and failure modes evolve as the design scales or context changes.

output: Residual-risk decision, detection plan, and review trigger.

rule: Prioritize severe, irreversible, hidden, or ethically unacceptable effects even when likelihood is uncertain.

reason: Low-frequency high-consequence failures should not be dismissed merely because precise probabilities are unavailable.

rule: Prefer eliminating or constraining causes over relying on training, reminders, or heroic attention.

reason: Design-level prevention is usually more reliable than memory-dependent control.

rule: Treat low detectability as a priority amplifier.

reason: Failures that are not noticed can accumulate, spread, or harm people before response is possible.

rule: Require an owner and review trigger for any mitigation that remains open at commitment time.

reason: Unowned mitigations become wishful thinking.

rule: Escalate residual-risk decisions when they involve safety, rights, legal obligations, vulnerable groups, or irreversible harm.

reason: Some risks require explicit authority and ethical review rather than local acceptance.

rule: Re-run the analysis when the function, scale, user population, operating context, dependency, or regulatory environment changes.

reason: A valid failure review is bounded by assumptions that may later become false.

invariant: Concrete failure-mode naming

why: The archetype fails if risk remains abstract.

invariant: Cause-effect separation

why: Confusing causes, modes, and effects leads to weak mitigations.

invariant: Actionable prioritization

why: The review must guide decisions under limited attention and resources.

invariant: Design or control change

why: A recorded risk without prevention, mitigation, detection, or explicit acceptance is not sufficient.

invariant: Residual-risk accountability

why: Remaining risk must be visible to the people authorized to accept, reject, or escalate it.

invariant: Context-bound validity

why: Failure modes depend on actual users, environments, loads, incentives, maintenance, and organizational capacity.

outcome: Earlier discovery of serious design weaknesses

indicator: High-priority failure modes are found before full launch or irreversible commitment.

outcome: Reduced preventable harm, rework, downtime, and support burden

indicator: Mitigations remove causes, add controls, or improve detection before failure escapes.

outcome: Clearer design rationale and accountability

indicator: Decisions show why some risks were treated, monitored, escalated, or accepted.

outcome: Improved robustness under variation and stress

indicator: The solution handles realistic operating conditions, edge cases, and dependencies more gracefully.

outcome: Better learning from past incidents and near misses

indicator: Prior failures are converted into prospective controls for new designs.

prose_essence:
Failure Mode Anticipation is the pattern of asking, before commitment, how a proposed solution could fail and what should change because of that knowledge. It is not the same as filling out an FMEA table, holding a design review, or maintaining a risk register. Those can be mechanisms. The archetype is the full chain from a defined function or requirement to a concrete failure mode, plausible cause, expected effect, priority, mitigation, detection signal, and residual-risk decision.

The archetype matters because failure usually looks obvious in hindsight. After launch, people can often say which handoff was brittle, which assumption was wrong, which warning sign was ignored, or which dependency was undocumented. Failure Mode Anticipation pulls some of that hindsight forward while the design can still be changed.

prose_when_to_use:
Use this archetype when a solution is specific enough to analyze but not yet too expensive to change. It is especially useful before full release, scale-up, handoff, procurement, policy rollout, safety approval, workflow standardization, or major operational change.

It is strongest when failure would cause harm, outage, rework, exclusion, loss of trust, legal exposure, wasted resources, or irreversible downstream effects. It also applies when a design depends on multiple components, roles, incentives, data flows, handoffs, environments, or user behaviors. Those interactions are where many failures hide.

Do not use a heavy version of this archetype for every small reversible experiment. A low-cost prototype, staged release, or ordinary feedback loop may be enough when failure is cheap, visible, and easily corrected. Use proportionate depth.

prose_structural_problem:
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?

prose_intervention_logic:
The intervention starts by naming the function or requirement being protected. The team then asks how that function could fail under realistic conditions. For each failure mode, it separates causes from effects. Causes point toward prevention or redesign. Effects explain why the failure matters and who bears the cost.

The next step is priority. Not every failure deserves the same effort. Priority may consider severity, likelihood, detectability, reversibility, equity, legal obligation, evidence quality, strategic importance, and whether the failure is ethically unacceptable even if rare. The final step is treatment: remove the cause, constrain the action path, add monitoring, create fallback, assign an owner, change the design, or explicitly escalate residual risk.

The archetype is complete only when insight changes the design or the decision record. A beautiful failure table that does not affect implementation is documentation, not intervention.

prose_key_components:
### Function or Requirement

`function_or_requirement` — Defines the operation, obligation, performance expectation, or design promise whose possible failure is being examined. Failure mode anticipation needs a clear reference function. Without it, the analysis drifts into vague worry because no one knows what the design is supposed to preserve, deliver, or prevent.
### Failure Mode

`failure_mode` — Names a specific way the function, requirement, workflow, control, policy, or interface could fail. A useful failure mode is concrete enough to investigate and act on. It should distinguish the observable failure from its cause and from its effect.
### Failure Cause

`failure_cause` — Identifies the condition, error, dependency, degradation, assumption, interaction, or external stressor that could produce the failure mode. Cause analysis turns failure naming into redesign logic. Causes may be technical, human, organizational, environmental, incentive-based, informational, or temporal.
### Failure Effect

`failure_effect` — Describes what happens if the failure mode occurs, including harm, loss, delay, rework, exclusion, service degradation, or cascading consequences. Effects are evaluated from the perspective of affected users, operators, systems, rights, safety, resources, and long-term obligations, not only from the designer’s viewpoint.
### Risk Priority

`risk_priority` — Ranks or classifies failure modes so scarce prevention effort is directed toward the most consequential, likely, hard-to-detect, or strategically important risks. Risk priority can be numeric, categorical, deliberative, or scenario-based. It should not hide value judgments behind a false precision score.
### Mitigation Action

`mitigation_action` — Specifies the prevention, redesign, control, detection, fallback, training, documentation, governance, or acceptance action assigned to a prioritized failure mode. The action should change the design or operating system, not merely record the risk. The strongest mitigations remove or constrain the cause rather than relying only on vigilance.
### Detection Signal

`detection_signal` — Defines how the team will know that a failure mode is emerging, has occurred, or has escaped existing controls. Detection signals connect anticipation to monitoring, testing, inspection, feedback, incident reporting, or leading indicators. They reduce the gap between predicted and observed failure.
### Residual Risk Decision

`residual_risk_decision` — Records what risk remains after mitigation and whether that residual risk is accepted, transferred, monitored, escalated, redesigned, or considered unacceptable. This component prevents the analysis from ending at a to-do list. It clarifies who is authorized to accept residual risk and under what evidence or ethical constraints.
### Severity Scale

`severity_scale` — Provides a shared way to compare the seriousness of failure effects across otherwise different failure modes. Severity scales should include human, operational, legal, environmental, reputational, equity, and reversibility dimensions when relevant.
### Likelihood Estimate

`likelihood_estimate` — Estimates how plausible or frequent a failure mode is under defined operating conditions. Likelihood should be explicit about uncertainty, evidence quality, baseline assumptions, and whether rare but catastrophic cases receive special handling.
### Detectability Estimate

`detectability_estimate` — Evaluates whether the failure would be noticed before harm, during operation, after harm, or not at all without new instrumentation. Low detectability often deserves priority even when likelihood is uncertain because silent failures can accumulate or escape accountability.
### Failure Owner

`failure_owner` — Assigns responsibility for preventing, monitoring, or responding to a failure mode. Ownership should map to actual authority and capacity. Assigning a risk to someone without decision rights is a paper control.
### Review Trigger

`review_trigger` — Defines when the failure analysis must be revisited because assumptions, design, use context, regulations, scale, or observed incidents have changed. Failure mode anticipation is not one-time paperwork. Review triggers keep the analysis alive as the system and its environment evolve.

prose_common_mechanisms:
### Failure Modes and Effects Analysis

`failure_modes_and_effects_analysis` — This is a method that can implement Failure Mode Anticipation. Implements the archetype through a structured table or review that maps functions to failure modes, causes, effects, priority, and actions. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.
### Hazard Analysis

`hazard_analysis` — This is a method that can implement Failure Mode Anticipation. Implements the archetype by identifying hazardous states, initiating conditions, exposure paths, controls, and mitigations before operation. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.
### Premortem Workshop

`premortem_workshop` — This is a ritual that can implement Failure Mode Anticipation. Implements the archetype by asking participants to imagine that the solution has failed and then work backward to plausible causes and prevention actions. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.
### Fault Tree Analysis

`fault_tree_analysis` — This is a method that can implement Failure Mode Anticipation. Implements the archetype by decomposing a top failure event into contributing conditions and logical combinations of causes. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.
### Risk Register

`risk_register` — This is a document that can implement Failure Mode Anticipation. Implements the archetype by maintaining a living record of failure modes, priorities, owners, mitigation status, detection signals, and residual-risk decisions. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.
### Safety Case

`safety_case` — This is a document that can implement Failure Mode Anticipation. Implements the archetype by linking identified failure modes and controls to an evidence-backed argument that the system is acceptably safe for a defined context. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.
### Design Review

`design_review` — This is a ritual that can implement Failure Mode Anticipation. Implements the archetype when the review explicitly searches for failure paths, tests assumptions, assigns actions, and checks whether mitigations change the design. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.
### Failure Scenario Review

`failure_scenario_review` — This is a method that can implement Failure Mode Anticipation. Implements the archetype by walking through plausible failure stories across time, handoffs, dependencies, and stress conditions. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.
### Incident Pattern Review

`incident_pattern_review` — This is a method that can implement Failure Mode Anticipation. Implements the archetype by using past incidents, near misses, complaints, defects, audits, or support patterns to anticipate similar failures in a new design. It is not the archetype itself; it is one way to organize or carry out the anticipatory analysis.

Mechanism choice should follow the shape of the failure problem. A decomposable component design may need FMEA-style analysis. A harm pathway may need hazard analysis or a safety case. A politically committed team may need a premortem to surface dissent. A complex causal combination may need a fault tree. A long implementation program may need a risk register to track ownership and residual-risk decisions.

prose_failure_modes:
The most common failure is checklist theater: a table is completed, approved, and archived without changing the design. Another common failure is false precision scoring, where numbers make weak judgments look objective. A third is single-perspective blindness: the review includes experts but not operators, maintainers, users, implementers, or affected groups.

Other failure modes include unowned mitigation, residual-risk laundering, cause-effect confusion, paralysis by exhaustive risk, and overreliance on training or vigilance. These failures are mitigated by requiring concrete entries, role diversity, decision authority, owner assignment, review triggers, and explicit escalation for high-stakes residual risks.

prose_neighbor_distinctions:
**Error-Proofing Design** designs systems so common errors are impossible, constrained, or immediately detected. Failure Mode Anticipation may reveal the need for error-proofing, but it covers broader failure paths.

**Fail-Safe Default** defines what safe state the system should enter when failure occurs. Failure Mode Anticipation discovers which failures could occur and whether fail-safe defaults are needed.

**Robust Solution Selection** chooses among options that perform acceptably under uncertainty. Failure Mode Anticipation analyzes how a particular design could fail and what should be changed.

**Safety Margin Design** adds reserve capacity, tolerance, or buffer. Failure Mode Anticipation can identify where margins are warranted, but it is not the margin itself.

**Rapid Prototype Learning Loop** tests assumptions through low-cost artifacts. Failure Mode Anticipation can use prototype evidence, but it does not require a prototype; it requires structured prospective failure reasoning.

**Implementation Feasibility Alignment** checks whether real-world implementation constraints, capacities, incentives, and workflows fit the design. Failure Mode Anticipation asks how the design or implementation could fail and what treatments are justified.

prose_cross_domain_examples:
In medical device implementation, Before deploying a home-monitoring device, the team identifies failure modes including battery depletion, misplacement, incorrect alerts, missed follow-up, and low-connectivity households. The analysis maps causes, effects, detection gaps, mitigations, and residual risk before broad use.

In public benefits policy, Before changing eligibility renewal, an agency anticipates documentation failures, identity-verification errors, appeal bottlenecks, digital access gaps, and erroneous denials. The policy could fail through administrative and user-context pathways that can be redesigned or monitored.

In data platform, A team reviews a new data ingestion process for schema drift, duplicate records, permission mismatches, retry storms, and silent downstream corruption. The review prioritizes hard-to-detect failures and assigns observability and fallback actions.

In manufacturing process, Before adding a new assembly step, the team identifies incorrect part orientation, skipped torque check, tool wear, sensor miscalibration, and inspection escape. Concrete failure modes can be prevented through fixtures, interlocks, maintenance, detection, and training changes.

In organizational change, Before rolling out a new approval workflow, leaders anticipate bottlenecks, unclear ownership, escalation failures, workaround channels, and incentive conflicts. The design can fail through roles, incentives, and handoffs rather than technical defects.

The extended permit-system example in the front matter shows the same structure in a public-service setting: define functions, identify failure modes, analyze causes and effects, prioritize hard or harmful failures, assign mitigations, and set review triggers.

prose_non_examples:
A team says “this might fail” in a meeting and moves on. This is not the archetype because No failure mode, cause, effect, priority, mitigation, or residual-risk decision is created.

A generic project risk register lists “user adoption risk” without explaining how adoption could fail. This is not the archetype because The risk is too abstract to guide redesign or detection.

A completed FMEA table is filed away after approval and never changes the design. This is not the archetype because The mechanism was used, but the intervention logic did not occur.

A team adds a safety margin without analyzing which failure modes the margin addresses. This is not the archetype because A margin can be a mitigation, but it is not the anticipatory mapping and prioritization pattern.

An incident postmortem diagnoses a failure that already happened. This is not the archetype because Postmortems can feed future anticipation, but the immediate activity is retrospective diagnosis.

prose_tradeoffs:
Failure Mode Anticipation takes time and can slow commitment. That cost is justified when late failure would be harmful or expensive, but excessive analysis can delay reversible learning. The right level is proportionate to stakes and uncertainty.

Structured scoring helps compare many risks, but it can create false precision. A high-quality draft should record evidence quality and ethical thresholds, not only numerical priority.

Broad participation improves realism, but it can also expand the review into every imaginable concern. Good facilitation turns concerns into failure modes, causes, effects, priorities, and actions.

Mitigation can introduce new complexity. A control that prevents one failure may create another: delay, burden, alert fatigue, exclusion, maintenance cost, or bypass incentives. Mitigations should be reviewed as design changes with their own failure modes.

prose_invariants_to_preserve:
Preserve concrete failure-mode naming. The archetype loses force when risks remain generic labels such as “adoption risk,” “quality risk,” or “operational risk.”

Preserve the distinction between mode, cause, and effect. A failure mode names how the function fails; a cause explains why; an effect explains what happens because of it. Mixing these together creates weak mitigations.

Preserve actionability. Every high-priority failure mode should lead to prevention, mitigation, detection, escalation, or explicit residual-risk decision.

Preserve accountability. Mitigation actions require owners with actual authority, capacity, and review paths.

Preserve context validity. Failure modes depend on operating conditions, users, maintainers, incentives, time pressure, load, regulation, and environment. A review done in one context does not automatically transfer to another.

Preserve ethical seriousness. Residual risk is not acceptable merely because it has been documented. Some harms require redesign, escalation, or refusal.

prose_target_outcomes:
The primary outcome is earlier discovery of serious weaknesses before they become expensive, harmful, or politically difficult to correct. The design should emerge with fewer preventable failure paths, clearer controls, better detection, and more explicit residual-risk decisions.

A second outcome is better organizational memory. Past incidents, near misses, support burden, audits, and user workarounds become prospective design evidence rather than stories rediscovered after each launch.

A third outcome is improved accountability. The team can show which failure modes were considered, why some were prioritized, what actions were assigned, who owns them, and what risk remains.

prose_parameter_dimensions:
**Scope of analysis.** The unit can be a component, workflow step, interface, policy rule, operating process, data pipeline, service journey, or whole system. Wider scope catches interactions but can become too vague; narrower scope supports action but may miss system-level failure.

**Depth of causal analysis.** Some contexts need a simple cause list. Others need fault trees, scenario paths, barrier analysis, or evidence-backed safety arguments. Depth should rise with consequence, complexity, novelty, and uncertainty.

**Priority method.** Priority can be numeric, categorical, deliberative, evidence-weighted, threshold-based, or scenario-based. Numeric scoring can help compare entries, but it must not hide weak evidence or contested values.

**Participation breadth.** Designers, engineers, operators, maintainers, users, implementers, support teams, safety experts, regulators, and affected groups see different failure paths. Wider participation improves coverage but needs facilitation and clear scope.

**Risk tolerance and escalation.** Some residual risks can be accepted locally. Others require executive, regulatory, ethical, legal, or affected-party review. Safety, rights, irreversible harm, vulnerable groups, and silent failures should lower the threshold for escalation.

**Review cadence.** A one-time review may be enough for a stable low-risk change. Dynamic systems need review triggers tied to scale, context, incidents, new dependencies, user populations, maintenance changes, or regulatory shifts.

prose_variants_and_near_names:
### FMEA-Style Failure Analysis

Uses a structured failure-mode, effect, cause, scoring, and action record to anticipate design weaknesses before release or operation. Its distinctive feature is: The variant emphasizes systematic tabulation and prioritization rather than scenario storytelling alone. It remains within Failure Mode Anticipation because It still maps failure modes, causes, effects, priorities, mitigations, and residual risk before implementation.
### Hazard Path Analysis

Anticipates failures by tracing how a hazardous state could arise, what exposure paths it creates, and which barriers can interrupt the path. Its distinctive feature is: The variant focuses on causal pathways to harm and on barriers that break those pathways. It remains within Failure Mode Anticipation because It still anticipates failure before implementation and assigns prevention, detection, and residual-risk treatment.
### Premortem Failure Anticipation

Imagines that the solution has already failed, then reasons backward to plausible causes, warning signs, and preventive changes. Its distinctive feature is: The variant uses a future-failure story as a cognitive frame for surfacing hidden assumptions and dissent. It remains within Failure Mode Anticipation because The output still identifies failure modes, causes, detection signals, mitigation actions, and residual-risk decisions.
### Operational Failure Mode Mapping

Maps how a workflow, service, or operating process can fail at handoffs, dependencies, staffing constraints, data flows, and exception paths. Its distinctive feature is: The variant treats the operating process as the unit of analysis rather than only the product, component, or policy text. It remains within Failure Mode Anticipation because It still anticipates failures before broader implementation and assigns mitigation, monitoring, and residual-risk decisions.
### Policy Failure Mode Anticipation

Applies failure-mode anticipation to policy designs, administrative rules, incentives, enforcement paths, equity effects, and implementation constraints. Its distinctive feature is: The variant treats rules, incentives, administrative capacity, and affected populations as design elements that can fail. It remains within Failure Mode Anticipation because It still identifies failure modes, causes, effects, priorities, mitigations, detection signals, and residual risk before implementation.

Near names include FMEA, Failure Modes and Effects Analysis, prospective failure analysis, premortem, hazard analysis, risk assessment, fault tree analysis, and risk register. Most of these should be treated as mechanisms, variants, or aliases rather than standalone archetypes. The parent archetype should remain the general intervention pattern: anticipate failure modes before implementation and turn that anticipation into prevention, mitigation, detection, or residual-risk decisions.

FMEA-Style Failure Analysis

distinctive_feature: The variant emphasizes systematic tabulation and prioritization rather than scenario storytelling alone.

distinct_from_parent: The parent is the general anticipatory failure intervention; this variant is the structured FMEA-inspired method form.

still_same_parent_because: It still maps failure modes, causes, effects, priorities, mitigations, and residual risk before implementation.

source_primes: fmea robustness

condition: A design can be decomposed into functions, steps, components, controls, or requirements.

reason: FMEA-style records work best when there is a stable unit of analysis.

condition: Several failure modes compete for limited prevention resources.

reason: Severity, likelihood, and detectability estimates help prioritize action.

condition: The organization needs a traceable record of decisions and owners.

reason: The structured table supports accountability and later review.

Function or Requirement

role: Defines the unit being analyzed.

Failure Mode

role: Names each possible way the unit can fail.

Failure Effect

role: Describes consequence if the failure occurs.

Risk Priority

role: Ranks attention and mitigation effort.

Mitigation Action

role: Assigns prevention or control changes.

Failure Modes and Effects Analysis

mechanism_type: method

role: Provides the structured review format.

FMEA Table

mechanism_type: template

role: Records failure-mode analysis output.

Risk Register

mechanism_type: document

role: Tracks open actions and residual risk.

example_domains: engineering healthcare operations product_design

domain: Healthcare

example: A medication handoff process is decomposed into steps, with each failure mode prioritized before the protocol is launched.

domain: Manufacturing

example: A new assembly fixture is reviewed for incorrect orientation, skipped fasteners, sensor drift, and inspection escapes.

failure_mode: Score theater

mitigation: Require action rationale, evidence quality, owner, and residual-risk decision rather than relying only on a numeric score.

failure_mode: Component tunnel vision

mitigation: Review interfaces, handoffs, maintenance, users, and operating context as well as components.

Hazard Path Analysis

variant_type: subtype

distinctive_feature: The variant focuses on causal pathways to harm and on barriers that break those pathways.

distinct_from_parent: The parent includes many failure-prioritization forms; this variant is organized around hazard emergence and interruption.

still_same_parent_because: It still anticipates failure before implementation and assigns prevention, detection, and residual-risk treatment.

source_primes: causality robustness constraint

condition: The main concern is harm, exposure, unsafe state, rights violation, or environmental damage.

reason: Hazard framing foregrounds consequences and barriers.

condition: Failure results from combinations of events rather than a single component defect.

reason: Path analysis can represent multiple contributing causes and controls.

Failure Cause

role: Identifies initiating and contributing conditions.

Failure Effect

role: Frames harm or loss that the hazard produces.

Mitigation Action

role: Defines barriers, controls, or redesigns that interrupt the path.

Detection Signal

role: Indicates when the hazardous state is emerging or uncontained.

Hazard Analysis

role: Maps hazardous states and controls.

Fault Tree Analysis

role: Decomposes causal combinations.

Safety Case

role: Links hazard controls to evidence.

example_domains: safety infrastructure policy environmental_design

domain: Infrastructure

example: A flood-control project maps failure paths from sensor outage, blocked drainage, delayed alerts, and evacuation bottlenecks.

domain: Digital services

example: A data-sharing feature maps privacy hazards from consent ambiguity, access misconfiguration, and downstream reuse.

failure_mode: Overlooking social or organizational hazards

mitigation: Include operators, affected users, regulators, and maintainers in the hazard review.

Premortem Failure Anticipation

distinctive_feature: The variant uses a future-failure story as a cognitive frame for surfacing hidden assumptions and dissent.

distinct_from_parent: The parent can be analytic or tabular; this variant is counterfactual and narrative.

condition: The team is overconfident, politically committed, or reluctant to voice concerns.

reason: The premortem frame legitimizes dissent and makes failure thinkable.

condition: The design is early enough that major changes remain possible.

reason: Premortem insight must still be able to alter design, scope, sequencing, or safeguards.

Failure Mode

role: Names how the imagined failure manifested.

Failure Cause

role: Works backward to plausible causes.

Detection Signal

role: Identifies warning signs that could appear before failure.

Mitigation Action

role: Turns concerns into design or implementation changes.

Premortem Workshop

mechanism_type: ritual

role: Provides the future-failure elicitation format.

Failure Scenario Review

role: Turns imagined failures into scenario paths.

Risk Register

role: Preserves actions and owners after the session.

domain: Policy

example: A rollout team imagines that the benefits portal failed publicly and identifies access, staffing, data-quality, and communication failure modes.

domain: Product development

example: A launch team imagines the product was abandoned and uncovers onboarding, trust, and support failures.

failure_mode: Doom performance

mitigation: Translate imagined failure into prioritized causes, evidence checks, owners, and design changes.

failure_mode: Consensus suppression

mitigation: Collect concerns individually before group discussion and protect dissent.

Operational Failure Mode Mapping

distinct_from_parent: The parent is general; this variant emphasizes workflows, roles, dependencies, load, staffing, and exception handling.

source_primes: function observability feedback

condition: The design depends on real operations rather than a single artifact or component.

reason: Operational failures often appear at handoffs, timing boundaries, and exception paths.

condition: Existing incident, support, audit, or near-miss data can inform the analysis.

reason: Operational evidence helps reveal repeated failure modes.

Function or Requirement

role: Defines the operational promise or step.

Failure Mode

role: Identifies where the workflow can break.

Detection Signal

role: Links failure modes to operational monitoring.

Failure Owner

role: Assigns responsibility across roles or teams.

Incident Pattern Review

role: Uses past signals to anticipate future operational failures.

Failure Scenario Review

role: Walks through failure under real operating conditions.

Design Review

role: Brings operators and implementers into review before commitment.

domain: Public services

example: A benefits renewal process maps failures at document upload, identity verification, language support, and appeal handoffs.

domain: Operations

example: A warehouse process maps errors that appear only during shift changes, scanner outages, or peak load.

failure_mode: Formal process bias

mitigation: Include workarounds, informal coordination, exception cases, and frontline constraints in the map.

Policy Failure Mode Anticipation

distinct_from_parent: The parent is domain-general; this variant specializes the analysis for policy and institutional design.

source_primes: causality uncertainty robustness

condition: A policy could fail through incentives, eligibility rules, administrative burden, data quality, enforcement, or unequal access.

reason: Policy failure often emerges through social and institutional pathways, not only technical defects.

condition: A decision maker needs to surface unintended effects before broad rollout.

reason: Early anticipation can prevent harm, inequity, noncompliance, or legitimacy failure.

Failure Mode

role: Names how the policy could break or produce harm.

Failure Effect

role: Captures consequences for affected populations and institutions.

Risk Priority

role: Prioritizes failures across severity, likelihood, equity, and reversibility.

Residual Risk Decision

role: Clarifies which harms cannot ethically be accepted.

Failure Scenario Review

role: Explores plausible policy failure stories.

Risk Register

role: Tracks policy risks, owners, and mitigations.

Design Review

role: Brings implementers and affected-party evidence into policy review.

domain: Benefits administration

example: A new eligibility rule is reviewed for documentation failures, digital access failures, erroneous denials, appeal delays, and stigma effects.

domain: Education policy

example: A school accountability change is reviewed for gaming incentives, unequal burden, data errors, and unintended resource shifts.

failure_mode: Affected-party invisibility

mitigation: Include user-context validation or lived-experience evidence before accepting policy risk.

near_names:
FMEA
Failure Modes and Effects Analysis
Prospective Failure Analysis
Premortem
Hazard Analysis
Risk Assessment
Fault Tree Analysis
Risk Register