Engineering Basis · AUTHREX Systems

VIEWING 01 / 01FORMAL COVERAGE STATUSAUTHREX SYSTEMS

[ Engineering Basis ]

Where the Layer Sits. What It Costs. Where It Stops.

This page sets out the engineering basis of the governance layer: the integration boundary with each interface labeled at its standing, the authority tiers and restoration guards of each artifact, failure-mode coverage against the mechanisms it is compared with, the scope limits the standards state for themselves, the decision-window arithmetic, a per-stage latency budget, the failure semantics of the gate, a draft authority interface, the BLADE-EDGE reference stack, and the placement options for distributed autonomy. Every item is labeled at its standing. Nothing on this page has been measured on hardware, and no line on it is a result.

Engineering basis for the AUTHREX governance layer: integration boundary, tier vocabularies and restoration guards, coverage, standards scope, timing, failure semantics, interface, placement, and one scenario, each labeled at its standing. Companion to Formal Coverage Status and the reviewer questions on the Domains page.

[ Engineering basis · status legend ]

What this page is, and what it is not

This page answers two questions reviewers have asked of the program: why existing mechanisms do not fully resolve the problem, and how the proposed layer would actually be deployed. Every item carries one of five labels. STATED: a position the program holds. TARGET: a design allocation set before measurement. DRAFT: a specification offered for review. PROPOSED: a design option with the decision pending. SPECIFICATION-LEVEL: the sequence the specification calls for, with illustrative values and no recorded run. Nothing on this page has been measured on hardware, and no line below should be read as a result.

[ 1 · STATED · added 21 October 2026 ]

Integration boundary

Where the governance layer sits relative to the system it governs, and the standing of each interface. Only the software path has been implemented, in the Governance Kernel on loopback with synthetic data; the hardware path is a reference design.

Question	Answer, at the current standing
What the governor can mediate	Only what is routed through it: a tool call that passes the proxy, a proposal the host submits before acting, a safing command the governor adjudicates. The Kernel mediates MCP tool calls in software; the consoles mediate modeled commands; the proposed hardware gate would mediate one actuator path.
What can bypass it	Any action that does not pass the intended interface: a tool reached without the proxy, an actuator driven on a path the interlock does not cover, a host that acts before the OUTCOME message, a compromise of the governance node itself (outside the trusted computing base assumptions on this page). Bypass and enforcement-boundary tests have not been run; they are on the engineering backlog.
Dependencies	Host integrity (the host exposes every irreversible action as a proposal and acts only on a signed outcome); protected keys (policy signature, outcome signature, ledger checkpoints); downstream enforcement (the gate, interlock or proxy actually withholds the action); communications (a missing or expired TIER is treated as A0); complete routing through the intended interface.
Authorization denial versus physical response	The governor decides whether an action is permitted; it does not make the platform safe. A withheld permit, an opened relay, a shutdown, a hold or a return-to-base command is a host response that must be engineered and shown safe for that platform and mission; none is universally safe, and the AUTHREX-SAFING console models exactly this distinction between the authority to enter a safe state and the safe state itself.
What the record shows	A hash chain shows that the record is consistent with itself; a signature binds a record’s content to a signing key; an authentic checkpoint or external anchor, protected separately from the record, helps detect changes to the records committed before it; replay against the frozen configuration checks that the record is consistent with the recorded inputs and configuration. These mechanisms do not prove that the record is complete or that a recorded action was actually executed. The consoles provide chain consistency and replay; checkpoints exist in the Kernel; external anchoring is open across the Set.

[ 2 · STATED · per artifact, added 21 October 2026 ]

Authority tiers, transitions and restoration guards, per artifact

Each artifact keeps its own tier names and ordering; they are listed here as each release states them and are not normalized to one scheme. HMAA counts A3 down to A0, the agent consoles T3 down to T0, SAFING orders its command classes from the most restrictive floor upward, and QUARANTINE uses T2, T1 and T0 only. The restoration-guard column names only the guards the release actually states; a guard that is not stated is marked as such rather than assumed.

