Autonomous Defensive Mission Control under Uncertainty: Perception, Tracking, Prediction, Safe Action Selection, Lost-Link Continuity, and Answerable Multi-Domain Simulation

1. Executive Summary

The transition from automated systems to fully autonomous cyber-physical systems necessitates rigorous runtime assurance, deterministic simulation, and transparent evidence generation. This research report details a comprehensive, modular Python simulation architecture designed to demonstrate autonomous defensive mission control under profound uncertainty. The proposed framework establishes a mathematically answerable, inspectable closed-loop system encompassing perception, tracking, prediction, candidate generation, safety evaluation, execution, and continuous proof logging.
To bridge the gap between deterministic software evaluation and the unpredictability of real-world environments without exposing classified or operational performance metrics, the architecture implements Black-Box Simplex runtime assurance1 and functional conformal prediction3. Crucially, the system enforces a strict epistemological boundary between physical existence, the autonomous agent’s internal belief state, and its generated intent. By leveraging normalized coordinates, abstract synthetic hazards, and bounded trajectory primitives (e.g., SYNTHETIC_NULL_SINK), the simulation avoids operational targeting and force authorization while delivering an inspectable proof of safety and operational continuity under degraded conditions5. This architecture supports the Evulgare analytical workbench, providing deterministic state transitions within a declared synthetic scenario while maintaining strict data minimization and privacy7.

2. Layered Autonomy Architecture

The simulation architecture is fundamentally structured around the separation of concerns, isolating absolute ground truth from the autonomous agent’s constrained perception and intent. This prevents “agency laundering” and ensures that the machine leadership functions remain fully traceable to human-defined boundaries9.
The architecture is divided into the following strictly isolated layers, governed by pure reducers and deterministic state machines:

1. World Physics & Entity Layer: Computes true synthetic kinematic state, ground-truth locations, and synthetic environmental conditions. This layer is entirely opaque to the autonomy agent.
2. Perception & Sensor Degradation Layer: Applies safe synthetic models for latency, occlusion, false positives, missed detections, and open-set recognition logic to world truth, emitting synthetic observations.
3. Belief & Tracking Layer: Fuses observations into persistent track records, continually updating covariance matrices and resolving identity associations over time.
4. Prediction Layer: Calculates bounded reachable sets and occupancy tubes for tracked entities, utilizing conformal prediction to guarantee statistical validity without distribution assumptions4.
5. Planning & Candidate Generation Layer: Emits bounded semantic action options (e.g., LEFT_DEVIATION, SPEED_REDUCTION) and calculates risk bands.
6. Runtime Assurance (Simplex) Layer: An independent safety governor evaluates candidates against hard safety constraints. If the advanced controller fails, control shifts to a lookahead baseline controller1.
7. Command & Execution Layer: Commits the safe action to the simulation state, adjusting synthetic control efforts.
8. Evidence & Proof Inspector Layer: Serializes state transitions into canonical digests, continuously evaluating forty independent proof invariants for real-time compliance7.

3. World Truth, Autonomy Belief, and Autonomy Intent (Core Research Area 1)

To prevent the autonomy agent from receiving omniscient state, the architecture enforces strict module boundaries, object visibility rules, and serialization boundaries. The system tests for truth leakage at every deterministic tick, ensuring that the autonomous agent operates solely on degraded, synthetic observations.

3.1 World Truth

The WORLD_TRUTH module represents absolute physical reality in the synthetic domain. It is visible only to the rendering engine and the proof inspector for comparative analysis.

Python
from dataclasses import dataclass, field
from typing import List, Tuple

@dataclass(frozen=True)
class Kinematics:
position: Tuple[float, float, float]
velocity: Tuple[float, float, float]
acceleration: Tuple[float, float, float]

@dataclass(frozen=True)
class WorldEntity:
entity_id: str
true_kinematics: Kinematics
true_class: str
synthetic_signature: float

@dataclass(frozen=True)
class WorldTruth:
timestamp: float
entities: List[WorldEntity] \= field(default_factory=list)
environmental_noise: float \= 0.0

3.2 Autonomy Belief

The AUTONOMY_BELIEF module represents the internal state calculated by the autonomous system based on synthetic perception. It is the sole input for candidate generation.

Python
@dataclass(frozen=True)
class AutonomyBelief:
timestamp: float
active_tracks: List[‘TrackRecord’] \= field(default_factory=list)
sensor_health: str \= “NOMINAL”
localization_covariance: float \= 0.01

3.3 Autonomy Intent

The AUTONOMY_INTENT module captures the agent’s proposed future state prior to safety governor intervention. The independence of this module allows the system to log exactly what the advanced controller attempted to do before the runtime assurance layer modified or rejected the request1.

