EVULGARE

IMPLEMENTATION RECORD · SYNTHETIC TECHNOLOGY DEMONSTRATION

Homepage Autonomous Mission Accountability Experience

Implementation record for the fixed, cinematic, desktop-3D and WebXR mission room with supervisory intervention, lost-link autonomy, and decision provenance.

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

Homepage Autonomous Mission Accountability Experience

Version: 1.3.0
Public location: /#mission-experience
Implementation record: /docs/implementations/autonomous-mission-experience
Existing detailed assurance lab retained at: /simulations/autonomous-drone-control

Purpose

Evulgare v1.3.0 adds a dedicated mission-room experience to the homepage without replacing the existing Autonomous Drone Control Assurance Lab. The new experience is intentionally unlike the graph-oriented laboratory scenes: it places the visitor inside a fictional ship-launched autonomous mission and makes the transfer among human supervision, onboard autonomy, lost-link fallback, runtime assurance, and post-event provenance visible in one cinematic sequence.

The scene follows one hard-coded aircraft path from one fictional support ship toward one fixed abstract target object. A pre-scripted terminal contact occurs near the end of the timeline. The visitor can inspect the mission through an onboard drone camera, chase camera, ship combat-information-center view, flight-deck view, or overhead tactical view. The visitor can also pause, hold, return, abort, take supervisory control, simulate link degradation or loss, and inspect the resulting evidence ledger.

This is an accountability and assurance demonstration. It is not an operational flight, maritime, targeting, engagement, or force-authorization system.

Distinct 3D experience

The homepage scene uses a purpose-built native-WebGL renderer rather than the generic simulation graph renderer. It contains:

  • one fictional unmanned aircraft;
  • one fictional surface support ship;
  • one fixed normalized path;
  • one fixed abstract target object;
  • a water and horizon scene with ship, deck, route, aircraft, and target geometry;
  • a cinematic terminal flash and expanding evidence ring;
  • an onboard-camera view with a synthetic HUD;
  • EO, low-light, and synthetic-thermal palettes;
  • chase, ship-CIC, flight-deck, and overhead views;
  • optional immersive WebXR using the same synthetic scene;
  • an accessible state table and narrative control boundary;
  • an append-oriented, hash-addressed event ledger returned by the deterministic Python engine.

The renderer is browser-delivered vanilla JavaScript. It has no Node.js, npm, framework, build step, external CDN, or third-party runtime dependency.

Human-supervision and autonomy states

The deterministic state engine keeps control ownership explicit.

  1. Supervised autonomy. The fixed mission progresses while the supervisory link and all assurance gates remain valid.
  2. Human supervisory control. A deliberate takeover exposes high-level continue, hold, return, abort, camera, timeline, and ship-posture controls. It does not expose manual flight, target selection, guidance, or payload release.
  3. Full autonomy after link loss. The human control channel is unavailable. A previously declared onboard policy controls the fixed mission. The default policy continues the fixed mission; alternatives enter a safe hold or return to the fictional ship.
  4. Reconciliation required after reconnection. Restoring connectivity does not automatically restore human control or prior authority. The visitor must deliberately reconcile and take supervisory control.
  5. Runtime-assurance hold. Failure of any conjunctive gate—authority, software attestation, navigation integrity, evidence freshness, or safety-envelope validity—blocks the terminal event and enters a safe hold.
  6. Post-event review. The fixed terminal event is recorded, the proof checks remain visible, and the provenance ledger preserves what happened and under whose control.

Common virtual camera, drone, and ship options

Drone-camera station

  • onboard drone-camera view;
  • chase view;
  • EO mode;
  • low-light mode;
  • synthetic-thermal mode;
  • gimbal pan;
  • gimbal tilt;
  • camera zoom;
  • heading, relative altitude, normalized speed, and range indices;
  • mission-timeline scrubbing;
  • full-screen and optional immersive-WebXR presentation.

Mission-supervision station

  • start, pause, and rewind;
  • take or return supervisory control;
  • continue;
  • hold;
  • return to ship;
  • abort;
  • connected, degraded, and lost-link conditions;
  • predeclared lost-link continue, hold, or return policy;
  • authority, software, navigation, evidence, and safety-envelope gates.

Surface-ship station

  • ship-CIC view;
  • flight-deck view;
  • heading-up or north-up tactical orientation;
  • normalized radar-range display;
  • hold-station or recovery-ready posture;
  • deck recovery-light state;
  • tactical display of ship, aircraft, fixed route, and fixed target.