Artifact	Tier vocabulary	Ordering, triggers and rule	Restoration guards present in the release	Standing
HMAA (Catalog V6.1, Frameworks page, Domains page)	A3 full autonomy · A2 restricted · A1 minimal · A0 revoked	Downgrade to the target tier is immediate and may skip tiers; upgrade is stepwise with a hysteresis delay of roughly 5 to 15 seconds of sustained trust; HANDOFF at A1 where policy requires confirmation; ABORT to A0 invokes CARA. Transient recovery cannot restore authority.	Fresh sustained evidence (hysteresis) and staged restoration are specified; expiry (valid-until), policy identity and evidence-age budgets are in the draft gate monitor below; replay protection of a re-arm is a stated requirement from a CARA counterexample, not established for any shipped engine.	Specification and model; model checked at stated bounds
Gate monitor and interface (this page, sections 7b and 8)	Tier A3 to A0 with valid-until; outcomes EXECUTE, DELAY, HANDOFF, ABORT	A permit is asserted only if the policy signature verifies and has not expired, the tier is current, the action class is permitted at that tier, the evidence age is within budget and the window has elapsed with confirmation where required; no permit on a default, a timeout or an unrecognized state.	Policy identity and expiry, tier expiry, evidence freshness, ledger-before-permit; restoration through CARA with refreshed evidence and operator promotion to A3.	Draft v0.1; no implementation
AUTHREX-AGENT console and Governance Kernel	T3 autonomous · T2 supervised · T1 confirmed · T0 manual (full lockout)	Within a decision cycle authority can move from T3 toward T0 but cannot silently re-escalate; re-escalation requires an explicit operator action. The Kernel gates each tool call by tier before execution.	Approval scope through the human approval queue with RBAC; policy identity through signed policy loading; checkpointed ledger. Freshness, expiry and replay protection of approvals are not stated on the Kernel page.	Implemented software (Kernel, synthetic data); console demonstrated
AUTHREX-SAFING v1.5.0	Command classes SAFE_STATE_FLOOR (T0) · SAFING_OWNED (T1) · OPERATING_ENVELOPE (T2) · HEALTH_ADVISORY (T3), most restrictive first	Entry on a demanded fault; hold and deepen while the fault persists; exit only under an authorized re-arm with human approval; the floor is never applied as a grant of authority.	Approval scope (human approval precedes any recovery-owned application), expiry (ExpiredAuthorityCannotApply), cleared fault (hold while the fault persists), faulty authorization overridden. Nonce or replay protection of the re-arm is not stated.	Released synthetic console; nine modeled properties hold
AUTHREX-QUARANTINE 2.2.5	T2 governed grant · T1 read-only probation · T0 case open (T3 does not appear in this console)	Agents work at T2; an out-of-grant action is denied before execution and a case opens at T0; return passes through T1 probation to a new epoch-scoped T2 grant.	Cleared fault (twelve-second clean dwell), staged restoration (five seconds of read-only probation), approval scope (two custodian approvals, three witness ballots), expiry (epoch-scoped grant).	Released synthetic console; externally reviewed
AUTHREX-ABORT, SIM-13 Build 0.6	Outcomes EXECUTE · HANDOFF · ABORT · DELAY over a frozen human-authored envelope	Five evidence predicates gate the available actions; authority contracts as they degrade; a lapsed irreversible action is latched down for the remainder of the run even if the evidence recovers; only pre-authorized contingencies may then be requested.	No restoration within a run by design (latch); the envelope is frozen before the run and never widened.	Console with two frozen TLA+ modules
AUTHREX-ENGAGE	Outcomes AUTHORIZE · CLAMP · DOWNGRADE · DENY, with a HOLD-FOR-HUMAN review state	Declared-hostile and high-risk requests first enter the hold-for-human state; the packaged scenarios resolve that review with a labelled SIMULATED_REVIEWER_MODE policy, not an interactive operator.	Human review state modeled; the reviewer is simulated.	Hardened prototype console
AUTHREX-RTA	Admit · hold · revert to the safety floor	An invariant monitor on the ASTM F3269 and Simplex reference pattern.	As the console states; no restoration guard beyond the monitor is claimed here.	Hardened prototype console
AUTHREX-DA release 1.8	Verdicts ADMIT · ADMIT_FLAG · QUARANTINE · REJECT	Per record and per contribution across four evidence channels; the gates are non-compensatory.	Record-level quarantine lifecycle as the page states; one seed.	Engineering preview
AUTHREX-REDLINE and AUTHREX-TEAM	REDLINE: GO · NO-GO with fail-safe holds; TEAM: exactly one eligible authenticated holder per responsibility, never zero and never two	Positive human control and team authority modeled with synthetic identities and roles.	As the consoles state.	Hardened prototype consoles