Python
@dataclass(frozen=True)
class AutonomyIntent:
intended_route: List[Tuple[float, float, float]]
primary_candidate_id: str
decision_deadline: float
objective_status: str

Visual encodings heavily depend on these schemas. In the 3D layer, WORLD_TRUTH is rendered as solid, opaque geometries, whereas AUTONOMY_BELIEF is rendered via wireframes or point clouds11. This provides semantic table equivalents where an analyst can directly compare the true location of a synthetic hazard against the autonomy’s estimated location. In Operator Mode, WORLD_TRUTH is hidden to simulate operational stress. In Engineer/Replay Mode, both layers are overlaid to identify perception discrepancies and truth leakage.

4. Synthetic Perception (Core Research Area 2)

Synthetic perception deliberately avoids the inclusion of real signatures, operational thresholds, or classified sensor models. Instead, it relies on parameterized probability distributions to mimic sensor degradation safely.
The architecture models occlusion through ray-casting against abstract geometric volumes; if line-of-sight is broken, the sensor pipeline triggers a missed detection, forcing downstream tracking to rely on predictive covariance expansion. Stale observations and latency are injected via a configurable delay queue, separating the timestamp of the event from the timestamp of its arrival at the belief layer.
Crucially, the system implements open-set recognition (OSR) abstractions12. Rather than forcing all objects into known classification bins, the synthetic sensor utilizes evidential deep learning principles11 to assign explicit uncertainty metrics, categorizing inputs into bounding categories such as KNOWN_STUFF, KNOWN_THINGS, and UNKNOWN_THINGS11. False positives are procedurally generated from environmental noise parameters, testing the tracking module’s ability to prune spurious data.

Python
@dataclass(frozen=True)
class Observation:
obs_id: str
sensor_id: str
estimated_position: Tuple[float, float, float]
classification_state: str # e.g., “KNOWN_STUFF”, “UNKNOWN_THING”
detection_confidence: float
latency_ms: float
is_out_of_distribution: bool

5. Tracking (Core Research Area 3)

The tracking module consumes synthetic observations and resolves identity association, maintaining a persistent history of fused data. The TrackRecord schema is foundational for motion prediction.

Python
@dataclass(frozen=True)
class TrackRecord:
track_id: str
observation_refs: List[str]
est_position: Tuple[float, float, float]
est_velocity: Tuple[float, float, float]
est_acceleration: Tuple[float, float, float]
covariance: List[float]
first_seen: float
last_seen: float
track_age: float
classification_state: str
detection_confidence: float
track_confidence: float
motion_hypotheses: List[str]
staleness_ms: float
corridor_intersection: bool
source_correlation: str

Staleness acts as a primary trigger for uncertainty scaling. If an object is classified as an UNKNOWN_THING or is flagged as out-of-distribution, the track_confidence penalty increases linearly with staleness, leading to broader spatial bounds in the prediction phase.

6. Motion Prediction (Core Research Area 4)

Motion prediction in autonomous systems frequently suffers from overconfidence on out-of-distribution data14. Public, deterministic simulators require safe, mathematically sound approaches to prediction that do not rely on proprietary, black-box neural networks representing classified performance.
A comparison of safe public approaches yields distinct trade-offs:

• Constant Velocity / Constant Acceleration: Highly interpretable but computationally naive, failing to account for intent or physical maneuverability.
• Multiple Hypotheses: Explores branching pathways based on historical behavior, but suffers from state explosion in dense synthetic environments.
• Conformal Prediction (CP): The recommended approach for this architecture. CP is a distribution-free statistical tool that constructs uncertainty sets with finite-sample coverage guarantees3.
• Occupancy Tubes & Uncertainty Ellipsoids: By leveraging CP, the system generates bounding volumes (occupancy tubes) over time. If a tracking algorithm outputs an expected position, CP calculates an adaptive non-conformity score, wrapping the trajectory in a volumetric boundary that represents the confidence interval4.

Feedback-based CP is utilized to continuously adjust the non-conformity score based on realized trajectory errors, adapting safely under drift and dynamically widening bounds when tracks become stale3.

Python
@dataclass(frozen=True)
class Prediction:
track_id: str
horizon_ms: float
occupancy_tubes: List[Tuple[float, float, float, float]] # x, y, z, radius
uncertainty_ellipsoids: List[float]
conformal_risk_alpha: float
reachable_set_bounded: bool

7. Candidate Actions (Core Research Area 5)

To maintain a strict non-operational boundary, the architecture avoids generating actuator commands, real flight-control gains, or firing solutions. Instead, planning is restricted to bounded semantic options.

