EVULGARE

IMPLEMENTATION RECORD · SYNTHETIC TECHNOLOGY DEMONSTRATION

Autonomy Cross-Run Assurance and Evidence Export

Implementation record for deterministic run-to-run comparison, change-impact review, and bounded JSON evidence export.

Open the comparison workbenchOpen evidence API contractResearch-to-software traceability →

Autonomous Navigation Cross-Run Comparison and Evidence Export

Release: 1.6.0
Canonical lab: /simulations/autonomous-drone-control
Comparison API: POST /api/v1/drone-control/compare
Evidence export API: POST /api/v1/drone-control/evidence/export
Evidence contract: GET /api/v1/drone-control/evidence
Proof: GET /api/v1/drone-control/evidence/proof

Purpose

Introduced in v1.5.0 and preserved in Evulgare v1.6.0, this assurance workspace compares two deterministic synthetic autonomy-navigation runs. The comparison does not merely report whether the final outcome changed. It identifies the normalized inputs that changed, the evidence and decision domains those inputs can affect, whether the selected trajectory or applied safety-filtered action changed, how event sequences differ, whether proof checks regressed, and which assurance claims require renewed review.

The workspace implements the principle that a successful outcome is not enough. A change to sensing latency, uncertainty, authority, supervision, software attestation, navigation integrity, or a safety gate may require review even when the final mission result remains the same.

Cross-run change-impact workflow

  1. The current lab result is retained as the baseline run.
  2. A bounded candidate variation is merged with the baseline normalized input configuration.
  3. Both runs are executed independently by app.autonomy_navigation.run_navigation.
  4. Each run is executed a second time to verify same-version, same-input, same-seed reproducibility.
  5. Input changes are classified into distinct impact domains such as perception, tracking, prediction, planning, reaction margin, authority, human supervision, runtime assurance, software provenance, and mission outcome.
  6. Proof checks and canonical event-code sequences are compared.
  7. Conservative assurance-claim states are derived without using a composite safety, authority, accountability, or blame score.
  8. The comparison receives a deterministic SHA-256 digest.
  9. The browser may download the comparison as JSON. The public endpoint does not persist it.

The comparison is not a counterfactual branch. Both sides are canonical deterministic runs under their own declared inputs. Counterfactual inspection remains separately labeled COUNTERFACTUAL — NOT EXECUTED and cannot mutate either run.

Conservative claim states

The comparison uses these bounded states:

  • UNCHANGED
  • SUPPORTED_WITHIN_DECLARED_BOUNDS
  • SUPPORTED_WITH_QUALIFICATIONS
  • SUSPENDED_PENDING_REVIEW
  • WITHDRAWN_FOR_CANDIDATE_SCOPE
  • NOT_ESTABLISHED_BY_SIMULATION

A candidate may continue to pass all software proof invariants while a claim remains suspended pending review. Passing proof means the packaged deterministic engine followed its declared rules. It does not mean that a changed assumption has been independently validated or that a real vehicle would be safe.

Portable evidence bundle

The evidence export contains:

  • normalized synthetic input configuration;
  • scenario, seed, outcome, selected trajectory, planner request, safety-filter result, and applied synthetic action;
  • append-oriented event timeline and canonical history digest;
  • candidate trajectories and deterministic reason codes;
  • proof checks and proof digest;
  • world-truth summary;
  • accessible table and text equivalents;
  • key replay frames;
  • a frame manifest containing every frame ID, event reference, proof reference, and frame hash;
  • optional complete replay frames;
  • source-report identifiers;
  • explicit public-safety boundary;
  • independent hashes for inputs, timeline, proof, frame manifest, result, and complete bundle.

Full frames are excluded by default to keep the portable artifact compact. A user may explicitly include all bounded replay frames. The export is generated in memory and downloaded by the browser; it is not stored by the public endpoint.

Determinism and integrity

Given the same engine version, normalized input configuration, and scenario seed, the logical history and evidence bundle must reproduce exactly. Browser timing does not participate in decision-state calculation. SHA-256 proves that an artifact has not changed relative to the hashed bytes; it does not prove that the simulation assumptions are true.

Accessibility

The comparison workspace is represented in semantic HTML and does not depend on WebGL. It includes:

  • a baseline-versus-candidate metrics table;
  • a text summary of changed fields, outcome state, trajectory state, and review requirement;
  • non-color-only claim-state labels;
  • a table of affected assurance claims, triggering inputs, and qualifications;
  • keyboard-operable comparison and export controls;
  • an ARIA live region for comparison and export status.

Relationship to accepted-baseline regression

The comparison workspace compares two user-declared bounded runs. The v1.6.0 regression workspace at /simulations/autonomous-drone-control/regression adds a different control: a hash-addressed accepted manifest with exact versions, assumptions, normalized inputs, deterministic seeds, case order, result digests, and history digests. Regression uses the comparison engine as evidence input but evaluates eight named accepted-baseline claims and a newly introduced/resolved/unchanged difference lifecycle. Neither workspace can promote a candidate to an operational baseline or alter accepted evidence.

Public-safety boundary

The comparison and export capability does not add or expose:

  • real GPS or real-world coordinates;
  • operational route planning;
  • real vehicle or ship control;
  • target selection or ranking;
  • terminal guidance;
  • payload or weapon functions;
  • force authorization;
  • MAVLink, PX4, ArduPilot, DroneCAN, DJI, ROS, radio, serial, socket, or other hardware protocols;
  • an external command channel;
  • public scenario persistence.

Every compared run terminates at SYNTHETIC_NULL_SINK.

Verification

Focused dependency-light tests cover:

  • identical-run reproducibility;
  • latency-driven evidence impact;
  • authority-loss claim withdrawal;
  • mission-outcome changes;
  • event-sequence divergence;
  • deterministic evidence-bundle hashes;
  • optional complete-frame export;
  • strict rejection of unknown, invalid, and operational fields;
  • evidence contract and boundary fields;
  • self-test vectors for comparison and export.

Packaged Chromium verification covers the actual Jinja workbench, local JavaScript, deterministic comparison/export downloads, semantic tables, and responsive layout. Remaining acceptance work is production-host Flask/MySQL/Passenger verification, browser smoke/security-header verification against the deployed release, representative WebXR hardware testing, and qualified assistive-technology review.