Where the Layer Sits. What It Costs. Where It Stops.
This page sets out the engineering basis of the governance layer: 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 labelled 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: coverage, standards scope, timing, failure semantics, interface, placement, and one scenario, each labelled at its standing. Companion to Formal Coverage Status and the reviewer questions on the home 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 ]
Failure-mode coverage by mechanism
The alternatives table on the home page is organised by mechanism. This table is organised 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 behaviour.
| 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 |
[ 2 · 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 behaviour 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 unauthorised 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 behaviour 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 |
[ 3 · 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 home page.
[ 4 · 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.
[ 5 · 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 safe state. The table names the conditions, what is recorded, and the recovery path. None of this has been implemented in hardware.
| Condition | Gate behaviour | 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 |
[ 5b · 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 unrecognised 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.
[ 6 · 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:..." }[ 7 · 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 6) | 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 |
[ 8 · 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 |
Behaviour 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.
[ 9 · 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.