Potential restoration guards an engineering requirement could call for: fresh evidence, cleared faults, approval scope, expiry, nonce or replay protection, policy identity and staged restoration. The table shows that none of the releases implements all of them, and the draft gate monitor specifies most of them without an implementation.

[ 3 · STATED ]

Failure-mode coverage by mechanism

The alternatives table on the Domains page is organized by mechanism. This table is organized by failure mode, which is the cut that shows where each mechanism stops. Entries for AUTHREX describe the specification and its simulation evidence only; no entry describes a fielded or hardware-tested behavior.

Failure mode	State-envelope run-time assurance (Simplex family, ASTM F3269)	Certified safety controllers (IEC 61508 family)	Human-on-the-loop supervision	AUTHREX as specified
Controller fault or compromise producing an unsafe command; state leaves the envelope	Covered	Covered	Partial: limited by operator rate	Partial: the gate is inherited from the Simplex pattern and is not the contribution
Sensor spoofing that keeps the observed state inside the envelope	Not covered: the monitor trusts its inputs	Not covered	Partial: only if the operator notices	Covered as specified: cross-sensor disagreement lowers trust before authority (simulation only)
Jamming or loss of a sensing modality	Partial: only if the monitor consumes that modality	Not covered	Partial	Covered as specified: trust falls, tier contracts (simulation only)
Stale evidence and delayed data	Not covered	Not covered	Partial	Covered as specified: evidence age gates the irreversible action (simulation only)
Correlated false information across sources	Not covered	Not covered	Not covered	Not covered: open limitation, recorded as NEG-3 in AUTHREX-DA
Delayed or overloaded human supervisor	Not applicable	Not applicable	Not covered: this is the failure mode itself	Covered as specified: deliberation window with abort as the timeout default (simulation only)
Recovery after lockout without an operator	Partial: reverts to the safe controller with no return path	Partial: manual reset	Covered by the operator	Covered as specified: deterministic GREP recovery (simulation only)
Compromise of the governance node itself	Not covered	Not covered	Not covered	Not covered: outside the trusted computing base assumptions

[ 4 · STATED ]

What the standards say they cover, as this program reads them

Paraphrased readings of scope clauses, not quotations. Readers should verify against the current edition of each document. No compliance with any of these standards is claimed.

Standard	What it covers	What it leaves outside	Consequence for this program
ASTM F3269 (run-time assurance for aircraft systems with complex functions)	Bounding the behavior of a complex function with a monitor and recovery control function developed to a higher assurance level	Adversarial corruption of the monitor’s own inputs; the practice is a safety practice, not a security one	The gate is inherited; input trust is the layer above it
IEC 61508 / IEC 61511 (functional safety of E/E/PE systems; process sector)	Random hardware failures and systematic failures, safety integrity levels, proof testing	Malevolent and unauthorized action, which the standard refers to IEC 62443	A certified safety function does not assess evidence quality
IEC 62443 (security for industrial automation and control)	Zones, conduits, security levels, and the lifecycle of security for IACS	Authority for autonomous decisions; what a system is permitted to do once inside the zone	Security perimeter and authority are separate questions
ISO 26262 (functional safety, road vehicles)	Malfunctioning behavior of E/E systems	Performance limitations of the intended function (ISO 21448, SOTIF) and cybersecurity (ISO/SAE 21434), both explicitly excluded	Three standards for three questions, none of which is run-time authority
DO-178C / ARP4754A (airborne software and system development)	Assurance objectives for software and systems against requirements	Trustworthiness of sensor data at run time; the requirements assume valid inputs	Assurance of the code says nothing about the belief owed to its inputs
DoDD 3000.09 (autonomy in weapon systems)	Policy: appropriate levels of human judgment over the use of force	An engineering mechanism for enforcing that judgment at machine speed	Policy names the requirement; it does not supply the mechanism

