EVULGARE

IMPLEMENTATION RECORD · SYNTHETIC TECHNOLOGY DEMONSTRATION

Decision Review and Evidence Adjudication Workbench

Implementation record for verified reconstruction packages, mandatory contrary-evidence inspection, bounded adjudication, append-oriented assurance-claim lineage, machine-sovereign review, and deterministic non-authoritative review export.

Open the Decision Review WorkbenchOpen the decision-review API contractResearch-to-software traceability →

Decision Review and Evidence Adjudication Workbench

Release: Evulgare.com 2.0.0-rc.15-WIP
Public route: /workbench/decision-reconstruction/review
API root: /api/v2/decision-reconstruction/review
Memory record: .uai/workbench/decision-review.uai

Purpose

The Decision Review Workbench extends the deterministic Decision Reconstruction record with a separate review and adjudication layer. It verifies the source reconstruction package before review controls become available, requires inspection of contrary evidence and unresolved defeaters, preserves historical evidence and claim states, and exports a hash-addressed review package.

A review package is evidence of a bounded workflow. It is not proof of factual truth, cognition, independent judgment, approval, certification, legal liability, sovereign recognition, operational readiness, or authority to act.

Authoritative architecture

The pure Python module app/decision_review.py is authoritative for:

  • reconstruction-package verification;
  • strict review-input validation;
  • review-state classification;
  • required-inspection enforcement;
  • evidence-to-claim relationships;
  • assurance-claim state propagation;
  • review-event hash chaining;
  • append-oriented review lineage;
  • comparison and counterfactual isolation;
  • evidence-package export and verification;
  • public-safety and non-persistence boundaries.

Jinja and vanilla JavaScript may render, navigate, request deterministic derivations, and download evidence. They cannot manufacture a supported claim, change source history, delete evidence, create approval, determine liability, or authorize an action.

Source-package verification

Before review begins, the domain layer verifies:

  1. the source package schema;
  2. the package digest;
  3. deterministic replay from the recorded input;
  4. the source run digest;
  5. the source canonical-history digest;
  6. the source event manifest;
  7. the source frame manifest;
  8. the source package manifest;
  9. accessible equivalents;
  10. synthetic and non-operational declarations;
  11. public non-persistence;
  12. no automatic approval;
  13. SYNTHETIC_NULL_SINK termination.

A package that fails verification cannot enter the review workflow.

Review distinctions

The workbench preserves seven separate observable states:

Review state What the record can establish What it cannot establish
Human click a browser or physical input event occurred comprehension, merits review, or judgment
Procedural confirmation a workflow step was completed substantive evaluation or independent judgment
Merits review evidence, alternatives, contrary indicators, authority, and change impact were inspected cognition or independent judgment
Declared independent judgment conditions associated with an independent assessment were recorded actual cognition, moral understanding, legal approval, or certification
Machine report the primary machine produced a report independence, correctness, or institutional approval
Independent machine review a separately identified reviewer examined primary evidence, contrary hypotheses, authority, defeaters, and abstention conditions legal personhood, sovereign recognition, or legal approval
Abstain / defer the reviewer declined to resolve the claim within available evidence and scope support, rejection, or authority to act

The browser records workflow conditions. It does not claim to observe private reasoning or hidden chain of thought.

Mandatory inspections

A bounded export requires explicit inspection of all six dimensions:

  1. contradictory evidence;
  2. unresolved defeaters;
  3. changed scope;
  4. authority state;
  5. runtime assurance;
  6. change impact.

At least one source evidence record must be opened. A structured rationale and residual unknowns must be recorded. Abstention must remain available as a first-class result.

Evidence adjudication

Evidence-to-claim relationships remain explicit:

SUPPORTS
CHALLENGES
QUALIFIES
DEFEATS
INVALIDATES

INVALIDATES removes current reliance but does not delete the historical record. DEFEATS withdraws current support for the exact scope. CHALLENGES requires qualification or unresolved treatment. Favorable evidence cannot average away a failed authority or proof condition.

Adjudication states

The review layer uses seven conservative states:

SUPPORT CONFIRMED WITHIN BOUNDS
SUPPORT QUALIFIED
CONTRADICTION UNRESOLVED
EVIDENCE INVALIDATED BUT HISTORICALLY PRESERVED
CLAIM SUSPENDED PENDING REVIEW
CLAIM WITHDRAWN FOR CURRENT SCOPE
NOT ESTABLISHED

Claims concerning certification or liability remain NOT_ESTABLISHED regardless of favorable synthetic evidence.

Append-oriented claim lineage

