CARA: Control Authority Regulation Architecture

National Importance

When autonomous systems experience authority lockout due to trust collapse, sensor failure, or adversarial interference, the system must recover safely rather than remain indefinitely in a degraded or inoperable state. Binary reset approaches (full restart or manual intervention) create dangerous gaps in operational capability, particularly in defense and critical infrastructure where continuous operation is essential.

The Simplex architecture (Sha, 2001) provides binary switching between a complex and a simple controller, but lacks graduated recovery phases. CARA extends this concept by implementing structured recovery through four GREP phases, enabling autonomous systems to restore authority incrementally while maintaining safety guarantees throughout the recovery process.

CARA Architecture

CARA implements deterministic recovery through four structured phases known as GREP (Guard, Reduce, Evaluate, Promote). When HMAA authority enters A0 (revoked), CARA activates automatically and manages the system through recovery:

CARA Pipeline

Key Contributions

• Four-phase GREP recovery protocol (Guard, Reduce, Evaluate, Promote)
• Deterministic recovery behaviors: safe-stop, return-safe, hover-hold, crawl-mode, degraded-teleop
• Terminal non-compensatory policy gate preventing unsafe authority restoration
• Mutual exclusivity guarantee: only one CARA behavior active at any time
• Recovery timing with configurable dwell periods (5-15 seconds sustained trust)
• Formal safety properties: no A0-to-A3 single-step transition possible
• Integration with HMAA authority levels and SATA trust monitoring
• Validated across 350+ simulation runs with zero unsafe recovery actions

Role in the Governance Stack

CARA is activated by HMAA when authority enters A0 (revoked). It uses SATA trust readings to monitor recovery progress and determine when authority can be safely restored. In the rover testbed, CARA manages safe-stop and return-safe behaviors. In the UAV platform, CARA controls safe-land, hover-hold, and return-to-base protocols. CARA ensures that recovery is structured and deterministic rather than relying on binary reset or manual intervention.

The Recovery Governance Problem

When an autonomous system experiences authority lockout (trust collapse causing complete loss of operational authority), it must recover safely. Current approaches implement one of two strategies: full system restart (losing operational context and creating dangerous gaps in capability) or manual intervention (requiring human operator availability that may not exist in contested environments).

The Simplex architecture (Sha, 2001) provides a foundational approach to runtime safety through binary switching between a complex controller and a verified simple controller. However, Simplex operates as a binary switch without graduated recovery phases, making it insufficient for systems that must regain full capability incrementally while maintaining safety guarantees at each stage.

Knight (2002) identifies that safety-critical systems require predictable failure modes with well-defined recovery paths. CARA implements this principle through structured, deterministic recovery that never allows an unsafe state transition regardless of the recovery scenario. Each GREP phase has formally specified entry and exit conditions, ensuring that recovery progress is monotonic and verifiable.

GREP Recovery Protocol

The four GREP phases execute sequentially with strict ordering guarantees. No phase can be skipped, and backward transitions occur only if trust deteriorates during recovery:

Terminal Non-Compensatory Policy Gate

CARA includes a terminal safety mechanism: the non-compensatory policy gate. This gate blocks authority restoration if any single policy condition fails, regardless of how well other conditions are met. High trust in most sensors cannot compensate for a critical sensor remaining in a failed state. This prevents the system from resuming full autonomy when a known-compromised sensor remains in the loop.

Mutual Exclusivity Guarantee

Only one CARA recovery behavior is active at any time. This prevents conflicting commands (e.g., return-to-base and hover-hold simultaneously) and ensures the system always has a single, unambiguous operational mode during recovery.

Recovery Scenario Testing

CARA recovery has been validated across the full range of fault scenarios in both simulation environments:

Key validation results: no A0-to-A3 single-step recovery possible (hysteresis enforced), Guard phase activates within one control cycle of lockout detection, Reduce phase correctly selects highest-trust sensors for minimal operations, non-compensatory gate correctly blocks restoration with any failed sensor, and all GREP transitions logged with timestamps for post-incident reconstruction.

CARA Recovery Simulation

The CARA simulation demonstrates the complete GREP recovery protocol in real-time. Users can inject faults to trigger A0 lockout, then observe the structured recovery process as CARA progresses through Guard, Reduce, Evaluate, and Promote phases.

Simulation Features

Hardware Platform Integration

API Implementation

POST /recovery/evaluate

{
  "authority_level": "A0",
  "fused_trust": 0.18,
  "trust_trend": "rising",
  "current_phase": "GUARD",
  "dwell_elapsed_s": 8.2,
  "sensor_status": {
    "camera": "degraded",
    "lidar": "failed",
    "imu": "healthy",
    "gps": "healthy"
  }
}

{
  "phase": "REDUCE",
  "behavior": "return-safe",
  "can_promote": false,
  "blocking_conditions": [
    "lidar: trust < 0.30"
  ],
  "trusted_sensors": ["imu", "gps"],
  "recovery_progress": 0.22,
  "estimated_restore_s": 42
}

Pseudocode

def cara_evaluate(state):
    if state.authority == "A0" and state.phase == None:
        return activate_guard()              # Immediate safe-stop
    if state.phase == "GUARD" and trust_rising(state):
        return transition("REDUCE")          # Minimal safe behaviors
    if state.phase == "REDUCE" and state.tau > 0.35:
        return transition("EVALUATE")        # Monitor recovery
    if state.phase == "EVALUATE" and state.tau > 0.55 and policy_gate_passes(state):
        return transition("PROMOTE")         # Restore authority
    return hold_current_phase(state)

Scenario: Multi-Sensor Failure Recovery

Selected References

• Sha, L. (2001). Using Simplicity to Control Complexity. IEEE Software, 18(4), 20-28.
• Sha, L. et al. (2001). The Simplex Architecture. IEEE Real-Time Systems Symposium, 2-10.
• Stoller, S. et al. (2012). Runtime Verification with State Estimation. Proc. RV, Springer LNCS 7186.
• Leucker, M. & Schallhart, C. (2009). A Brief Account of Runtime Verification. JLAP, 78(5), 293-303.
• Knight, J. (2002). Safety-Critical Systems: Challenges and Directions. Proc. ICSE, 547-550.

Provable Guarantees

Known Limitations and Failure Modes

Simulation Reproducibility

The simulation supports single-architecture mode (CARA recovery only) and full pipeline mode (CARA integrated with SATA, HMAA, ADARA, MAIVA, and FLAME). Both configurations demonstrate CARA behavior under authority lockout conditions.

Cite This Work

If you reference this architecture in your research, please use one of the following citation formats:

@misc{oktenli2026cara,
  author       = {Oktenli, Burak},
  title        = {Control Authority Regulation Architecture},
  year         = {2026},
  publisher    = {Zenodo},
  doi          = {10.5281/zenodo.18917790},
  url          = {https://doi.org/10.5281/zenodo.18917790},
  note         = {Georgetown University}
}

About This Project

This architecture is part of the authority-governed autonomy research program by Burak Oktenli at Georgetown University (M.P.S. Applied Intelligence). It is published on Zenodo with DOI 10.5281/zenodo.18917790 under CC BY 4.0.

Related: Full Research Portfolio · All Repositories · Rover Testbed · UAV Platform · Evaluation Protocol