ADR-0028: R0-D Sealed Residual Evidence and Regenerative Validation

Status: accepted
Date: 2026-07-27

Context

R0-C2 returns an ordinary verified Core artifact, but provenance is still a generator-owned Rust value. A consumer cannot independently determine whether an artifact came from the claimed source, B0 certificate, specialization request, R0-B2 evaluation, budgets, and exact deterministic R0-C2 transform.

Making MixedStaticEvaluation opaque closes in-process mutation. It does not create portable, mutation-evident residual evidence.

Options considered

OptionBenefitCost
Trust ResidualCore fieldsNo new formatPublic fields and provenance can be forged
Hash only the residual artifactDetects artifact mutationDoes not bind source, request, evaluation, or budgets
Store the entire evaluation trace and transformation witnessOffline inspection of every eventLarger format and a second witness language before the relation is stable
Seal identities and regenerate the exact R0-B2/R0-C2 resultSmall canonical evidence; rejects forged claimsValidation repeats specialization work

Decision

R0-D introduces a canonical ResidualEvidence record with a domain-separated hash. Its payload binds:

schema and replay-policy versions
source semantic hash
interpreter-semantics hash
B0 request hash
B0 certificate hash
R0 specialization request hash
canonical R0-B2 evaluation hash and step count
residual semantic hash
residual node and canonical-byte counts

The declared evidence hash is excluded from its own payload.

The canonical evaluation hash covers the request hash, complete/frontier outcome, halt reason, ordered static facts, exact steps, executed-node trace, and skipped-node trace.

Independent admission boundary

The verifier accepts raw source, B0 request, B0 certificate, R0 request, residual artifact, and evidence. It does not accept or trust the emitter’s validated request, evaluation record, or ResidualCore wrapper.

It:

  1. validates the source/B0/R0 request chain again;
  2. checks every evidence provenance field and its canonical hash;
  3. verifies the supplied residual artifact and recomputes its exact metrics;
  4. replays R0-B2 from the validated inputs and compares evaluation identity;
  5. regenerates the deterministic R0-C2 artifact from the replay;
  6. requires exact residual program, semantic hash, node count, and byte count.

This is regenerative validation: independence is at the admission and provenance boundary. It does not claim algorithmic diversity from the R0-B2 machine or R0-C2 transformation kernel.

Rationale

  • A forged certificate cannot select arbitrary static facts because validation never consumes a caller-provided evaluation record.
  • Exact regeneration checks structural correspondence more strongly than a residual-hash-only certificate.
  • The format stays small while R0-C transformations are still evolving.
  • Repeated work is acceptable at the first correctness lighthouse.

Trade-offs

  • Validation costs another bounded R0-B2 evaluation and R0-C2 generation.
  • A shared bug in generation and regeneration is not detected by implementation diversity.
  • The evidence is not yet a compact proof object suitable for a tiny checker.

Differential testing and mutation rejection remain mandatory defenses. A future proof-carrying or independently implemented checker must use a new schema/policy version and ADR.

Consequences

Positive: R0 residual artifacts gain canonical, mutation-evident provenance and a public fail-closed admission API that trusts no generator-owned wrapper.

Negative: verification time is comparable to specialization time.

Non-claims

R0-D evidence does not make the residual native or standalone, does not implement CoreVM0, Futamura P1/P2, Projection Birth, dependency closure, or Nauxogenesis.

Revisit trigger

Changing any payload field, evaluation encoding, replay policy, R0-C determinism rule, or replacing regeneration with a compact proof checker requires a version change and a new ADR.