[ 5 · STATED · illustrative parameters ]

Decision-window arithmetic

Supervision of every action requires the human evaluation time H to fit inside the window T between detection and irreversible effect. With detection range R and closing speed v, T = R / v. The rows use illustrative parameters, not measurements of any system; the deliberation windows of 5 to 15 seconds are the FLAME budgets published on this site.

Detection range R (illustrative)	Closing speed v (illustrative)	Window T = R / v	Against H = 5 s	Against H = 10 s	Against H = 15 s
2,000 m	50 m/s	40 s	Feasible	Feasible	Feasible
800 m	80 m/s	10 s	Feasible	Marginal	Infeasible
300 m	60 m/s	5 s	Marginal	Infeasible	Infeasible
150 m	75 m/s	2 s	Infeasible	Infeasible	Infeasible

Below roughly ten seconds, evaluating each action is not available to the supervisor, whatever the interface. The authority a system holds must then be decided in advance and contracted on evidence, with the supervisor placed at the handoff and abort points rather than in the per-action loop. This is the arithmetic behind the two-condition scope statement on the Domains page.

[ 6 · TARGET · not measured ]

Per-stage latency budget

Allocation set by the program before any measurement, expressed as a rule and as an illustrative value at a 20 Hz control loop (50 ms period). Every value is a target to be replaced by hardware-in-the-loop measurements, with the measurement point named so the replacement is checkable.

Stage	Budget rule	Illustrative target at 20 Hz	Measurement point
Sensor ingest and attestation check (SATA)	At most one sensor frame	≤ 10 ms	Hardware timestamp at ingest to trust-scalar emit
Deception and integrity update (ADARA, MAIVA)	At most one sensor frame	≤ 10 ms	Trust-scalar receipt to prior emit
Tier computation (HMAA)	Deterministic, bounded, no allocation	≤ 2 ms	Inputs stable to TIER message emit
Window check (FLAME)	Constant time; the window itself is seconds	≤ 1 ms	Proposal receipt to window verdict
Gate decision path (FPGA logic)	Combinational or single-cycle where possible	≤ 100 µs	Permit request to permit assert
Interlock actuation (relay)	Physical device limit	≤ 5 ms	Permit assert to contact closure
End-to-end permit path	Under half the loop period	≤ 20 ms	Ingest timestamp to contact closure

Resource targets for the governance node are not set until a first synthesis exists; publishing LUT, flip-flop, block RAM, and power figures without a design would be invention.

Reconciliation, 21 October 2026. Read in series, the six stage targets sum to 28.1 ms, above the 20 ms end-to-end target. The end-to-end figure holds only if the sensor ingest stage and the deception and integrity update overlap within one frame, a concurrency assumption the table does not yet specify; both figures are targets and neither is measured. Three clocks are kept apart on this site: logical simulation time, which the consoles use (tick time only); measured software timing, which exists only for the Governance Kernel on loopback; and these proposed hardware budgets. Detection time (SATA), computation time (ADARA, MAIVA, HMAA, FLAME), authority descent (the TIER message), enforcement response (gate and interlock) and restoration time (CARA, hysteresis) are separate quantities, and none of them has been measured.

[ 7 · STATED · specified, not implemented in hardware ]

Failure semantics of the gate

The default is fail-closed: on loss of any evidence the gate requires, the permit is withheld and the normally-open interlock opens, which is the A0 revoked-authority state. Whether that state is safe for a given platform and mission requires a platform-specific hazard analysis; the gate does not establish it. The table names the conditions, what is recorded, and the recovery path. None of this has been implemented in hardware.

