IMPLEMENTATION RECORD · SYNTHETIC TECHNOLOGY DEMONSTRATION

Autonomous Drone Control Assurance Lab

Implementation record for the deterministic perceive-track-predict-select-avoid-recover-prove autonomy-navigation assurance laboratory.

Autonomous Drone Control Assurance Lab

Version: 1.6.0
Canonical route: /simulations/autonomous-drone-control
Implementation engine: app/autonomy_navigation.py
Renderer: app/static/js/autonomous-drone-control.js
Template: app/templates/simulations/drone_control.html

Purpose

This public lab demonstrates how a bounded autonomous inspection system can be made technically answerable when an unexpected synthetic object enters its planned corridor. It is an instrumented assurance application, not a flight simulator or operational control system.

The lab exposes the complete deterministic sequence:

PERCEIVE → TRACK → PREDICT → EVALUATE OPTIONS → SELECT → AVOID → RECOVER → PROVE

A default run shows an object becoming observable, a detection and persistent track being created, predicted occupancy intersecting the nominal corridor, candidate trajectories being generated and evaluated, one candidate being selected through stable reason codes, the independent safety filter modifying the planner request when needed, the vehicle following the applied synthetic action, minimum separation being recorded, and the nominal route being reacquired before the fictional inspection objective is reached.

Version 1.6.0 also adds the accepted-baseline regression workbench at /simulations/autonomous-drone-control/regression. That workspace executes ordered deterministic suites against an exact hash-addressed manifest, preserves accepted and candidate histories independently, and reports scoped claim states and evidence differences without changing the 3D/WebXR lab itself.

Deterministic autonomy loop

The domain layer owns all assurance-critical logic. Pure or narrowly stateful deterministic functions implement:

  1. observation generation;
  2. persistent track maintenance;
  3. future occupancy prediction;
  4. conflict detection;
  5. bounded candidate generation;
  6. candidate feasibility and scoring;
  7. deterministic selection;
  8. independent safety filtering;
  9. mission recovery;
  10. event and frame hashing;
  11. named proof-invariant evaluation.

Browser frame rate does not determine logical state. Given the same engine version, input payload, seed, and declared configuration, the logical frame sequence and result digest reproduce.

Representation boundary

The scene and accessible record keep three representations separate:

Representation Meaning Default visibility
World truth What the synthetic world actually contains Hidden in operator mode; available in engineer/replay mode
Autonomy belief Observations, estimates, tracks, and uncertainty available to the autonomy stack Visible
Autonomy intent Nominal route, candidate set, selected trajectory, safety-filter output, and applied synthetic action Visible

A world-truth object cannot appear in autonomy belief before its simulated observability and latency conditions are satisfied.

Object tracking

Tracks use stable IDs such as OBJ-017. Each active track records observation references, first-seen and last-observed times, track age, observed and estimated state, synthetic motion class, detection confidence, track confidence, prediction uncertainty, predicted occupancy, and corridor-intersection status.

The lab does not collapse these fields into one generic “AI confidence” value.

Candidate action engine

The bounded candidate set includes:

  • left deviation;
  • right deviation;
  • vertical deviation;
  • speed reduction;
  • hold/stop;
  • safe return.

Each candidate records feasibility, predicted minimum clearance, risk band, goal delay, path penalty, control-effort band, constraint violations, goal reachability, safety state, and stable reason codes. An infeasible candidate cannot be selected.

The decision panel reports only logged facts and reason codes. It does not expose fabricated model monologue or chain-of-thought.

Safety filter

Planner intent and applied action are distinct records:

NOMINAL PLANNER REQUEST
APPLIED SAFE ACTION

The independent safety layer may preserve, constrain, replace, or reject the planner request. Any intervention is visible in the status strip, decision panel, timeline, accessible record, post-run summary, and proof output.

Real-time synthetic metrics

The engine derives:

  • time to predicted conflict;
  • current and minimum predicted separation;
  • safety-envelope margin;
  • reaction margin;
  • decision deadline;
  • route deviation and predicted goal delay;
  • deterministic planning runtime;
  • sensor-to-track, track-to-plan, command, and total reaction latency;
  • applied-command age;
  • generated, feasible, rejected, and reserve candidate counts;
  • safety-filter intervention state.

