AUTHREX-SAFING
The Authority to Enter a Safe State, and the Authority to Leave It
When a fault demands safing, the question of who holds the authority to act should already be settled. AUTHREX-SAFING governs the safe-state lifecycle of an autonomous system: the authority to enter a safe state on a demanded fault, to hold and deepen it while the fault persists, and to exit it only under an authorized re-arm with human approval. A fail-safe governor adjudicates every safing command, the safe-state floor is never applied as a grant of authority, every decision is written to a SHA-256 hash-chained ledger, and the whole run replays deterministically against five published reference roots. Governance and assurance only. No dynamics, no actuation, no targeting. Synthetic data.
Safing Is an Authority Decision, Not a Reflex.
- A fault fires and the safe-mode response is a hard-coded reflex with no adjudicated authority behind it
- Nothing distinguishes a demanded safing from a false one, so a benign condition can pull the system down
- Leaving the safe state is the most dangerous transition, yet it is often the least governed one
- After the fact there is no tamper-evident record of what was safed, what was denied, and who authorized the exit
- A fail-safe governor adjudicates every safing command against the safe-state lifecycle before it is applied
- Four health monitors demand safing on real faults, and detection accounting separates true, false, and missed safings
- Exit is the guarded transition: a safe-state exit requires an authorized re-arm, and human approval precedes it
- Every decision is written to a SHA-256 hash-chained ledger and the run replays deterministically from its seed
Four Safing Commands, One Guarded Exit.
The governor does not treat safing as a single event. It adjudicates four distinct safing commands across the lifecycle, and it can refuse any of them. The safe-state floor itself is never applied as a grant of authority, and the exit is the most guarded transition of all.
A demanded fault carries the system into a safe state. Entry is the protective transition: when a health monitor demands safing on a real fault, the governor authorizes entry and records the decision to the ledger.
The system remains in its safe state while the fault persists. Hold prevents any primary authority from being applied underneath it, which is one of the nine modeled properties of the formal authority model.
A degrading condition drives the system to a more restrictive safe posture, stepping down through the four irreducible safe-state floors rather than improvising a response.
The guarded transition. Leaving the safe state requires an authorized re-arm, and human approval precedes any recovery-owned application of authority. An exit with no legitimate arming is refused.
Any safing command that fails the lifecycle guard is refused. The safe-state floor is never applied as an authority grant, expired authority cannot apply, and a faulty authorization is always overridden.
A Fail-Safe Governor, a Tamper-Evident Record, a Reproducible Run.
Fail-Safe Safing Governor
The reference model is fail-safe by construction, drawing on NASA fault-management safe-mode practice and the Simplex safety-controller pattern. Authority tiers run from the safe-state floor upward, four health monitors demand safing on real faults, and the governor adjudicates every safing command against the safe-state lifecycle before it is applied.
Hash-Chained Decision Ledger
Every decision is appended to a decision ledger, with each record chained to the one before it by a SHA-256 hash. VERIFY CHAIN confirms the chain with its entry count, and the built-in TAMPER TEST demonstrates detection: it reports the tampered position while the live chain stays intact.
Published Reference Roots
Five seeded scenarios, SCN_A through SCN_E, run from a fixed seed of 20260610 and reproduce five published reference roots. SCN_D is a PARTIAL run by construction: it exercises the fault-storm path that leaves residual staged authority. CHECK REFERENCE ROOT reproduces the root for the loaded scenario inside the page.
What Was Checked, and What It Does Not Claim.
The figures below are the documented results of the SAFING v1.5.0 verification for this research console. They describe deterministic, seeded behavior on synthetic scenarios, measured within this package. They are not an independent validation and they do not describe a deployed system.
The formal authority model check enumerates 2,488,320 executions across 15 model states and 23 transitions to a maximum depth of 7, and all nine modeled properties hold, including FloorNeverApplied, HoldPreventsPrimaryApplication, HumanApprovalPrecedesRecoveryOwnedApplication, ExpiredAuthorityCannotApply, and FaultyAuthorizationAlwaysOverridden. Implementation traces conform with 11,739 terminal decisions mapped across three scenarios and fifty seeds with zero mismatches. A mandatory campaign of 50 non-equivalent trust-critical mutants was executed and killed, and a shipped adversarial battery of 43 checks passes against the delivered source with signed results. Model-checking results apply to the stated finite model and its assumptions. None of this is a claim of operational safety, certification, or fitness for any real safing decision.
Provenance and Reproduction
- Reproducible release (zip) ↓ source, evidence, detached signatures
- Build and verification report ↓
Standalone sha256: ef8b828e039a12bdd3873723195bed87027df59d64ce82f91c72da09492e6bd6
Release-signing key fingerprint (SPKI DER sha256): 6f1910bb193dc7a26c0236a694c458c30ab9bb58d097b417f25e5a2b20774b68
The release verifies package-internal integrity via SHA256SUMS and detached Ed25519 signatures; external trust requires anchoring the key fingerprint out of band.
Governance and Assurance Only.
AUTHREX-SAFING is a deterministic synthetic research prototype. It does not model physical dynamics, real actuation, certified hardware, operational identity infrastructure, or an accredited deployment environment.
AUTHREX-SAFING governs the authority to enter, hold, deepen, and exit a safe state. It decides whether a safing command may be applied and whether an exit is legitimately armed. It computes no vehicle dynamics, drives no actuation, and has no targeting or weapons scope. The console runs entirely on synthetic, seeded scenarios in the browser. It is single-author research, not deployed, demonstrated in a synthetic simulation environment; no formal TRL determination has been performed.