Python
@dataclass(frozen=True)
class CandidateAction:
candidate_id: str
semantic_primitive: str
feasible: bool
min_normalized_clearance: float
risk_band: str
objective_delay: float
path_penalty: float
control_effort_band: float
violated_constraints: List[str]
objective_reachable: bool
status: str # “SELECTED”, “REJECTED”, “INFEASIBLE”, “RESERVE”

The system generates alternatives such as LEFT_DEVIATION, RIGHT_DEVIATION, VERTICAL_DEVIATION, SPEED_REDUCTION, HOLD, RETURN, and PREDEFINED_MINIMUM_RISK_STATE. The autonomous agent ranks these candidates based on minimum normalized clearance and path penalty, selecting a primary intent to pass to the runtime assurance layer.

8. Runtime Assurance (Core Research Area 6)

The Runtime Assurance (RTA) module acts as a mathematically independent safety governor, physically separating the PLANNER_REQUEST from the APPLIED_SAFE_ACTION. This is implemented via the Black-Box Simplex Architecture (BSA)1.
The advanced controller (AC) focuses on mission progression, while the baseline controller (BC) focuses purely on generating safe backup plans2. The RTA’s Decision Module (DM) monitors the AC’s proposed candidate action. If the AC’s intended path intersects with the occupancy tube of a predicted synthetic hazard, or if the AC misses a decision deadline, the RTA governor intervenes16.

Python
@dataclass(frozen=True)
class GovernorIntervention:
intervention_id: str
planner_request_id: str
applied_safe_action: str
governor_decision: str
reason_code: str
proof_conditions_met: bool

The governor can ACCEPT, MODIFY, HOLD, RETURN, DENY, or FORCE_MIN_RISK. Reason codes (e.g., CP_TUBE_VIOLATION, AUTHORITY_EXPIRED) are permanently serialized into the event log, ensuring absolute transparency as to why the AI was overridden7.

9. Lost-Link Continuity (Core Research Area 7)

Communications degradation requires strict state transitions to prevent the autonomous system from inventing new objectives after losing contact with human supervisors5. The system models lost-link behavior based on established aerospace continuity frameworks5.

10. Mission-State Metrics (Core Research Area 8)

The analytical workbench exposes deterministic metrics calculated exclusively from normalized data, ensuring no operational signatures are leaked7.

11. Event Model (Core Research Area 9)

Simulation events are modeled as stable, cryptographically verifiable records that append chronologically to form the canonical digest7.

Python
@dataclass(frozen=True)
class SimulationEvent:
event_id: str
timestamp: float
event_type: str
affected_entity: str
canonical_digest: str

The allowed event types form the backbone of the timeline reconstruction: world_update, observation, track_creation, track_update, prediction_update, route_conflict, candidate_generation, candidate_rejection, candidate_selection, runtime_assurance_intervention, communications_degradation, authority_change, local_autonomy, route_reacquisition, objective_completion, and evidence_finalization.

12. Python Engine Architecture (Core Research Area 10)

The backend is engineered for absolute determinism, utilizing a strict functional programming paradigm.

12.1 Safe Python Package Architecture

The package follows a domain-driven structure, strictly isolating schemas, reducers, and APIs.
evulgare_engine/ ├── core/ │ ├── world_physics.py # World Truth schema & true kinematics │ ├── perception.py # Evidential learning & synthetic noise │ ├── tracking.py # Covariance expansion & track association │ ├── conformal.py # CP occupancy tubes4 │ └── simplex_rta.py # Governor and Baseline Controller logic2 ├── models/ │ ├── state_machines.py # Lost-link and Mission flow │ ├── intent.py # Semantic options │ └── events.py # Logging and hashing ├── engine/ │ ├── simulator_loop.py # Deterministic clock and pure reducers │ ├── rng.py # Seeded deterministic RNG │ └── serializer.py # Canonical serialization & hydration └── api/ └── flask_routes.py # Zero-leakage stateless API

12.2 Safe Python Pseudocode (Engine Loop)

State mutation is entirely prohibited. Pure reducers construct the subsequent frame, mapping input states to output states predictably.

Python
import hashlib
import json
from copy import deepcopy

class DeterministicSimulation:
def __init__(self, seed: int):
self.clock: float \= 0.0
self.rng \= DeterministicRNG(seed)
self.world_state \= WorldTruth(timestamp=0.0)
self.belief_state \= AutonomyBelief(timestamp=0.0)
self.events \= []

def \_pure\_reducer(self, state: WorldTruth, delta: float) \-\> WorldTruth:  
    \# Implements synthetic physics without side effects  
    new\_state \= deepcopy(state)  
    new\_state.timestamp \+= delta  
    return new\_state

