AUTHREX-ENGAGE
The Authority Gate That Decides Before Anything Is Allowed to Act
An autonomous or operator-facing system can propose an action faster than any reviewer can weigh it. AUTHREX-ENGAGE places a fail-closed authority gate in front of that decision: an independent invariant monitor evaluates each proposed action against configured invariants before any authority is granted, and adjudicates it to one of five outcomes. Every admitted decision is written to a SHA-256 hash-chained ledger, and the whole run replays deterministically from its seed. Governance and assurance only. No targeting, no kinetic effects. Synthetic data.
The standalone console runs its engine exactly as released (v1.0.0), so its integrity check keeps matching the published value. Its start screen therefore shows the release-time name, AUTHREX RESEARCH PROGRAM, which predates AUTHREX SYSTEMS LLC.
Decide the Authority Before the Action Is Allowed.
- A system proposes an action and authority is assumed from prior testing
- No independent check stands between a proposed action and the authority to carry it out
- An out-of-distribution input can drive an action no reviewer ever weighed
- After the fact there is no tamper-evident record of what was authorized, at what tier, and why
- Each proposed action is evaluated by an independent, fail-closed invariant monitor first
- Configured invariants decide one of five outcomes: authorize, clamp, downgrade, deny, or hold for human
- If any invariant would be crossed, the safe default is deny or hold, never a silent grant
- Every admitted decision is written to a SHA-256 hash-chained ledger and replays deterministically
One Independent Check, Five Bounded Answers.
The gate does not return a simple yes or no. It resolves each proposed action to one of five outcomes, so that authority can be bounded rather than only granted or refused. The safe default under any monitor trip is deny or hold for human.
The proposed action passes every configured invariant and is permitted to proceed at full requested authority. The decision is recorded to the ledger.
Authority is granted but bounded. The action may proceed only within a reduced envelope, for example a lower rate or a narrower scope, when the full request would cross an invariant margin.
Authority is granted at a lower tier than requested. The action proceeds under a more conservative authority level while the higher tier is withheld.
The proposed action crosses a configured invariant and authority is refused. Denial is the fail-closed default whenever the monitor cannot confirm the action is within bounds.
The decision is escalated to a human and no automatic authority is granted. This is the second fail-closed default, used where the monitor determines the decision should not be made autonomously.
A Fail-Closed Monitor, a Tamper-Evident Record, a Reproducible Run.
Fail-Closed Invariant Monitor
An independent monitor evaluates each proposed action against a set of configured invariants before any authority is granted. If an invariant is crossed, or if the monitor cannot confirm the action is within bounds, the outcome defaults to deny or hold for human. Authority is never granted by omission.
Hash-Chained Decision Ledger
Every admitted decision is appended to a decision ledger, with each record chained to the one before it by a SHA-256 hash of the previous record and the current decision. Any later edit to an earlier record breaks the chain, which makes the sequence tamper-evident within the run. Tamper-evidence shows that a record was not altered after it was written, not that it describes the decision; that is established by replay against the seed and the frozen configuration hash.
Seeded, Reproducible Scenarios
Five stress scenarios, SCN_A through SCN_E, run from a fixed seed of 20260610. Because the console uses a seeded generator, the same scenario produces the same sequence of decisions on every run, which lets the behavior be inspected and replayed rather than only observed once. Time inside the engine is tick time; the wall clock only paces the animation and stamps exports, so the replay is the same on any hardware.
What Was Checked, and What It Does Not Claim.
The figures below are the documented results of the ENGAGE verification for this engineering console. They describe in-browser, seeded behavior on synthetic scenarios. They are not an independent validation and they do not describe a deployed system.
Coverage here means the share of the console decision logic exercised by the seeded scenario sweep, measured within this package. The suite checks that each of the five outcomes is reachable under the configured invariants, that the fail-closed defaults hold when the monitor trips, and that the hash-chained ledger stays consistent under replay. None of this is a claim of operational safety, certification, or fitness for any real engagement decision.
Intended Host in the Reference-Design Series.
Intended host in the reference-design series: BLADE-CUAS (BLADE-08), the counter-UAS platform, as the host of the fail-closed engagement-authority gate over a defended installation. The gate decides authority only; the platform’s sensing, targeting, and effect functions sit outside this console and outside AUTHREX.
Reference design, not built. Nothing in this console has run on it, no latency has been measured, and no relation between the browser engine and any hardware path has been established. No targeting or kinetic effects.
Governance and Assurance Only.
AUTHREX-ENGAGE governs the authority to act. It decides whether a proposed action may proceed, at what tier, and whether it must be clamped, denied, or held for a human. It does not select, identify, or target anything, it computes no actuation, and it drives no live system. The console runs entirely on synthetic, seeded scenarios in the browser. It is single-author engineering work, not deployed, and self-assessed at approximately TRL 2 to 4.
Five consoles, one engineering question: who holds authority at run time, how that holder is established, and what happens when the answer is unavailable.