IMPLEMENTATION RECORD · SYNTHETIC TECHNOLOGY DEMONSTRATION

Accepted-Baseline Scenario Regression Assurance

Implementation record for exact-scope accepted baselines, deterministic scenario-suite regression, conservative claim states, evidence-difference lifecycles, and portable hash-addressed evidence packages.

Scenario Regression and Accepted-Baseline Assurance Matrix

Release: Evulgare v1.6.0
Public route: /simulations/autonomous-drone-control/regression
Canonical implementation: app/autonomy_regression.py

Purpose

The Scenario Regression and Accepted-Baseline Assurance Matrix answers a narrow question:

Given an exact, versioned, synthetic baseline, what changed in a candidate run and which named assurance claims still have support?

It does not issue a composite safety score. It does not certify an aircraft, approve an operational deployment, establish legal compliance, or decide responsibility. The workbench preserves the accepted and candidate histories independently so a later reviewer can inspect what actually changed rather than accepting an aggregate pass/fail label.

Accepted baseline

The accepted synthetic baseline is stored at:

app/content/assurance/accepted-autonomy-baselines-v1.6.0.json

The manifest binds acceptance to all of the following:

  • release version;
  • navigation-engine version;
  • comparison-engine version;
  • regression-engine version;
  • policy version;
  • assurance-profile version;
  • configuration version;
  • assumptions identifier;
  • normalized coordinate-system identifier;
  • exact case order;
  • exact normalized input for every case;
  • exact deterministic seed for every case;
  • expected result digest and canonical-history digest;
  • declared public-safety bounds.

A successful result under another version, assumption, seed, or configuration is not silently treated as accepted evidence. The change is surfaced and the affected claims are qualified, suspended for review, or withdrawn for that candidate scope.

Accepted suites

The manifest contains four ordered suites:

  1. Core navigation and recovery — nominal operation, unexpected objects, constrained alternatives, minimum-risk behavior, and route recovery.
  2. Perception, tracking, and uncertainty — observability delay, reversing tracks, ambiguous evidence, false positives, sensing degradation, and late detection.
  3. Assurance gates and degraded recovery — integrity, separation assurance, lost-link behavior, goal/safety conflict, blocked corridors, and minimum-risk outcomes.
  4. Full public synthetic regression suite — all seventeen accepted deterministic cases in their declared order.

The order is part of the accepted record. Browser rendering cannot reorder cases to manufacture a different result.

Candidate profiles

The public workbench provides bounded, versioned candidate profiles:

  • exact accepted replay;
  • later sensing and tracking;
  • expanded prediction uncertainty;
  • unavailable separation assurance;
  • unavailable software attestation;
  • unavailable delegated authority;
  • changed lost-link return policy;
  • software-version scope change with otherwise identical behavior.

All candidate inputs remain within the normalized synthetic input schema already enforced by the autonomy-navigation engine. Unknown fields and operational terms such as latitude, longitude, target coordinates, flight protocols, or payload commands are rejected.

Independent regression dimensions

Every case is evaluated across separate evidence dimensions:

Dimension Question
Normalized input Did any accepted field or seed change?
Mission outcome Did the declared synthetic mission result change?
Selected trajectory Did the deterministic candidate selection change?
Safety filter Did runtime assurance intervene or modify the applied action?
Event sequence Did the append-oriented event-code sequence diverge?
Latency Did deterministic reaction timing change beyond the declared bound?
Minimum separation Did the normalized closest-separation evidence change?
Proof state Did a named invariant regress, recover, appear, or disappear?
Assurance claims Which named claims remain supported, qualified, under review, or withdrawn?
Public boundary Did every result remain synthetic, normalized, non-persistent, and null-sink terminated?

One passing dimension cannot compensate for a withdrawn claim in another dimension.

Evidence-state vocabulary

The matrix uses four scoped states:

  • PASS — the evidence matches the exact accepted scope for the named claim.
  • QUALIFIED — evidence changed, but the claim remains supported only with an explicit qualification.
  • REVIEW REQUIRED — accepted support is suspended until the change is independently reviewed.
  • WITHDRAWN — the named claim is not supported for the candidate scope.

These are evidence states, not percentages and not a universal readiness, safety, authority, accountability, or blame score.

Named claims

The v1.6.0 matrix evaluates eight named claims independently:

  1. exact accepted-baseline scope;
  2. deterministic replay;
  3. perception and tracking;
  4. planner and safety-filter behavior;
  5. authority and human-supervision bounds;
  6. append-oriented provenance;
  7. mission outcome within declared scope;
  8. normalized public-safety boundary and SYNTHETIC_NULL_SINK termination.

Difference lifecycle

A current candidate may be compared with a previous candidate profile. The matrix classifies evidence differences as:

  • newly introduced — present now but absent from the previous candidate;
  • resolved — present in the previous candidate but absent now;
  • unchanged — present in both candidate records.

A resolved difference is not deleted. It remains available in the prior candidate record and in an exported evidence package.

Deterministic evidence package

The evidence export contains:

  • the complete accepted manifest;
  • exact suite case order;
  • candidate profile and candidate scope;
  • per-case accepted and candidate normalized inputs;
  • per-case result, proof, event, and history hashes;
  • separate accepted and candidate history evidence;
  • optional complete replay frames;
  • the named claim matrix;
  • introduced, resolved, and unchanged differences;
  • an evidence-manifest digest;
  • a package digest;
  • source-report references;
  • the explicit public-safety boundary.

The package is deterministic for the same version, manifest, inputs, seed, and export options.

Architecture

Assurance-critical logic is confined to pure deterministic Python functions in app/autonomy_regression.py. That module calls the accepted autonomy-navigation engine and cross-run comparison engine. It creates no database record and performs no network request.

The presentation layers consume authoritative server-derived state:

app/templates/simulations/drone_regression.html
app/static/js/autonomy-regression.js
app/static/css/base.css

JavaScript can request another bounded server-side run and render the returned matrix. It cannot determine claim state, alter an accepted manifest, mutate a canonical history, or persist a public scenario.

Public routes and APIs

GET  /simulations/autonomous-drone-control/regression
GET  /api/v1/drone-control/regression
GET  /api/v1/drone-control/regression/manifest
GET  /api/v1/drone-control/regression/suites
GET  /api/v1/drone-control/regression/baseline?suite=<suite-id>
POST /api/v1/drone-control/regression/run
POST /api/v1/drone-control/regression/evidence/export
POST /api/v1/drone-control/regression/evidence-bundle
GET  /api/v1/drone-control/regression/proof

Public POST requests are ephemeral. They modify no accepted evidence, database record, research report, or .uai memory.

Accessibility

The server renders an authoritative semantic representation before JavaScript executes. The workbench includes:

  • a descriptive status summary announced through a polite live region;
  • semantic tables with captions and scoped row/column headers;
  • text labels in addition to color;
  • keyboard-operable forms, tabs, and downloads;
  • visible focus;
  • responsive horizontal table containers rather than page overflow;
  • reduced-motion compatibility inherited from the core design system;
  • plain-language qualification and evidence-state definitions.

Report traceability

The design is grounded in the canonical report corpus, especially:

Public-safety boundary

The regression system contains no:

  • real vehicle or ship interface;
  • GPS or real-world coordinate input;
  • real route guidance or terminal guidance;
  • target selection or ranking;
  • payload or weapon control;
  • force authorization;
  • operational command channel;
  • public scenario persistence;
  • Node.js or frontend build dependency.

Every applied synthetic action terminates at:

SYNTHETIC_NULL_SINK

Simulation and deterministic regression evidence remain bounded by their declared assumptions. They do not eliminate the reality gap.