AUTHREX-REDLINE
Two Distinct Humans, or NO-GO
AUTHREX-REDLINE models one governance question in isolation: how a system can show that a single critical, irreversible until commit authorization is never exercised without two distinct authenticated humans, and that the absence of that condition produces a safe refusal rather than an unsafe default. The two authorization keys are human only; a machine principal is never eligible to hold either. The guarded action is representable as authorized, the GO state, only when both keys are held by two distinct authenticated humans and no hold is in force. Otherwise the state is the failure safe NO-GO. The guarded action is an abstraction, everything on screen is synthetic, and every authority change is appended to a hash chained ledger with deterministic replay. Hardened standalone prototype, v0.13.
AUTHREX-REDLINE is a deterministic synthetic research prototype. It models the authority governance principle of positive human control, that a machine is never eligible to hold the critical authorization and that two distinct authenticated humans are required to authorize it, as an abstract state machine. It does not model real nuclear weapons, NC3 systems, launch or release mechanics, targeting, authorization codes, command procedures, certified hardware, operational identity infrastructure, or an accredited deployment environment. Behavior shown is demonstrated in simulation. No formal TRL determination has been performed.
The Critical Authorization Is Held by Humans, or Not at All.
- A single actor, or an automated component, can end up holding the critical authorization alone
- Nothing structurally prevents a machine principal from being assigned an authorization role
- When authentication or availability fails, the system can default toward action instead of refusal
- Holds and vetoes are not attributed, so a conservative machine action can masquerade as a human decision
- The GO state is representable only when both keys are held by two distinct authenticated humans and no hold is in force
- A machine is never eligible: rejected at the interface, quarantined at the capability check, cleared by the arbiter, and caught by the human control audit
- Every failure path lands in NO-GO, the failure safe state, and a commit is voided the moment its authorization state changes
- Supervisor vetoes and arbiter fail safe holds are recorded as what they are, with the record never inventing a human action
Five Outcomes, One Invariant.
Within the modeled scripted and seeded scenarios, the arbiter maintains exactly one eligible authenticated holder for each responsibility. The two authorization keys, R_AUTH_A and R_AUTH_B, are human only and must be held by two distinct authenticated humans. The operational responsibilities, R_ADVISE and R_STAGE, stay continuously filled with no gaps, and an empty responsibility falls to REDLINE_SAFE_HOLD.
The guarded action is representable as authorized only when both authorization keys are held by two distinct authenticated humans and no hold is in force. A commit is recorded only in the GO state and is bound to the exact authorization state that produced it.
The failure safe default. Revocation, holder loss, a veto, a fail safe hold, lease expiry, or reassignment voids any commitment immediately, and a new epoch opens from NO-GO. The system refuses rather than defaulting to action.
A supervisor veto is an explicit human action that names the available supervisor and states a hold duration inside the configured bound; anything else is refused and recorded rather than silently corrected. Clearing a hold is likewise a supervised human action, never the allocator's.
The arbiter may engage a separately named fail safe hold on an autonomous allocator request. It is recorded as an arbiter action with its trigger, never as a human action, because a positive human control model should not invent a human action, even a conservative one.
A machine proposed for an authorization key is rejected at the interface. A forged grant naming a machine fails the capability check and is quarantined. The same human on both keys is refused. Injected, stale, cross run, or higher epoch grants never become the effective holder.
Human Only Keys, a Tamper-Evident Record, Six Audits.
Human Only Authorization Keys
Six named principals: HS, the supervisor, and H1, H2, H3, the authenticators, any of whom may hold a key; M1 and M2, machine principals that may advise and prepare but are out of scope for both keys. The rule is enforced in depth: rejected at the interface, quarantined at the capability check, cleared by the arbiter when a holder is not an available, in scope, authenticated human, and swept by the human control audit across the entire recorded ledger.
Capability Markers and the Ledger
At run start the arbiter mints a random secret from the platform secure random source and holds it in a private closure keyed to the run; every grant is bound by a keyed tag over its immutable authorization fields, and every authority change is appended to a SHA-256 hash chained ledger. This is an in process capability marker for the simulation, not a hardware backed key and not a public key credential. The authenticated identities are synthetic; the console does not demonstrate real authenticated human control.
Six Audits and Sealed Evidence
Six independent checks run from the interface: authority, human control, grant chain, transition, replay consistency, and ledger chain verification with a tamper self test. Evidence sealing produces a portable record whose verification recomputes the digest, confirms the frozen configuration hash, and replays a fresh run from the same seed, requiring the replayed telemetry to equal the sealed telemetry field for field. This is a deterministic behavioral replay checksum, not a digital signature and not independently attested.
The Approved Description, and the Verified Figures.
AUTHREX-REDLINE v0.13 is a deterministic synthetic research prototype exploring positive human control authority governance through two distinct synthetic human authorization roles, explicit supervisor vetoes, separately attributed arbiter fail safe holds, fail safe NO-GO behavior, immutable private run metadata, private per run capability markers, a closed hash chained event vocabulary, structural transition and grant chain auditing, private state replay consistency, and deterministic behavioral evidence replay. It contains no operational weapon, targeting, release, or command procedure detail and is not formally verified, digitally signed, hardware backed, operationally validated, independently attested, or accredited.
The reference run at seed 20260728 over 400 ticks records 218 reassignments, 91 corrections, 11 forged grants rejected, 23 commitments, 139 GO ticks against 261 NO-GO ticks, 18 fail safe holds, zero gaps, zero splits, and a pass on all six audits. The build passed through ten iterative independent audit rounds during development. Each round produced written findings, and each finding was closed in a subsequent build. The final rounds reported no publicly reachable authorization or positive human control failure. These are development review outcomes on a research prototype, measured within this standalone; they are not a certification, an accreditation, or a third party attestation, and the invariant is demonstrated over the modeled scenarios, not over arbitrary distributed concurrency.
Provenance and File Integrity
- AUTHREX-REDLINE v0.13 is a hardened standalone prototype with no signed release. There is no release archive, no detached signature, and no signing key for this artifact.
- This build does not include formal model checking, property based adversarial testing beyond the bundled batteries, mutation testing, a digital signature, human credential authentication, implementation identity, a sealed release manifest, or an independent verifier.
- Single-author research: Burak Oktenli, MBA.
The published file has SHA-256 480459efb3cfc1023c6b50d843c98befa9ed3d340f8a00eeb6308f0743914164. Recompute it locally to confirm the file you received matches the file described here.
Reference ledger root (seed 20260728, 400 ticks): 7bce87c43f67203852c3d02e3477cd75dec91f39e7f030fbff45d8f59a2fbb72. The root is a behavioral fingerprint, reproducible by anyone who runs the same build at the same seed for the same number of ticks; it is a reproducibility aid, not proof of authenticity.
Governance and Assurance Only.
The guarded action is an abstraction, and the console carries no operational, weapon, targeting, release, or command procedure detail of any kind. The adversary in the model is the untrusted allocator, meaning the proposal and injection data entering the documented interface; the browser host and any scripts loaded before the engine are trusted. A single HTML file cannot fully defend against a co resident script that executes before the engine, and for high assurance use the engine would run as an isolated module or service. The Operations tab carries a live two dimensional schematic and the 3D Model tab a live three dimensional scene, both read only presentation layers rendered from the same engine state; all state changes enter through the same documented request path used by the console controls. The console runs entirely client side on synthetic, seeded data, uses no browser storage, requires a secure random source and refuses to start without one, and is demonstrated in simulation; no formal TRL determination has been performed.
Five consoles, one research question: who holds authority at run time, how that holder is established, and what happens when the answer is unavailable.