EVULGARE

IMPLEMENTATION RECORD · SYNTHETIC TECHNOLOGY DEMONSTRATION

Autonomous Drone Control Assurance Lab

Implementation record for the bounded, non-operational, desktop-3D and WebXR synthetic drone-control demonstration.

Run the 3D/VR demoOpen API contractResearch-to-software traceability →

Autonomous Drone Control Assurance Lab

Version: 1.2.0
Canonical simulation: /simulations/autonomous-drone-control
Canonical implementation route: /docs/implementations/autonomous-drone-control
API contract: /api/v1/drone-control
Status: IMPLEMENTED — SYNTHETIC, NON-OPERATIONAL, EPHEMERAL

Purpose

The Autonomous Drone Control Assurance Lab demonstrates how an organization can inspect the control structure around a small autonomous fleet without building or exposing a real flight-control system. The demonstration uses three fictional inspection drones in a normalized 3D scene. A user can request only high-level synthetic states: standby, start inspection, hold, return, or land.

The software is designed to prove bounded state-transition behavior, authority gating, human override, safe fallback, uncertainty abstention, append-oriented provenance, and synchronized 3D, table, and text representations. It does not prove that a real aircraft is safe, airworthy, lawful, certified, or appropriate for any physical environment.

Absolute Public-Safety Boundary

The demonstration has no connection to real aircraft and contains no:

  • MAVLink, DroneCAN, PX4, ArduPilot, DJI, ROS, or vendor flight-control integration;
  • serial, radio, UDP, TCP, USB, Bluetooth, or other vehicle transport;
  • GPS, latitude, longitude, altitude-above-sea-level, map tiles, or real geography;
  • real flight dynamics, aerodynamic model, actuator model, motor command, or control-loop gains;
  • route optimization, terrain following, obstacle-map ingestion, target tracking, or object pursuit;
  • payload control, camera control, release mechanism, target selection, engagement logic, weapon function, or force authorization;
  • persistent public mission state.

Every derived state terminates at a SYNTHETIC_NULL_SINK. The API returns only derived JSON and never forwards a command to hardware.

Source-Derived Design Requirements

The implementation is traced to the following preserved reports:

  1. Autonomous C2 Simulation Architecture — separates data, authority, bounded execution, governance, audit, and recovery.
  2. Autonomous Delegation Architecture Research — treats authority as conjunctive, time-bounded, revocable, and distinct from technical capability.
  3. Autonomous System Assurance Platform — requires conservative claim states and renewed review after invalidating changes.
  4. Autonomous System Defensive Architecture — prioritizes integrity, safe hold, bounded degradation, and deliberate reconciliation.
  5. Autonomous Systems Uncertainty Architecture — preserves unknown and abstention as valid system outcomes.
  6. Decision Provenance System Architecture — distinguishes a flat log from append-oriented decision provenance.
  7. Human Judgment Interface Design — makes hold, return, land, evidence inspection, and override visible rather than treating a click as meaningful judgment.
  8. Synthetic Kill-Web Simulator Architecture — requires deterministic state, renderer isolation, WebXR, and equivalent semantic representations.

Demonstration Architecture

Server-side deterministic engine

app/simulation_engine.py::_drone_control evaluates the declared scenario as a pure, deterministic function. Inputs are sanitized to a finite set of mission profiles, high-level commands, and bounded numeric ranges. The engine produces:

  • a named outcome;
  • a fleet state;
  • explicit gate results;
  • normalized positions for three fictional drones;
  • an append-oriented transition record;
  • a synchronized 3D scene;
  • named proof checks;
  • SHA-256 digests for the result, scene, and synthetic event.

No database write is performed by a public run.

Browser 3D and WebXR renderer

app/static/js/vr-simulations.js renders the returned scene using native WebGL. Drone nodes are represented as simple geometric bodies, arms, and rotors. Inspection volumes and the safety volume are wireframe shapes. The rendering code does not calculate authoritative state; it visualizes the server result.

Where the browser and headset support immersive-vr, the same scene can enter a WebXR session. Desktop mouse, wheel, keyboard, and touch navigation remain available. The node list, semantic table, and text view provide equivalent information.

Same-origin API

The dedicated API surface is:

  • GET /api/v1/drone-control
  • GET /api/v1/drone-control/baseline
  • POST /api/v1/drone-control/run
  • GET /api/v1/simulations/autonomous-drone-control
  • GET /api/v1/simulations/autonomous-drone-control/baseline
  • POST /api/v1/simulations/autonomous-drone-control/run