Each review records:

  • root source-package digest;
  • predecessor review digest, when one exists;
  • source canonical-history digest;
  • source package digest;
  • review-lineage index;
  • source-history mutation flag;
  • source-evidence deletion flag;
  • prior-review overwrite flag;
  • lineage digest.

A successor review appends to lineage. It never replaces or deletes the predecessor. Source history and source evidence remain immutable.

Human and machine review

Human review can record evidence access, contrary-hypothesis inspection, available alternatives, authority, duration, rationale, and abstention. A completed form or long duration does not prove cognition or independent judgment.

Machine-sovereign review does not insert a ceremonial human approval step. Independent machine review instead requires:

  • a separately identified implementation;
  • a distinct implementation lineage;
  • primary-evidence access;
  • implementation diversity;
  • independently scoped authority;
  • contrary-hypothesis review;
  • abstention availability;
  • unresolved-defeater reporting.

These conditions support technical independence inside the synthetic workflow. They do not establish legal personhood, international recognition, or legal approval.

Comparison and counterfactual review

The comparison operation shows historical versus reviewed claim states without changing either history.

A counterfactual review branch is labeled:

COUNTERFACTUAL REVIEW — NOT EXECUTED

It receives a separate digest and cannot modify the parent review, parent source history, or canonical review lineage.

Deterministic evidence package

The export contains:

  • exact source-package and source-run identities;
  • verified source manifest;
  • exact review input;
  • review classification and reviewer conditions;
  • mandatory-inspection record;
  • evidence opened;
  • evidence-to-claim relationships;
  • adjudicated evidence states;
  • historical and reviewed claim states;
  • proof lineage;
  • assumptions and limitations;
  • change impact;
  • append-oriented review events;
  • review-history digest;
  • lineage digest;
  • accessible table and narrative equivalents;
  • public-safety boundary;
  • package digest;
  • SYNTHETIC_NULL_SINK termination.

Package verification establishes deterministic structure and byte integrity inside the declared synthetic scope. It does not establish truth or approval.

API v2

GET  /api/v2/decision-reconstruction/review
GET  /api/v2/decision-reconstruction/review/catalog
GET  /api/v2/decision-reconstruction/review/baseline
POST /api/v2/decision-reconstruction/review/run
POST /api/v2/decision-reconstruction/review/compare
POST /api/v2/decision-reconstruction/review/branch
POST /api/v2/decision-reconstruction/review/export
POST /api/v2/decision-reconstruction/review/verify
GET  /api/v2/decision-reconstruction/review/proof

Public POST requests are same-origin, bounded, ephemeral, strict-field validated, and non-persistent. Unknown and operational fields are rejected.

Accessible equivalents

The interface includes:

  • server-rendered source verification;
  • mandatory-inspection checklists;
  • evidence table;
  • assurance-claim lineage table;
  • review-event log;
  • artifact-lineage record;
  • review/adjudication record;
  • plain-text equivalent;
  • raw deterministic evidence;
  • no-JavaScript baseline;
  • keyboard-operable tabs;
  • visible focus;
  • reduced-motion support;
  • forced-color compatibility;
  • narrow-screen reflow without page-wide overflow.

A user who cannot use enhanced JavaScript can still inspect the source identity, evidence, claim states, events, review classification, limitations, unknowns, and public boundary.

Research traceability

The implementation is grounded in preserved canonical reports covering:

  • decision provenance, evidence integrity, causal reconstruction, and the distinction between technical causality and legal liability;
  • human judgment and the distinction between a click, procedural confirmation, merits review, and independent judgment;
  • delegated authority and the principle that capability does not imply authority;
  • conservative assurance-claim states, defeaters, and change-impact propagation;
  • machine-sovereign separation of powers and independent machine review;
  • legal, governance, and public-claim qualifications;
  • the unified Assurance Simulation Workbench and synchronized accessible representations.

The report bodies remain byte-preserved under docs/reports/. Source-derived statements remain source claims unless independently verified.

Public-safety boundary

The workbench contains no real vehicle or ship interface, GPS or operational coordinates, target search, target selection, target ranking, weapon-target pairing, payload or weapon functions, terminal guidance, force authorization, operational rules of engagement, classified data, external command channel, or public anonymous-run persistence.

Every derived public artifact is synthetic and terminates at:

SYNTHETIC_NULL_SINK

Acceptance status

Repository-level deterministic behavior, proof, package structure, report integrity, .uai integrity, Jinja/JavaScript/CSS syntax, accessibility semantics, and browser-harness behavior can be tested locally.

Actual cPanel Python 3.13.14, Flask/MySQL/Passenger, representative browsers and physical devices, WebGPU/WebXR hardware, assistive technologies, dynamic production security, measured performance, legal review, certification, procurement acceptance, and independent claim verification remain separate acceptance gates.