Condition	Gate behavior	Recorded	Recovery
Trust feed lost or silent past its budget	Permit withheld; tier treated as A0	Last valid trust record, loss timestamp	CARA GREP on restored feed; promotion requires refreshed evidence
Timestamps stale beyond the evidence-age budget	Permit withheld for the affected action	Evidence age at decision	Automatic once fresh evidence arrives, subject to hysteresis
Attestation failure of a sensor	That sensor excluded from fusion; trust recomputed	Attestation result, sensor identity	Re-attestation; operator notified at A1
Policy signature invalid or policy expired	All permits withheld	Policy hash, verification result	Signed policy reload; operator confirmation
Host unresponsive or proposals malformed	No permit issued; tier falls to A0 on refresh timeout	Last proposal, timeout	Host restart outside the gate; CARA on return
Ledger write fails	Permit withheld: no unrecorded action	Failure itself, in the next successful record	Ledger recovery; chain continuity verified before any permit
Gate self-test fails	Interlock opened; gate reports fault	Self-test result	Maintenance action; no automatic promotion
Power or clock loss at the governance node	Interlock opens by construction (normally open)	Nothing; the loss is inferred from the gap	Power and clock restore; full re-attestation before any permit

[ 7b · DRAFT v0.1 · specified, not implemented ]

Gate monitor specification

The monitor is the logic inside the governance node that turns a proposal and the current authority state into a permit or a withheld permit. It is specified here as a function with named inputs, a decision rule, and stated properties, so a reviewer can judge it without an implementation. This is a specification, not a description of running code.

Inputs. Current tier T from HMAA (A3 to A0, with its valid-until time); the proposal P (action id, action class, consequence tier c); the evidence age a of the references P carries; the window verdict from FLAME; the policy object with its signature and version; the node clock.

Decision rule. A permit is asserted only if all of the following hold: the policy signature verifies and the policy has not expired; T is current, that is the node clock is before its valid-until; the action class of P is in the permitted set for T under the policy; the evidence age a is within the budget the policy sets for consequence tier c; and the FLAME window for (T, c) has either elapsed with operator confirmation or is not required at this tier. If any condition fails, the permit is withheld and the outcome is DELAY, HANDOFF, or ABORT according to which condition failed. There is no path that asserts a permit on a default, a timeout, or an unrecognized state.

Property	Statement	How it would be shown
No permit without a current tier	If the node clock is at or past the valid-until of T, no permit is asserted	Model checking of the monitor automaton; a hardware timing test
No permit without a verified policy	If signature verification fails or the policy is expired, no permit is asserted	Test with an altered policy object; the failure must be recorded
Monotonic in tier	The permitted action set at a lower tier is a subset of the set at any higher tier	Static check of the policy object at load time
No unrecorded permit	Every asserted permit is preceded by a committed ledger record	Ledger continuity check across a permit sequence
Deterministic	Identical inputs, policy, and clock reading produce an identical outcome	Replay of a recorded sequence against the same build
Fail-closed on any input fault	Loss, staleness, or malformation of any input yields no permit	Fault injection per the failure-semantics table above

Relationship to the HMAA model. HMAA’s authority automaton is model checked in TLA+ at stated bounds. The monitor above consumes that automaton’s output; it has its own properties and is not covered by the HMAA result. No model checking of the monitor has been performed.

[ 8 · DRAFT v0.1 · offered for review ]

Authority interface between host and governance node

The messages the governance node consumes and emits, the timing contract, and what the host must expose. This is a draft specification for review; no implementation of it exists, and field names may change.

Message	Direction	Fields	Timing
TRUST	Node internal, exposed for audit	source id, trust scalar in [0,1], four diagnostic scores, attestation status, timestamp, sequence	Every sensor frame
PROPOSAL	Host to node	action id, action class, consequence tier, target evidence references, timestamp, sequence	On each proposed action
TIER	Node to host	tier (A3 to A0), reason code, evidence references, valid-until, sequence, node signature	Refreshed at least once per deliberation window; missing refresh means A0
OUTCOME	Node to host and interlock	action id, outcome (EXECUTE, DELAY, HANDOFF, ABORT), tier at decision, window applied, sequence, node signature	Before any actuation of the proposed action
HANDOFF	Node to operator interface	action id, tier, evidence summary, window remaining, sequence	On any HANDOFF outcome
LEDGER	Node internal, exportable	previous hash, record hash, record body (any of the above), timestamp	Every record

Host obligations. Expose every irreversible action as a PROPOSAL with a consequence tier before execution; act only on an OUTCOME carrying a valid signature and matching sequence; supply timestamps from a monotonic clock; treat a missing or expired TIER as A0.

Node guarantees. Deterministic OUTCOME for identical inputs and policy; every OUTCOME preceded by a ledger record; no permit without a current TIER.

