Core question: Which source distinctions determine the declared consequence, do those distinctions survive the projection, and are they still connected to the mechanism that governs the effect?
Surface fidelity is not consequence fidelity
API and tool translations are often judged by what remains visible: an operation name, an argument, a schema field, a version token, a guard-looking header. Projection Assurance asks a harder question. If two source situations require different consequences, can the projected action still tell them apart, and does that distinction actually constrain the effect?
Visible information can become decorative. A tool may expose the reviewed version while the underlying operation ignores it at the effect cut. The opposite can happen too: a broad source option may disappear from the agent surface while a narrower target mechanism still realizes the exact source consequence being claimed.
Projection Assurance therefore treats the source consequence as the reference point. Interface similarity is evidence only when it contributes to preserving that consequence.
What has to survive
The framework keeps five questions separate instead of folding preservation into one similarity score.
- Correspondence
- Is the target fact or mechanism legitimately about the same source distinction? A value that merely looks similar is not enough.
- Discrimination
- Do source worlds with different required consequences remain distinguishable in the projected representation?
- Operative Placement
- Does the preserved distinction reach a recognized mechanism at the cut where the consequence is actually governed?
- Exact Realization
- Given the declared mechanism semantics, does the projected action reproduce the source consequence across the bounded worlds?
- Coverage
- How much of the source capability is represented? Breadth stays separate from correctness of the slice that is represented.
These questions can disagree, and those disagreements are often the useful result. A projection can preserve information structurally while failing to use it operatively. Another can expose less surface area while exactly realizing the declared consequence on the supported slice.
A safeguard can survive the interface and disappear at the effect
The GitHub guarded-merge case is the cleanest example. The bounded source consequence says that a merge may proceed when the pull request head is still the reviewed head H0, but a stale request at H1 must be rejected.
The studied projection retains enough information to distinguish H0 from H1. Correspondence and discrimination therefore hold. But the operative merge path does not bind the effect to the reviewed head through the available expected-head guard.
The result is C1 / D1 / O0 with Exact Realization contradicted. The interface has not forgotten the head identity. The failure is that the retained identity no longer governs the consequential merge.
Less surface can still preserve the consequence
The frozen Technical Note evaluation also contains the opposite pattern. In the studied Azure Blob path, the target does not preserve a general overwrite-choice surface. Yet the declared consequence is narrower: create only if the blob does not already exist.
At the effect cut, If-None-Match: * realizes that create-if-absent consequence directly. The source control does not need to survive as the same knob when the target has a different mechanism that preserves the declared consequence exactly.
This is why Projection Assurance is not schema preservation. It can reject a visually faithful projection and accept a structurally different one when the consequence warrants that difference.
Exact realization catches what structure can miss
Structural preservation is necessary for many claims, but it is not the final word. Exact Realization evaluates the projected mechanism against the source consequence over the declared bounded worlds.
The prospectively frozen PayPal holdout in the Technical Note illustrates the point. An idempotency mechanism exists at the effect side, but a static header value is too coarse when the required distinction is logical-operation specific. The evaluation produces a minimal counterexample and, within the predeclared repair vocabulary, a singleton repair.
Here the problem is not the header type itself. The static value fails to encode the logical-operation distinction required by the declared consequence.
The frozen evaluation stays frozen
RISU Technical Note 2026-04 reports the frozen v0.2.0 Evaluation Capsule. That record contains the declared profiles, retained source evidence, qualifications, cryptographic identities, and the reported GitHub, Azure, and PayPal evaluation results.
Consequence-Preserving Projections v0.7.0 is the current separately archived implementation. It strengthens source-contract handling, evidence binding, proof-carrying construction, and certificate checking. It does not rewrite the frozen evaluation or retroactively enlarge the claims reported in the Technical Note.
Later engineering can therefore improve how assurance artifacts are produced and checked while the evidence behind the published evaluation remains fixed.
Research frontier · September 2026
The published Projection Assurance record remains frozen. In parallel, RISU Verify is testing a narrower but harder question: when can a consequence judgment be tied to executable behavior rather than only to a declared target model?
Current rule: one independently grounded forbidden effect can establish regression, but preservation requires closure over the declared consequential boundary. A clean run by itself is never promoted into proof of preservation.
- Observed regression
- For a controlled execution, a concrete forbidden effect can be bound to the exact executable, world, and observed consequence, then checked independently as a regression witness.
- Bounded preservation
- For an exact hermetic program and an explicit finite boundary, independent checkers reconstruct the consequence relation from the program bytes and exhaustively enumerated inputs before testing whether every realized consequence is allowed.
- Independent checking
- The current research path uses separately implemented checkers, fixed known-answer vectors, adversarial mutation tests, and seeded generative differential checks. The producer is not allowed to self-declare a complete realized relation.
- Open boundary
- Positive preservation is not yet claimed for unrestricted native software. The next research problem is how to justify a sound refinement from richer implementations into the bounded execution model without hiding or relabeling consequences.
This frontier does not replace the frozen Technical Note evaluation or the v0.7.0 scientific core. It extends the evidence architecture around the same consequence-centered discipline while keeping broader claims out of scope until a specific artifact earns them.
The checkpoint is a project-level research update, not a claim of external peer-review acceptance or a new general-purpose product release.
Certificate-backed external cases
RISU Verify builds a developer-facing layer over the byte-pinned v0.7.0 core rather than reimplementing its verdict logic. Before a semantic result is accepted, provenance checks bind retained evidence to declared source material. The frozen producer emits a proof-carrying certificate, and a separate compact consumer checks that certificate against the evidence root before the product derives a status.
The retained external cases give the framework three useful kinds of evidence.
- GitHub guarded merge
- Historical negative control. CONSEQUENCE_REGRESSION · C1/D1/O0. The reviewed head remains distinguishable but is not operatively bound to the merge effect.
- Azure DevOps Wiki edit
- External positive control. On the declared existing-page edit slice, the caller-reviewed ETag is carried into If-Match: PRESERVED · C1/D1/O1, Exact Realization established.
- GitHub file update transition
- A real historical before/after software revision under the same byte-identical source consequence contract moves from C0 and contradicted realization to C1/D1/O1 and established realization.
A real revision can change preservation without changing the source consequence
The GitHub create_or_update_file transition is especially useful because the source consequence contract is byte-identical before and after. The question stays fixed: commit only if the current file is still the blob version the caller reviewed; otherwise reject the stale update.
The pair is labeled REPAIR_CONSISTENT_HISTORICAL_TRANSITION. The label says that the pinned after revision preserves the declared consequence where the pinned before revision does not, under the same bounded contract. The upstream issue and pull request identify the historical revisions; they do not determine the RISU verdict.
Visible guards are tested, not trusted
The Azure DevOps positive control also carries a semantic mutation that keeps the same agent-facing operation, the same etag input, the same If-Match header surface, and the same source consequence contract. The only change is operative binding: the caller-reviewed ETag is ignored and the latest fetched ETag is used instead.
The visible safeguard therefore survives while the consequence does not. The result flips from PRESERVED · C1/D1/O1 to CONSEQUENCE_REGRESSION · C1/D1/O0 with MECHANISM_MISALIGNMENT. That mutation is a compact demonstration of why interface inspection alone cannot establish consequence preservation.
The Workbench keeps the proof path inspectable
RISU Verify can package one completed run into a content-addressed .risu.json handoff. The browser-local Workbench rehashes the embedded report, certificate, run manifest, and available logs, checks their cross-references, and renders the already-produced result without issuing a new scientific verdict.
For before/after comparisons, the handoff records whether both runs share the same source_semantic_digest. A focused projection comparison is shown only when the declared source semantics are unchanged. This keeps a software change from being presented as a pure projection repair when the source consequence itself has changed.
Open the RISU Verify Workbench
Result
Projection Assurance makes consequence preservation a testable property of the path from source semantics to agent-facing action. It distinguishes whether the mapping is legitimate, whether consequence-distinct worlds remain distinguishable, whether the retained distinction reaches the effect-governing mechanism, whether that mechanism realizes the source consequence, and how much of the source capability the projection actually covers.
Taken together, the records show why no single interface pattern is a proxy for preservation. Visually similar projections can diverge at the effect, while structurally different projections can still realize the same declared consequence. The assurance record carries the evidence, witnesses, qualifications, and certificate checks that justify that distinction.
Scope of the result
Every result remains relative to a declared source consequence, bounded worlds, retained evidence, explicit semantic premises, and the effect cut under study. Projection Assurance does not establish general agent safety, whole-operation correctness, live-runtime conformance, complete source-model adequacy, or representative ecosystem prevalence.
Coverage is not inferred from preservation of one slice. A certificate-backed result for an existing-page Azure Wiki edit does not certify the whole upsert tool. A historical GitHub result does not become a live deployment certificate. Later RISU Verify product layers do not gain authority to alter C/D/O or Exact Realization from the frozen scientific core.
Research and source record
- Technical Note
- RISU Technical Note 2026-04
- Technical Note DOI
- 10.5281/zenodo.22149639
- Frozen evaluation
- Projection Assurance Evaluation Capsule v1.0.0 · frozen v0.2.0 evaluation
- Evaluation Capsule DOI
- 10.5281/zenodo.22149517
- Current scientific core
- Consequence-Preserving Projections v0.7.0
- Current software DOI
- 10.5281/zenodo.22149593
- v0.7.0 archive pin
- bc3c0be440b1b729d3131a630491cce62f1f885fb305aa46a4483fee0adad72f
- Developer-facing layer
- RISU Verify v0.4.0-rc1 · frozen core remains byte-pinned