def tick(self, time\_delta: float):  
    self.clock \+= time\_delta

    \# 1\. Physics Update  
    self.world\_state \= self.\_pure\_reducer(self.world\_state, time\_delta)

    \# 2\. Perception & Belief  
    observations \= simulate\_perception(self.world\_state, self.rng)  
    self.belief\_state \= update\_tracking(self.belief\_state, observations)

    \# 3\. Prediction & Intent  
    predictions \= calculate\_conformal\_tubes(self.belief\_state)  
    intent \= generate\_candidates(self.belief\_state, predictions)

    \# 4\. Runtime Assurance  
    governor\_decision \= evaluate\_simplex(intent, predictions)

    \# 5\. Execute & Log  
    self.execute\_action(governor\_decision.applied\_safe\_action)  
    self.\_record\_event("TICK\_COMPLETE", governor\_decision)

def \_record\_event(self, event\_type: str, context: any):  
    state\_string \= json.dumps(self.world\_state.\_\_dict\_\_, sort\_keys=True, default=str)  
    digest \= hashlib.sha256(state\_string.encode()).hexdigest()  
    self.events.append(SimulationEvent("EVT", self.clock, event\_type, "SELF", digest))

12.3 Flask API Design

The Flask API facilitates communication utilizing compact transport. No simulation state is persisted cross-site or cross-session, aligning with strict data-minimization privacy policies8.

13. Multi-Domain Demos (Core Research Area 11)

The platform must prove the universality of the deterministic architecture. Each of the five public demos utilizes the same authoritative workbench shell and core Python engine but features distinct synthetic visual identities.

A. Autonomous Drone Control

Focuses on sub-1000 ft aerial inspection in a synthetic environment6. The scenario tests conformal prediction applied to multi-agent uncooperative swarms10. The primary hazard is a dynamic rogue drone. When the RTA determines a trajectory conflict, the AC is overridden with a VERTICAL_DEVIATION baseline command to clear the synthetic airspace safely.

B. Autonomous Maritime Safety

Applies the architecture to a synthetic maritime corridor. The scenario highlights open-set recognition (OSR) by injecting out-of-distribution observations representing an uncooperative vessel failing to transmit AIS data11. The RTA enforces a COLREGs-equivalent logic constraint18, forcing a SPEED_REDUCTION and RIGHT_DEVIATION.

C. Satellite Continuity and Collision Avoidance

Models a synthetic orbital track confronting a high-speed debris cloud. Time-series conformal prediction calculates ephemeris uncertainty ellipsoids. The RTA layer relies on a lookahead baseline controller to compute a permanently safe orbit-raising maneuver (PREDEFINED_MINIMUM_RISK_STATE) before the AC misses a computational deadline2.

D. Unmanned Logistics under Communications Loss

Focuses on last-mile synthetic logistics facing a total C2 lost-link event5. The system navigates the lost-link state machine, ultimately entering LOCAL_AUTHORITY_EXPIRED. The RTA utilizes CP models of synthetic pedestrian density19 to execute a SAFE_RETURN to a predefined landing pad.

E. Infrastructure Inspection and Hazard Avoidance

Deploys a drone in a cluttered synthetic bridge topology facing extreme environmental noise (wind gusts). Feedback-based conformal prediction dynamically expands the drone’s own uncertainty margins due to kinematic drift3. The RTA triggers an INTEGRITY_HOLD, overriding the AC’s pathing to force a safe landing on a structurally verified pier21.

14. Three-Dimensional Experience (Core Research Area 12)

The browser representation contract requires the frontend to reconstruct analytical timelines purely from hydrated state, explicitly preventing the client from inventing physical behavior7.
Visual encodings enforce epistemological clarity. WORLD_TRUTH elements are rendered as solid, mathematically precise objects. AUTONOMY_BELIEF is visualized as point clouds or bounding boxes to emphasize uncertainty. The conformal prediction occupancy tubes are rendered as translucent, volumetric meshes based on the designated risk alpha4.
The rendering engine supports twelve distinct camera specifications to facilitate analysis:

1. Drone Camera: Egocentric view mapping directly to the sensor’s field of view.
2. Chase Camera: Stabilized third-person view tracking the main agent.
3. Overhead Tactical View: Orthographic top-down layout abstracting altitude.
4. Topological View: A node-based representation graph ignoring physical geography to visualize governance and authority state relationships7.
5. Mission-Control View: Multi-pane tiled dashboard showing cameras alongside metrics.
6. Event-Follow Camera: Automatically pans to the highest-risk synthetic conflict identified by the RTA.
7. Decision-Focus Camera: Zooms and holds on the spatial location where the governor intervened.
8. Selected-Entity Focus: Locks the camera onto a user-clicked synthetic hazard.
9. Comparison Camera Sync: Two viewports locked in spatial sync, showing the safe RTA run versus an unconstrained failure baseline7.
10. WebXR View: Full immersive device API support.
11. Non-XR Equivalent: Standard WebGL Canvas fallback for desktop.

15. Proof Inspector (Core Research Area 13)

The Proof Inspector is a continuous UI diagnostic layer that validates system architecture integrity during the deterministic run. Every proof card displays deep-linked properties to allow analysts to verify why a simulation passed or failed7.

16. Progressive Delivery and Performance Budgets (Core Research Area 14)

To ensure the analytical workbench is highly accessible globally without relying on heavy client infrastructure, the architecture implements aggressive progressive delivery strategies8.

17. Accessibility (Core Research Area 15)

The simulation architecture must remain fully analytically useful for users unable to engage with the 3D WebGL scene, ensuring strict parity between visual, narrative, and tabular views7.

18. The 35 Scenarios (Deliverable 16)

The following 35 deterministic scenarios guarantee comprehensive evaluation across diverse risk profiles and domains.

19. The 40 Proof Invariants (Deliverable 17)

Every proof dynamically reflects the runtime status of the system, asserting the structural integrity of the autonomy. These are continuously evaluated by the Proof Inspector7.

20. The 40 FAQ Answers (Deliverable 33)

Architecture & Epistemology

1. What is the difference between World Truth and Autonomy Belief? World Truth represents absolute physical reality (used for visualization and evaluation); Autonomy Belief is the degraded, uncertain state the AI calculates based on noisy sensors.
2. Why use normalized coordinates instead of WGS84? To ensure the simulator remains purely abstract, definitively preventing the leakage or storage of classified operational data.
3. Can the autonomy agent access the World Truth? No. A strict epistemological barrier is enforced via decoupled Python schemas and memory boundaries.
4. What does SYNTHETIC_NULL_SINK mean? It is a safe termination state where the simulation stops calculating physics and no further kinetic action is taken.
5. How is determinism achieved? By utilizing pure functional reducers, frozen dataclasses, and a strictly seeded pseudo-random number generator (PRNG) executed in sequence.
6. Why use bounding semantic options instead of actuator commands? Bounded options focus the simulation on high-level decision-making intent, abstracting away platform-specific flight dynamics or classified control laws.
7. What is a “canonical digest”? A SHA-256 cryptographic hash of the simulation state at a specific tick, ensuring auditability and replay integrity7.