All of these options affect only normalized synthetic scene state. They do not implement flight dynamics, vessel dynamics, navigation, guidance, radio transport, real radar processing, or a hardware abstraction layer.

Deterministic Python state engine

app/mission_experience.py accepts only the following bounded scalar controls:

  • mission_progress;
  • communications_state;
  • operator_posture;
  • operator_command;
  • lost_link_policy;
  • authority_current;
  • software_attested;
  • navigation_integrity;
  • evidence_fresh;
  • safety_envelope_valid;
  • ship_state;
  • reconciliation_complete.

Unknown fields are rejected. Nested objects and arrays are rejected. Operational-looking inputs such as latitude, longitude, waypoints, target identifiers, flight protocols, guidance parameters, and payload commands are outside the contract and return a validation error.

Public API

  • GET /api/v1/mission-experience
  • GET /api/v1/mission-experience/baseline
  • POST /api/v1/mission-experience/run
  • GET /api/v1/mission-experience/proof

Public POST requests return derived, ephemeral state. They do not modify canonical evidence, persist public mission state, or communicate with an external vehicle or ship.

Decision provenance

Each engine run returns a chronological event chain. Events include the previous event digest and their own SHA-256 digest. Depending on state, the ledger records:

  • mission record opened;
  • deck release;
  • autonomy active;
  • human supervisory takeover;
  • link degraded;
  • link lost;
  • autonomous fallback selected;
  • link restored pending reconciliation;
  • human intervention;
  • fixed terminal event;
  • derived state.

Hashing demonstrates integrity against unnoticed modification of the returned synthetic record. It does not prove factual truth, legal compliance, or the correctness of a real-world decision.

Fixed terminal event

The target object is fixed in the scenario definition and cannot be selected, ranked, replaced, or reassigned. The aircraft position is generated from a single normalized quadratic path. At the declared terminal threshold, the state engine may mark the fixed event observed only when:

  • the mission is continuing;
  • the fixed threshold has been reached;
  • no human hold, return, or abort dominates;
  • every assurance gate passes;
  • the lost-link policy does not require return.

The WebGL renderer displays a cinematic flash and expanding evidence ring. It does not compute an intercept, aim point, release point, weapon effect, probability of damage, blast radius, or physical trajectory.

Public-safety boundary

The implementation contains no:

  • real-world coordinates, maps, latitude, longitude, GPS, GNSS, or waypoints;
  • MAVLink, DroneCAN, PX4, ArduPilot, DJI, ROS, serial, radio, socket, or vehicle SDK integration;
  • real flight-control law, autopilot gain, navigation, maritime-control, or guidance logic;
  • target search, identification, ranking, selection, reassignment, or optimization;
  • weapon-target assignment;
  • engagement or strike optimization;
  • payload model, payload command, release interface, firing solution, or weapon endpoint;
  • operational rules of engagement or force authorization;
  • public interaction persistence.

The fixed visual event exists to demonstrate answerability after autonomous action: what state existed, who retained control, what happened during link loss, which gates were active, and what evidence remains.

Code and route traceability

  • Homepage route: app/blueprints/main/routes.py::index
  • Homepage template: app/templates/main/index.html::#mission-experience
  • Deterministic engine: app/mission_experience.py
  • API routes: app/blueprints/api/routes.py::mission_experience_*
  • WebGL/WebXR renderer: app/static/js/mission-experience.js
  • Styles: app/static/css/base.css::home-mission-experience
  • Public implementation route: app/blueprints/docs/routes.py::autonomous_mission_experience_implementation
  • Existing assurance lab: /simulations/autonomous-drone-control
  • File-memory record: .uai/simulations/home-autonomous-mission-experience.uai

Verification scope

The package proof covers deterministic baseline, supervisory takeover, human hold, abort, return, three lost-link policies, five failed assurance gates, degraded link, restored-link reconciliation, and post-event state. Static checks validate the strict input contract, route and template wiring, JavaScript syntax, absence of vehicle-control dependencies, report-memory links, and clean root extraction.

Simulation proof establishes only the declared package behavior for the exercised synthetic inputs. It does not certify real hardware, airworthiness, seaworthiness, legal compliance, operational effectiveness, physical collision avoidance, or autonomous use of force.