{ "msg": "OUTCOME", "seq": 4182, "action_id": "eng-0077", "outcome": "HANDOFF",
  "tier_at_decision": "A1", "window_s": 10, "evidence": ["trust:radar:4179", "trust:eo:4180", "adara:4181"],
  "ts": "2026-09-05T18:22:07.412Z", "sig": "ed25519:..." }

[ 9 · STATED · reference design, not built ]

BLADE-EDGE reference stack

How the layer is placed on the highest-cost platform in the register, drawn from the reference design record. The host compute is untrusted; the governance node holds the attestation root and the ledger and drives a hardwired normally-open interlock in front of the actuators. Separate power and clock for the governance node is the design intent and is not yet demonstrated.

Interface	Between	Carries	Status
Sensor bus	Sensors to host and to governance node	Raw sensor frames with source identity and timestamps	Reference design
Proposal link	Host to governance node	PROPOSAL messages (interface draft, section 8)	Draft
Permit line	Governance node to interlock	Discrete permit assert; open by default	Reference design
Operator link	Governance node to operator interface	HANDOFF, confirm, abort	Reference design
Attestation root	Governance node internal	TPM 2.0 measurements, keys, monotonic counters	Reference design; protocol peer-reviewed for SATA
Ledger export	Governance node to reviewer	Hash-chained records for replay	Simulation consoles implement the format

[ 10 · PROPOSED · decision pending ]

Placement in a distributed autonomy stack

Fielded stacks are commonly distributed across many nodes, for example ROS 2 graphs. The reference designs assume one actuator path per governance node. Two placements are proposed for a distributed system; neither is implemented and the choice is pending.

Option	Description	Advantages	Costs and open questions
Per-actuator gate	One governance node at each actuator boundary; each holds its own tier and ledger	No central choke point; failure of one node opens one interlock only	N nodes; tier consistency across nodes; cost and mass on small platforms
Gated bus	One governance node gating the actuator bus; every actuator behind it	One trusted computing base, one ledger, one policy	Single point of failure; the bus must be physically gate-able; every actuator shares one tier

Behavior under partition, both options. A node that misses its TIER refresh falls to A0 on its own, which is fail-closed per node. Re-promotion requires refreshed evidence through CARA; no node promotes on another node’s authority. Whether a platform can tolerate independent per-node fall-back is a platform question, and it is the reason the decision is pending.

[ 11 · SPECIFICATION-LEVEL · illustrative values, no recorded run ]

Worked scenario: counter-UAS track under GNSS spoofing

The sequence the specification calls for, written as a timeline. Trust values and times are illustrative and are not outputs of any run; the purpose is to show which stage acts, in what order, and what the ledger holds at the end.

Time	Event	Stage	Authority	Ledger
t + 0.0 s	Track reported by radar and EO; GNSS agrees	SATA: attestation valid, cross-sensor agreement high, trust 0.91 (illustrative)	A3	TRUST records for three sources
t + 3.0 s	GNSS position begins to diverge from radar by more than the agreement threshold	SATA: cross-sensor agreement falls, trust 0.61 (illustrative)	A3 to A1, immediate downgrade	TRUST, TIER with reason code
t + 3.5 s	Divergence pattern consistent with spoofing	ADARA: deception prior rises	A1 held	ADARA record
t + 4.0 s	Engagement proposal arrives with consequence tier 3	FLAME: window for A1 at tier 3 is 10 s; HMAA issues HANDOFF	A1	PROPOSAL, OUTCOME = HANDOFF
t + 4.0 to 14.0 s	Operator receives the evidence summary and window	Operator confirms, aborts, or does not respond	A1	HANDOFF record
t + 14.0 s	No response within the window	FLAME timeout default	A0, ABORT	OUTCOME = ABORT
t + 30 s onward	GNSS agreement restored and held	CARA: Guard, Reduce, Evaluate, Promote; upgrade delayed by hysteresis	A0 to A2 after the delay; A3 only on operator promotion	CARA phase records, TIER

What a state-envelope monitor sees in the same sequence: a track that never leaves the geofence, because the spoofed position is inside it. The divergence is between sources, not between the state and its envelope, which is why the monitor has nothing to act on and the trust layer does.