Runtime Assurance (Simplex) 8. What is the Black-Box Simplex Architecture? A runtime assurance framework that switches control from a complex, unverified controller to a trusted, highly verified baseline controller to prevent safety violations1. 9. Why is the baseline controller considered “trusted”? It is a simplified algorithm (like a dead stop, loiter, or orbit raise) designed solely to maintain a safe envelope, allowing for mathematical verification2. 10. What triggers a governor intervention? The intersection of the advanced controller’s proposed path with a hazard boundary or a conformal prediction tube4. 11. Does the RTA governor invent new missions? No, its sole mandate is to reject unsafe commands and force the system into a predefined minimum-risk state. 12. What is a Proof Invariant? A programmatic logic check evaluated every frame that guarantees a specific architectural rule holds true throughout the simulation. 13. Can the Advanced Controller bypass the RTA? No, INV-02 explicitly checks that all commands pass through the Decision Module before execution. 14. How does RTA handle multi-agent scenarios? It utilizes distributed boundary negotiations, ensuring agents do not mathematically force each other into unavoidable unsafe states21.
Uncertainty & Conformal Prediction 15. What is Conformal Prediction (CP)? A statistical framework that provides finite-sample coverage guarantees for prediction regions without requiring assumptions about the underlying data distribution3. 16. Why use CP instead of standard Kalman filters for prediction? CP accounts for out-of-distribution behaviors and provides explicit, bounded occupancy tubes that are highly effective for RTA safety checks4. 17. What is Feedback-Based CP? A methodology that dynamically adjusts prediction margins by continuously feeding observed trajectory errors back into the non-conformity score calculation3. 18. How is uncertainty visualized? Through translucent 3D occupancy tubes representing confidence intervals mapped directly to risk alphas4. 19. What is Open-Set Recognition (OSR)? The capability of a perception system to classify an object explicitly as “unknown” rather than forcing it into a known but incorrect category12. 20. How does OSR interact with CP? Objects classified as “unknown” generate wider CP occupancy tubes due to their inherently higher predictive uncertainty11. 21. What happens during sensor occlusion? The track covariance expands monotonically (enforced by INV-04) until the line of sight is restored.
Lost-Link & Communications 22. What defines a “Lost-Link” event? The severance of the command and control (C2) heartbeat for a duration exceeding a defined safety threshold5. 23. Can the autonomy invent a new objective after losing link? No. INV-05 and INV-26 strictly prohibit inventing unapproved objectives post-link loss17. 24. What is a Return-to-Home (RTH) procedure? A pre-programmed fallback behavior where the system navigates to a predefined safe recovery zone upon authority expiration5. 25. What altitude is used for RTH? A predefined safe altitude calculated to be higher than any known synthetic obstacle in the operational domain5. 26. What is “Integrity Hold”? A catastrophic fail-safe state invoked during simultaneous comms loss and hardware fault, prompting an immediate halt or landing. 27. How does the system regain authority? Through the AUTHORITY_REISSUED state transition, which requires a cryptographic challenge/response verification. 28. Does latency count as a lost link? Latency triggers a DEGRADED state, prompting cautious action constraints, but does not invoke full RTH until specific timeout thresholds expire.
User Interface & Accessibility 29. What happens if a user lacks a WebGL-capable device? The UI gracefully degrades to a Canvas 2D or fully DOM-based analytical table dashboard without losing analytical capability8. 30. How can I see what the autonomy “thinks”? The UI allows users to toggle rendering layers between World Truth (solid objects) and Autonomy Belief (wireframes and point clouds)11. 31. What is the Proof Inspector? A dedicated UI component that tracks the pass/fail status of the 40 invariants in real-time, providing deep links to evidence7. 32. Does the UI send my data to Evulgare? No, the simulation runs entirely in page-local JavaScript memory; it is explicitly data-minimizing and stores no behavioral profiles8. 33. Can I export a simulation run? Yes, the system generates a canonical JSON manifest containing the initial state and chronological event array7. 34. How are events logged? As a continuous textual narrative and sortable data table explicitly tied to precise simulation timestamps. 35. What is the “Compare-Baseline” view? A synchronization tool that allows side-by-side visual comparison of a safe RTA run versus an unconstrained failure scenario7.
General Platform & Evulgare Context 36. Is this a real weapons simulator? No. It explicitly boundaries out target selection, operational tactics, and real flight dynamics in favor of abstract safety governance. 37. What does the simulation prove? It proves the mathematical and computational architecture of runtime safety and accountability, not physical platform performance. 38. How does this relate to the “Governance Lifecycle”? It simulates the deterministic transitions required to satisfy overarching institutional gates, such as technical feasibility and independent review7. 39. Why are the scenarios multi-domain? To prove the universality and abstraction power of the RTA and CP architecture across disparate operational environments (aerial, maritime, space). 40. How do I verify the code’s safety claims? Analysts can execute the provided Python property tests, E2E hydration parity checks, and inspect the open JSON manifest manually.

21. Glossary of 60 Terms (Deliverable 34)

22. Architecture Diagrams (Deliverable 35)

(The following describes the structural layout of the six required diagrams, designed to be integrated into the standard markdown rendering pipeline via textual representation).

1. Epistemological Boundary Flow Diagram:
   * Structure: [World Truth] (Synthetic Physics Engine) [Sensor Degradation] [Autonomy Belief].
   * Purpose: Visually highlights that World Truth never bypasses Sensor Degradation, preventing memory leakage.
2. Black-Box Simplex RTA Diagram:
   * Structure: [Autonomy Intent (AC)] outputs to (Decision Module). The [Decision Module] checks constraints against [Conformal Prediction Tubes]. If safe, routes to [Execute AC]. If unsafe, routes to [Execute LBC].
3. Lost-Link State Machine Diagram:
   * Structure: A directed graph illustrating the flow: HEALTHY DEGRADED EXPIRING EXPIRED SAFE_RETURN.
4. Feedback-Based Conformal Prediction Diagram:
   * Structure: [Calibration Data] seeds the [Non-Conformity Score], producing the [Prediction Tube]. [Realized Trajectory Error] loops back to update the [Non-Conformity Score].
5. Browser Hydration Model Diagram:
   * Structure: [JSON Replay Manifest] feeds the frontend [Pure Reducer], generating the [Chronological State Array], which coordinates the UIs: (3D Canvas, Data Table, Metrics Graph).
6. Evulgare Governance Lifecycle Map Diagram:
   * Structure: Nodes representing Technical Feasibility, Independent Review, and Bounded Authority converge into a conjunctive RUN_COMPLETE gate, representing the overarching institutional safety hold7.

