Fail-Closed or Fail-Open Design¶
Method — instantiates Fail-Safe Default
A design method that chooses whether failure should block or release a boundary based on which default minimizes harm.
Fail-Closed or Fail-Open Design is not a device but a design decision: for a boundary that controls passage — a lock, a valve, a gate, a permission — it fixes, in advance, which way the boundary defaults when power, control, or verification is lost. Fail-closed means loss defaults to blocking (the door stays locked, the valve shuts, access is denied); fail-open means loss defaults to releasing (the door unlocks, the valve opens, passage is allowed). Its defining idea is that there is no universally safe direction — the right default is entirely a function of which failure causes greater harm in this context — and its whole work is forcing that comparison into the open before the crisis, then wiring the answer into the physics so no one has to choose under stress. It decides which safe state exists and who may lawfully reverse it; it does not detect faults or perform the runtime transition.
Example¶
An architect is specifying electronic locks for a new office building, and the same hardware question has two opposite right answers depending on the door. For the stairwell and exit doors, the design must be fail-safe (fail-open): if the building loses power or the fire alarm sounds, the maglocks must drop so people can escape — a door that traps occupants to protect the building is the intolerable failure. For the server room and the pharmacy, the design must be fail-secure (fail-closed): if power or the badge reader dies, those doors must stay locked, because an unattended open vault is the intolerable failure. The design method makes each choice explicit and traces it to the hazard it minimizes, then also fixes who may override the default — a fire marshal or security lead with the authority to hold a fail-open door secured, not any passerby. The deliverable is a door-by-door schedule of default directions and override authorities, decided cold, months before any actual power loss.
How it works¶
- Name the two failures. For each boundary, articulate the harm of defaulting-open versus defaulting-closed on loss of control.
- Pick the least-harmful default. Choose the direction whose worst case is more tolerable, and record why — the choice is context-specific and often value-laden.
- Wire the default into the physics. Implement so the safe direction is what happens passively on loss of power/signal, not something logic must actively command.
- Bound who may reverse it. Define the authority allowed to override the default and under what conditions, so the default isn't quietly negotiable in the moment.
Tuning parameters¶
- Default direction — closed versus open, per boundary. The single highest-stakes dial; the same building will want both, door by door.
- Granularity of choice — one policy for a whole class of boundaries or a per-boundary decision. Fine granularity fits the default to each hazard but multiplies specification and audit work.
- Override authority breadth — how many roles may reverse the default and how easily. Wider authority buys operational flexibility; narrower authority protects the default from erosion.
- Reversibility on restoration — whether the boundary returns to normal automatically when power/verification returns, or requires a deliberate act.
When it helps, and when it misleads¶
Its strength is that it converts a life-safety-versus-security argument from a panicked in-the-moment guess into a deliberate, documented default — and it makes the trade-off visible rather than hiding it inside whatever the hardware happened to do when it lost power.
Its failure mode is a mismatched default: choosing the direction that protects the wrong value, so failure fails dangerously — a fail-open where security was the greater hazard, or a fail-closed that traps people.[n1] The classic misuse is copying a default across contexts without re-deriving the hazard (applying data-center fail-closed logic to an occupied stairwell). A subtler misuse is an override authority so broad that the "default" is routinely reversed, which is really the manual_override failure of the fail-safe itself. The guarding discipline is to re-derive the direction from the local hazard for every boundary and to keep the override authority narrow and accountable, so the chosen default actually governs.
How it implements the components¶
Fail-Closed or Fail-Open Design fills the up-front design slice of the archetype — the reasoning that fixes the default before any fault occurs:
hazardous_failure_mode— its first act is naming the two competing harms (trapping people vs. releasing an asset) so the safer direction can be identified.safe_default_state— it decides which state is safe: closed or open, boundary by boundary, and wires that direction to be the passive result of losing control.override_authorization_boundary— it fixes who is permitted to reverse the default and under what conditions, so the chosen direction is not casually negotiable.
It does NOT implement failure_detector or shutdown_or_isolation_rule — it decides which default is safe, not how to sense the fault or execute the transition; sensing and the runtime cutoff belong to Automatic Shutdown and Trip Switch or Circuit Trip.
Related¶
- Instantiates: Fail-Safe Default — this method chooses which state is the safe default for a boundary, the decision every other mechanism assumes.
- Sibling mechanisms: Emergency Stop · Dead-Man Switch · Trip Switch or Circuit Trip · Automatic Shutdown · Safe Mode · Watchdog Timer · Containment on Alarm
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: The mechanism wires a boundary so loss of power or signal passively leaves it in the preselected least-harmful open or closed configuration.
Nearest alternative: Decision, Gate & Allocation — Designers choose the default once, but the deployed mechanism is the enduring physical or technical configuration that realizes it.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Choosing a safe failure default is a foundational safety and reliability engineering design decision.
Related originating lineages:
- Computer Science & Software Engineering — Computer security independently formalized fail-open versus fail-closed access-control behavior. Fail-open and fail-closed access-control defaults are established software and security-system design patterns.
- Security Studies & Intelligence Analysis — Threat modeling materially shapes which boundary state minimizes adversarial harm.
Review resolution: Both reviewers agree that engineering_design is primary. I retain computer_science, security_intelligence only as formative origin lineages; convergent is appropriate because the same operational pattern arose through parallel professional lineages. Reach is multi_domain because the structure transfers across several fields but is not a near-universal human pattern, an applicability judgment kept separate from provenance. Encyclopedia synthesis is false because the artifact is already established enough that encyclopedia-specific synthesis is not required. No unresolved historical ambiguity remains after reconciling the secondary fields.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] In access-control hardware the same choice has two named poles: a fail-safe lock releases on power loss (prioritizing egress) while a fail-secure lock stays locked (prioritizing security). The terminology encodes exactly this method's warning — "safe" is defined relative to a hazard, so the correct default for a fire exit is the wrong default for a vault. ↩