What are you trying to do?

We are building a safety layer for autonomous systems. When an AI-controlled system, a self-driving car, an aircraft, a ship, a power grid controller, is about to do something unsafe, our proposed layer is intended to detect the configured error condition, pause the action, reduce the AI's authority, and hand control back to a human.

How is it done today, and what are the limits?

Today, safety for autonomous systems is handled three ways: (1) testing to try to catch every failure case before deployment (impossible in the real world), (2) watchdogs that shut everything off when something looks wrong (expensive, kills productivity), or (3) rule-based safety rails that only work for the situations someone thought to write rules for.

None of these handle the real problem: AI systems are asked to act on sensor data that might be wrong, at speeds where humans cannot supervise every decision, in environments where an adversary may be actively lying to the system. The result is that when something goes wrong, there is no graceful path back to human control.

What is new, and why will it succeed?

What is new: AUTHREX is an integrated authority-lifecycle framework that treats authority itself as an engineered lifecycle, proposed as a runtime authority lifecycle informed by sensor trust, represented through selected formal models, and designed for possible enforcement at software, trusted-execution, or hardware boundaries. Instead of building more rules on top of the AI, the program proposes and internally tests components of a governance layer intended to sit between autonomous decision logic and registered action interfaces; physical actuator-boundary enforcement has not been demonstrated.

Why it will succeed: Selected authority-state and consensus components are represented through mathematical models and model checking; other components remain simulated, specified, or proposed. Sensor trust uses Dempster-Shafer evidence theory. Multi-agent agreement uses Byzantine fault tolerance. Authority state machines are model-checked in TLA+; the reported analysis explored 23,748 distinct reachable states at depth 9 (26,397,356 states generated); the result describes the discrete authority automaton under the assumption that instantaneous authority equals its target and does not cover continuous behavior between decision instants. Of 8 stated properties, 5 invariants and 1 liveness property held and 2 properties are vacuous at this bound (one upgrade-path, one trust-authority consistency, TrustAuthorityWeakConsistency). The same authority-governance pattern has been mapped through simulations and reference designs to several domains; cross-domain physical integration has not been demonstrated.

Who cares? If you succeed, what difference will it make?

Defense: The DoD Replicator Initiative and the Collaborative Combat Aircraft program are fielding autonomous systems faster than they can be supervised. AUTHREX is intended to provide an evaluable governance architecture for bounding delegated machine authority; the boundaries are designed for hardware-bound enforcement in the proposed architecture (no built hardware yet).

Commercial automotive: The 467 trend-linked crashes and 14 deaths documented in NHTSA EA22002 are not a Tesla-specific problem; they illustrate recurring authority, monitoring, and intervention risks that other ADAS and ADS programs may also need to address. AUTHREX proposes one governance architecture for evaluating those risks.

Critical infrastructure: Colonial Pipeline, Ukraine grid, and dozens of other industrial control system compromises force operators to choose between contaminated operation and full shutdown. AUTHREX proposes staged authority reduction and recovery mechanisms intended for evaluation in scenarios where operators seek to preserve selected critical functions while containing suspected compromise. This capability has not been demonstrated on operational infrastructure.

What are the risks?

Technical risk: Moving governance to the hardware boundary requires FPGA or ASIC integration at the actuator level. FPGA-based enforcement is a proposed development path; no independently reviewed FPGA implementation or live-silicon test result is claimed. This is where SBIR Phase II funding would validate the design.

Adoption risk: Integrators may resist adding a layer between their AI and their actuators. The counter is that AUTHREX makes AI systems more evaluable: the architecture may support clearer assurance evidence and authority boundaries, but any effect on legal, certification, accreditation, or acquisition risk would require program-specific assessment.

Adversarial risk: An adversary who understands AUTHREX may try to manipulate the sensor trust calculus or the authority handoff conditions. We address this through ADARA (adversarial deception-aware reasoning, a deception prior that can only lower authority) but require red-team evaluation, which is part of the development roadmap.

How much will it cost?

Engineering foundation documented as of October 5, 2026 (internally funded): a public corpus of Zenodo deposits, SSRN working papers, technical reference works, and four peer-reviewed journal articles, three of them bearing on this work (Journal of Hardware and Systems Security and Digital War, both Springer Nature, 2026, and The ITEA Journal of Test and Evaluation, 2026); 7 governance frameworks; 8 reported U.S. provisional patent applications (unexamined); 25 catalogued browser simulations; 12 hardware reference designs, 10 BLADE platforms plus rover and UAV testbeds (BOM-specified, $199 to $505K per design).

Phase I (SBIR, ~$300K over 6 months): FPGA bitstream commissioning on a Zynq UltraScale+ development board. Hardware-in-the-loop validation of the SATA-FLAME pipeline. Red-team evaluation on the Rover testbed.

Phase II (SBIR, ~$2M over 24 months): Full BLADE platform integration, one defense domain (suggested: BLADE-EDGE directed energy or BLADE-AV autonomous ground). Independent verification campaign (planned). TRL 4 to TRL 6 target.

How long will it take?

Completed as of October 5, 2026: engineering foundation documented. All 7 frameworks published, 12 hardware reference designs specified, 10 BLADE platforms plus rover and UAV testbeds, 8 U.S. provisional patent applications reported as filed.

Q4 2026 (planned or in progress): Priority for the next campaign is one demonstrator, not more frameworks: SATA, HMAA and CARA on a single ROS 2 platform, evaluated against the baselines and metrics fixed in the evaluation protocol. The remaining frameworks are out of scope for that demonstrator. BLADE-EDGE prototype assembly · FPGA enforcement-path RTL development (proposed; no reviewed implementation claimed) · UAV testbed flight validation · Nonprovisional filing decisions, pending owner and counsel, for the eight applications.

Q1-Q2 2027: SATA-FLAME on FPGA (TRL 4 to 5 target) · SBIR Phase II submission · BLADE-MARITIME hardware integration · Rover testbed governance validation campaign.

Q3 2027+: TRL 6 target across multi-framework governance on physical hardware · Potential later nonprovisional filings claiming benefit of the provisional applications, subject to applicable requirements and counsel advice · Evaluation partnership or CRADA engagement (planned) · BLADE-AV autonomous vehicle integration testing.

What are the mid-term and final exams?

Mid-term exam (Phase I end, ~12 months): SATA-FLAME pipeline running on FPGA hardware. Red-team evaluation under six attack vectors (sensor spoofing, authority hijack, Byzantine node compromise, jamming, credential theft, physical tampering). Proof of proposed enforcement options (software mediation, protected key storage, trusted execution, hardware-bound interlocks), none yet demonstrated as an independently evaluated, bypass-resistant physical implementation.

Final exam (Phase II end, ~36 months): Full BLADE platform, one defense and one civilian domain, demonstrated under independent evaluation. Success = the governance layer correctly prevents action in adversarial or low-trust scenarios AND correctly allows action in nominal scenarios, measured against defined thresholds.

Commercial exam: One OEM adoption in automotive ADAS or maritime USV, with measurable reduction in false-positive disengagement and false-negative incident rate. Future independent safety and assurance evaluation would require domain-specific processes, evidence, and qualified assessors (candidate mappings include ISO 26262 and MIL-STD-882E system-safety processes); no certification or approval is currently claimed.