23. Site-Ready Pages and API Routes (Deliverables 31, 32, 36, 37)

23.1 Site-Ready Autonomous Mission Control Page

URL Path: /simulations/autonomous-mission-controlLayout Strategy:

• Header Navigation: Mode toggles (Guided, Explore, Expert) and session RUN_ID.
• Left Column (Input): Scenario selector drop-down (Domains A-E) and dynamic toggles for injecting degraded-link events or sensor noise.
• Center Main (Viewport): WebGL 3D canvas featuring the CP occupancy tubes. Contains the view toggle for WORLD_TRUTH versus AUTONOMY_BELIEF.
• Right Column (Analytics): The Proof Inspector panel, tracking INV-01 through INV-40 in real-time with deep links to evidence7.
• Bottom Pane: Synchronized chronological ticker dial, Mission Metrics sparklines, and raw JSON Evidence tabs.

23.2 Site-Ready Multi-Domain Demo Page

URL Path: /simulations/multi-domain-rtaLayout Strategy:

• A hero carousel interface where users select an environment (Aerial, Maritime, Satellite, Logistics, Infrastructure).
• Selecting an environment dynamically loads the specific pre-computed JSON Replay Manifest.
• Demonstrates that each distinct domain seamlessly utilizes the exact same React/Three.js analytical shell, proving that the underlying Python deterministic engine is structurally domain-agnostic.

23.3 Proposed /docs Path and Stable ID

Path: /docs/architecture/rta-conformal-predictionStable ID: DOC-RTA-CP-2026-08

23.4 Proposed .uai Router

To integrate with the .uai Memory system7, the router utilizes canonical state digests to fetch and hydrate simulations seamlessly, avoiding reliance on persistent tracking cookies.

