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:
- Core navigation and recovery — nominal operation, unexpected objects, constrained alternatives, minimum-risk behavior, and route recovery.
- Perception, tracking, and uncertainty — observability delay, reversing tracks, ambiguous evidence, false positives, sensing degradation, and late detection.
- Assurance gates and degraded recovery — integrity, separation assurance, lost-link behavior, goal/safety conflict, blocked corridors, and minimum-risk outcomes.
- 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:
- exact accepted-baseline scope;
- deterministic replay;
- perception and tracking;
- planner and safety-filter behavior;
- authority and human-supervision bounds;
- append-oriented provenance;
- mission outcome within declared scope;
- normalized public-safety boundary and
SYNTHETIC_NULL_SINKtermination.
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:
- Autonomous System Assurance Platform, which requires claims and evidence to be invalidated or suspended when software, model, policy, environment, authority, or reproducibility changes;
- Decision Provenance System Architecture, which separates replayability from decision quality and invalidation from silent deletion;
- Designing an AI Simulation for Real-Time Evasion and Goal-Directed Navigation, which requires truth, belief, intent, candidate, latency, uncertainty, and safety-filter evidence to remain inspectable;
- Autonomous Systems Uncertainty Architecture, which rejects a single confidence value and requires evidence limitations to remain visible;
- Autonomous Delegation Architecture Research, which separates capability, authority, and restored connectivity;
- Human Judgment Interface Design, which rejects a human click as proof of independent judgment.
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.