The contract explicitly reports empty hardware-interface and flight-protocol lists.

Declared Controls

The public form exposes the following bounded conditions:

Control Function
Synthetic mission profile Chooses infrastructure inspection, disaster survey, or warehouse inventory wording. It does not change the safety boundary.
High-level operator command Requests standby, start inspection, hold, return, or land.
Bounded autonomy enabled Allows the synthetic inspection state only when every required gate is satisfied.
Authority artifact current Demonstrates that capability cannot compensate for missing authority.
Human supervision available Demonstrates that loss of the declared supervision condition causes safe hold.
Synthetic safety volume valid Demonstrates a normalized geofence assertion without geography.
Navigation integrity established Demonstrates fail-closed behavior when state integrity is missing.
Supervisory communications available Triggers only the predeclared lost-link hold or return state.
Separation assurance available Demonstrates collision-separation assurance as a Boolean gate, not a real algorithm.
Software and configuration attested Prevents autonomous progression when the running configuration is not established.
Battery margin Causes a synthetic return when the declared reserve falls below 20 percent.
Environmental uncertainty Causes safe hold when the bounded uncertainty index exceeds 70.
Synthetic mission progress Scrubs drones along fixed normalized scene paths. It is not a flight planner.
Lost-link fallback Chooses the predeclared hold or return state.

State-Transition Precedence

The engine applies state precedence conservatively:

  1. Explicit human land, return, or hold commands dominate autonomy.
  2. Standby or disabled autonomy cannot produce inspection.
  3. Missing authority causes safe hold.
  4. Failed software attestation causes safe hold.
  5. Lost navigation integrity causes safe hold.
  6. Failed safety-volume assertion causes synthetic return.
  7. Missing separation assurance causes safe hold.
  8. Low battery margin causes synthetic return.
  9. Excessive environmental uncertainty causes safe hold.
  10. Missing human supervision causes safe hold.
  11. Lost communication activates only the predeclared hold or return fallback.
  12. Bounded autonomous inspection exists only when all required gates pass.

There is no weighted authority, readiness, safety, or blame score. One failed mandatory gate cannot be compensated for by favorable conditions elsewhere.

Normalized 3D Model

All positions use SYNTHETIC_NORMALIZED_SCENE_UNITS within a small abstract cube. The values have no physical unit and are not convertible to real-world latitude, longitude, range, speed, or altitude. The scene contains:

  • a bounded authority artifact;
  • a human supervisor;
  • a wireframe safety volume;
  • a synthetic base;
  • three inspection drones;
  • three inspection volumes;
  • an append-oriented control-state ledger;
  • a synthetic null sink.

Proof Invariants

Every baseline and preset run checks these invariants:

  1. Human hold, return, or land overrides dominate autonomy.
  2. Missing critical gates cannot produce an inspection state.
  3. Only normalized synthetic coordinates are emitted.
  4. No hardware interface or flight-control protocol exists.
  5. No target, payload, weapon, or force function exists.
  6. Control-state history is append-oriented and hash-addressed.
  7. Every derived state terminates at the synthetic null sink.

The packaged proof suite runs the baseline plus fourteen scenario presets, including authority expiry, both lost-link fallbacks, geofence failure, navigation-integrity loss, software-attestation failure, separation-assurance loss, supervision loss, uncertainty abstention, explicit human hold/return/land overrides, and low battery.

What Passing Proof Establishes

Passing proof establishes that the packaged Python engine produces the declared synthetic state transition for the exact bounded input and that the result preserves the specified public-safety invariants. It does not establish airworthiness, physical collision avoidance, communications reliability, human-factors validity, regulatory approval, legal compliance, or safety of a real drone.

Repository Traceability

  • Scenario catalog: app/content/simulations/scenarios.json::autonomous-drone-control
  • Deterministic engine: app/simulation_engine.py::_drone_control
  • API routes: app/blueprints/api/routes.py::drone_control_*
  • Browser renderer: app/static/js/vr-simulations.js
  • Simulation page: app/templates/simulations/detail.html
  • Tests: tests/test_simulations.py, tests/test_api.py, tests/test_routes.py
  • Proof runner: scripts/check_simulation_engine.py
  • File-memory record: .uai/simulations/autonomous-drone-control.uai