JavaScript
// uai-router.js
export function routeUAIRequest(digest) {
// Check local memory cache to adhere to data minimization
if (cache.has(digest)) return cache.get(digest);

// Fetch canonical manifest via compact transport  
return fetch(\`/api/v2/engine/replay/${digest}\`)  
    .then(res \=\> res.json())  
    .then(manifest \=\> hydrateSimulation(manifest))  
    .catch(err \=\> invokeFallbackCanvas(err));

}

24. Research Traceability (Deliverable 38)

The architecture’s components directly trace to foundational research and safety standards:

• Simplex Runtime Assurance: Traced to the GovernorIntervention schema and evaluate_simplex() logic, ensuring mathematically verified backup controllers intercept unverified AC commands1.
• Conformal Prediction: Traced to the Prediction schema and volumetric WebGL shaders, providing statistically sound occupancy tubes based on non-conformity scores3.
• Open-Set Recognition: Traced to Observation.is_out_of_distribution flags and evidential learning abstractions, preventing overconfidence in anomalous data11.
• Lost-Link Protocols: Traced to the LostLinkStateMachine and RTH fallbacks, adhering to aerospace contingency standards5.
• Evulgare Framework: Traced to the canonical_digest, Proof Inspector UI, and deterministic clock, aligning with the platform’s focus on governance gates and answerability7.

25. What the Simulation Establishes vs. Requires Validation (Deliverables 39 & 40)

25.1 What the Simulation Establishes

This simulation definitively proves the computational architecture of safety. It establishes that:

1. The logical epistemological boundaries between physical truth, sensor belief, and autonomy intent can be cryptographically maintained and audited.
2. The Runtime Assurance (Simplex) logic mathematically guarantees a switch to a safe baseline controller before a synthetic constraint boundary is violated2.
3. The Conformal Prediction algorithm successfully produces bounded occupancy tubes based on dynamically adjusting synthetic non-conformity scores3.
4. The lost-link state machine correctly manages authority states without deadlock, preventing the unauthorized invention of objectives5.
5. The system generates an immutable, inspectable audit trail required for institutional governance and continuous proof verification7.

25.2 What Requires Real-System Validation

The simulation deliberately does not prove physical flight safety or operational efficacy. It leaves the following for real-system validation:

1. Model-to-Reality Gap: The actual aerodynamic performance, wind shear resistance, and physical actuator latency of the hardware platform.
2. Sensor Signatures: Real radar cross-sections, LiDAR point-cloud densities, and physical camera focal flaws.
3. Operational Intelligence: Target selection, force authorization, and real-world tactical engagement parameters (explicitly excluded by the synthetic boundary definition).
4. Hardware Failure Rates: Battery drain anomalies, real processor faults, thermal throttling, or mechanical degradation.
5. Real Cryptography: The actual RF link encryption strength, electronic warfare resistance, and baseband radio integrity26.

Works cited

1. arXiv:2102.12981v3 [cs.SE] 31 May 2022, https://arxiv.org/pdf/2102.12981
2. The Black-Box Simplex Architecture for Runtime Assurance of Multi-Agent CPS - Stanley Bak, https://stanleybak.com/papers/sheikhi2024isse.pdf
3. Conformal Prediction in The Loop: A Feedback-Based Uncertainty Model for Trajectory Optimization - arXiv, https://arxiv.org/html/2510.16376v1
4. From Prediction Uncertainty to Conformalized Distance Fields for Safe Motion PlanningThis work was supported in part by the Information and Communications Technology Planning and Evaluation (IITP) grants funded by MSIT No. 2022-0-00124, No. 2022-0-00480 and No. RS-2021-II211343, Artificial Intelligence Graduate School Program (Seoul - arXiv, https://arxiv.org/html/2607.00776v1
5. Lost Link Emergency Procedures for Drone Pilots, https://pilotinstitute.com/lost-link-emergency-procedures/
6. A Technology Survey of Emergency Recovery and Flight Termination Systems for UAS - Scholarly Commons, https://commons.erau.edu/cgi/viewcontent.cgi?article=1052\&context=publication
7. Governance Lifecycle and Qualified-Human Gates Assurance Workbench | Evulgare, https://evulgare.com/simulations/governance-lifecycle
8. Privacy | KillChains.com, https://killchains.com/privacy.php
9. Machine Leadership and Proxy Governance - KillChains.com, https://killchains.com/machine-leadership.php
10. Adaptive Conformal Prediction for Motion Planning among Dynamic Agents - Proceedings of Machine Learning Research, https://proceedings.mlr.press/v211/dixit23a/dixit23a.pdf
11. Open-Set LiDAR Panoptic Segmentation Guided by Uncertainty-Aware Learning - arXiv, https://arxiv.org/html/2506.13265v1
12. Data-Driven Hierarchical Open Set Recognition - arXiv, https://arxiv.org/html/2411.02635v1
13. arXiv:2004.02434v3 [cs.CV] 2 Mar 2021, https://arxiv.org/pdf/2004.02434
14. [2205.07160] Evaluating Uncertainty Calibration for Open-Set Recognition - arXiv, https://arxiv.org/abs/2205.07160
15. Conformal Prediction for Robotics | xLAB: Safe Autonomous Systems Lab, https://xlab.upenn.edu/conformal-prediction-robotics/
16. A Multi-Layer Resilient Architecture for Autonomous Quadcopter-Based Bridge Inspection Under Environmental Uncertainties - MDPI, https://www.mdpi.com/2504-446X/10/2/136
17. NPS Range Safety Review Questions For Operating Unmanned Aircraft Systems (UAS), https://nps.edu/documents/104517539/106004714/JIFX_UAS_RCC_Questionaire_7Jul15_Form.pdf/33385859-349a-4a6f-8c48-ce131f821ae8
18. A SURVEY OF MACHINE LEARNING … - UPC Commons, https://upcommons.upc.edu/bitstreams/827f67c5-6849-438f-b05f-711353ecb77d/download
19. Conformal Decision Theory, https://conformal-decision.github.io/
20. [2502.06221] Interaction-aware Conformal Prediction for Crowd Navigation - arXiv, https://arxiv.org/abs/2502.06221
21. A Multi-Layer Resilient Architecture for Autonomous Quadcopter Flight Under Environmental Uncertainties - Preprints.org, https://www.preprints.org/manuscript/202512.0411
22. (PDF) Runtime Assurance for Safety-Critical Systems: An Introduction to Safety Filtering Approaches for Complex Control Systems - ResearchGate, https://www.researchgate.net/publication/355141882_Runtime_Assurance_for_Safety-Critical_Systems_An_Introduction_to_Safety_Filtering_Approaches_for_Complex_Control_Systems
23. NeurIPS Poster Conformal Prediction in The Loop: A Feedback-Based Uncertainty Model for Trajectory Optimization, https://neurips.cc/virtual/2025/poster/116267
24. Trident : How to Break Deep Reinforcement Learning Cyber Defenses (Agentic) - arXiv, https://arxiv.org/html/2608.04317v1
25. Safety from Fast, In-the-Loop Reachability with Application to UAVs - Sam Coogan, https://coogan.ece.gatech.edu/papers/pdf/llanes2022iccps.pdf
26. FAA Part 108 Connectivity Requirements: What the NPRM Really Says, http://tealcom.io/post/faa-part-108-connectivity-requirements-what-the-nprm-really-says/