Reaction margin is derived from time to conflict minus the declared sensing, tracking/fusion, planning, command, and modeled response delays. Values are synthetic and use only normalized units.

Scenario library

The engine contains 17 scenario definitions and the public registry exposes 26 presets. Coverage includes nominal inspection, sudden crossing, occlusion, static debris, track reversal, high-speed intrusion, multiple convergence, blocked corridor, ambiguous track, decaying false positive, sensor degradation, navigation degradation, unavailable separation assurance, lost link during avoidance, goal/safety conflict, no feasible trajectory, late detection, human hold/return, expired authority, low battery, uncertainty abstention, failed software attestation, unavailable supervision, invalid safety volume, and safe return.

All controls are type-, enum-, length-, ID-, and bounds-validated. Operational-looking or undocumented fields are rejected.

Human supervisory control

Human hold, return, land, and abort commands dominate bounded autonomy where defined. “Take supervisory control” exposes high-level supervisory choices; it does not reveal joystick, steering, thrust, guidance, payload, or direct aircraft controls.

CONTINUE is disabled when no safe trajectory exists. RESUME AUTONOMY is available only after readiness gates pass. Urgent safety behavior does not wait for human confirmation.

Replay and canonical history

Each result contains a bounded, append-oriented timeline with deterministic timestamps, stable event codes, entity references, evidence references, previous-event hashes, event hashes, frame references, and a canonical history digest.

Replay reconstructs recorded frames rather than recomputing browser-timed state. Controls include play, pause, step backward/forward, restart, jump to event, playback speed, and truth/belief/intent overlays.

Counterfactual inspection

POST /api/v1/drone-control/counterfactual supports three bounded comparisons:

  • alternate candidate;
  • later detection;
  • higher uncertainty.

The branch is labeled COUNTERFACTUAL — NOT EXECUTED. It has its own digest and cannot modify canonical frames, events, or history digest.

Named proof invariants

The default result evaluates 14 named checks covering observation/track provenance, feasibility, safety-volume compliance, candidate-selection constraints, critical gates, minimum-risk behavior, human precedence, planner/filter separation, applied-action references, append-oriented history, counterfactual isolation, normalized coordinates, absence of hardware/protocol output, and null-sink termination.

Focused vectors: 11 passing runs.
Catalog contribution: baseline plus 26 presets.
Browser evidence: pass_with_qualification.

API

GET  /api/v1/drone-control
GET  /api/v1/drone-control/scenarios
GET  /api/v1/drone-control/baseline
GET  /api/v1/drone-control/proof
POST /api/v1/drone-control/run
POST /api/v1/drone-control/counterfactual

All POST results are derived, synthetic, non-operational, and non-persistent.

Accessibility

Every important 3D item has an authoritative equivalent representation. The page includes current-frame state, world-truth table, observation/track table, intent and applied-action table, candidate comparison, event timeline, proof table, text description, visible focus, keyboard operation, non-color-only labels and line styles, reduced-motion behavior, responsive critical controls, and a no-JavaScript server-rendered baseline.

Hard boundary

coordinate_system: SYNTHETIC_NORMALIZED_SCENE_UNITS
hardware_interfaces: []
flight_protocols: []
real_vehicle_control: false
real_world_coordinates: false
operational_route_planning: false
target_selection: false
target_ranking: false
terminal_guidance: false
payload_control: false
weapon_functions: false
force_authorization: false
external_command_channel: false
public_persistence: false
output_terminal: SYNTHETIC_NULL_SINK

Passing proof establishes only declared package behavior for exact synthetic inputs. It does not certify a real system, establish airworthiness, prove real-world collision avoidance, determine legal compliance, or eliminate the reality gap.

MISSION-FIRST · EVIDENCE-LOCKED · MACHINE-SPEED

DETECT → VERIFY → DENY → CONTAIN → RECOVER → PROVE

Command integrity. Decision superiority. Compartment security. Attested reconstitution.