Resilience engineering raises the strongest objection to rigid containment. Complex systems do not obey rules under load; they drift around them along gradients of workload and cost. Put a non-waivable gate in front of a high-tempo operation and the gate holds until the day it becomes the hazard: the mass-casualty event, the staffing hole, the outage. On that day, operators who know the gate will fail the patient route around it. Credentials get shared. Overrides get forged. The informal network that saves lives tonight also destroys the records that would have shown why the gate was failing, and the institution gets the worst of both: an uncontrolled workaround and no evidence. The gate meant to stop a failure now manufactures one.
The double standard behind the gate
The objection lands because containment is usually designed as if the human were the unreliable component. The engineering tradition answers with a comparison. A financial transaction engine is required to hold transactional integrity: no unanchored entries, no silently pending transactions, no teller manually auditing raw logs at midnight to keep the ledger from corrupting. A system for clinical care or benefits administration is handed “fluidity” and “heuristics” instead, and the difference in rigor is greatest exactly where a human is positioned to absorb whatever the system drops. The requirement is not that the person become a state machine. It is that the software become one. Integrity belongs to the platform; judgment stays with the person.
The asymmetric boundary
The fix separates the two by what each side may do.
The machine boundary is deterministic. Execution gates refuse state changes that lack a bound, expiring authorization. Expiration clocks are fixed to statutory deadlines, and they start at first receipt of the request, not at first entry into a queue, so the pre-intake stage cannot become an off-the-books waiting room. Rollback graphs run inside the platform, so a refuted premise reverses everything that consumed it. None of this watches a person. It watches records.
The human boundary is sovereign. The operator keeps discretion, judgment, and the authority to suspend the gate. No metric observes how fast they work, what they look at, or what they do away from the keyboard, because a boundary that watches the operator becomes the next control system.
The override
Between the two boundaries sits the emergency override, and its classification is the design.
The operator holds a legal and technical right to suspend the gate during a declared emergency. When they fire it, the event is recorded as a declaration of system failure. The record reads: this gate, in this condition, could not serve the purpose it was installed for, and a qualified operator said so in the moment. The override is not logged as a compliance breach, and the operator acquires no malpractice exposure for the bypass itself. Liability for the underlying failure stays with the institution and the vendor, who hold the design authority that produced it. What the operator holds is what Law VII grants to error-bearing parties: standing proportional to exposure, and a state change they can actually make.
The override also satisfies Law IX directly. Oversight counts only when the human can alter system state. A review queue a clinician cannot change is decoration; the override is the opposite, a state change with legal cover, exercised at the moment of need rather than filed for later.
The override is the human counterpart to the safety valve. The valve routes pressure when the system is overloaded; the override suspends the system’s control when the system itself is the overload source. Both are visible, both are logged, and both name an owner.
What the audit decides
Every override fires an automatic root-cause audit of the interface failure that made it necessary. Nobody has to file a complaint, and no manager decides whether the event merits review. The audit is attached to the event the way the receipt is attached to the transaction.
The log then does work at renewal time. Authority decays unless its justification is renewed, and a gate whose justification is holding shows a low override rate, few repeated causes, and fixes that arrive. A gate that keeps being overridden is a gate whose justification is failing, and the log proves it to whoever decides whether the authority persists. The override rate is read as an aggregate, never as a per-operator score, because the moment it becomes one it starts producing the drift it was meant to cure.
What is built and what is called for
Specifications for the record side are available. The proposed rescue register would record the occurrence, the labor, and whether the cause was fixed; the authority-grant schema provides a field for the renewal justification a deployed gate’s log could supply. These specifications do not establish an operating register or a deployed renewal gate. What has no mechanism yet is the legal allocation: the shield that makes the bypass itself non-actionable for the operator and assigns the underlying failure to the institution and vendor that hold design authority. Stated plainly, that allocation is the part of this arrangement that is called for rather than built, and until it exists the override fires at the operator’s own risk.
What this preserves
The drift objection assumed a choice between a rigid system that fails in crisis and a flexible system that leaks. The asymmetric boundary refuses the choice. The machine side stays rigid because the pressure that would corrupt it has a lawful exit. The human side stays flexible because the improvisation is now legal, visible, and priced to the party that caused the failure. The informal network does not need to be stamped out. It needs to be made unnecessary, and the audit is how the institution finds out what would have made it unnecessary.
The compulsion problem shows what happens when the people inside a system must be forced to stay. The override shows the reverse: a system that has to earn the compliance of the people it depends on, one fixed failure at a time.