How to reason about it
- Structural inspection validates schema and recomputable bindings without re-running policy. Native and npm signed-envelope authentication additionally check consumer trust and pinned context with the same Rust core and canonical report, but still do not re-run policy.
- Native
vouch verify --reexecuteemitscsk.native-reexecution-report/v0: authentication is reported first, then current Native execution under fixed complete-transcript scope, then the current-versus-signed comparison. - Native
vouch gate --require-decisionemits unsigned diagnosticcsk.native-gate-report/v0; the report records whether a live grant was minted but is never itself a capability or accepted gate input. vouch compiled build|inspect|validatehandleslispex.vouch-compiled-artifact/v1. The container binds exact source identities, Core IR, and verified bytecode but is integrity material, not signed evidence.- Opt-in compiled re-execution emits
csk.native-compiled-reexecution-report/v1; compiled gate emitscsk.native-compiled-gate-report/v1. Both are deterministic diagnostic output and cannot recreate their live typed evidence or grant. - Replay compares an explicit corpus and records agree, mismatch, and not-comparable outcomes.
- Receipt type tags and required fields are disjoint from Bridge-report tags and fields.
- The live chain is authenticated evidence -> request-bound authenticated evidence -> reexecuted evidence -> local grant. Each constructor is private. The unchanged serialized v0 reports, bundle, receipt, Bridge value, authentication-only evidence, or caller byte buffer cannot skip a transition or recreate authority.
- PNG/ZIP bytes and inspection JSON are source transport and integrity data, not signed Vouch evidence. The unchanged envelope signs the unchanged receipt context; neither an image, bundle, report, Bridge value, nor decoded byte buffer can recreate live request-bound evidence.
Receipt field groups
| Group | Binds or records | Does not establish |
|---|---|---|
| trust policy v1 source allowlist | consumer approval of the authenticated receipt source identity for the selected key | a new receipt claim, normalized-source approval, input approval, report promotion, or transferable authority |
| input bundle | exact untrusted envelope/source/input bytes supplied to the existing verifier | receipt status, signature authority, trust, report promotion, freshness, replay prevention, or source approval |
| contract/type | csk.differential-receipt/v0 and schema version | future-schema compatibility |
| source/input | exact checked rule and pinned datum bytes/hashes | correctness or completeness of host data conversion |
| execution | lowering/evaluation transcript and observed result | semantic equivalence outside the checked profile |
| identity | declared generator/version and artifact hashes | authenticity, issuer identity, or timestamp truth |
| verification | schema and recomputable byte bindings | honest generation or policy correctness |
| authentication (Native/npm) | authorized signature plus exact source, input, profile, and issuer-engine context; same Rust core yields byte-identical v0 reports | historical execution, freshness, identity, honest deployment, or implementation independence |
| compiled artifact | canonical exact-source identities, Core IR identity, verified bytecode bytes and identity, fixed profile, verifier, VM, and limits | signature, trust, request choice, execution, compiler correctness outside exact re-derivation, or authority |
| native re-execution | both current Native evaluators agree and their complete canonical transcript equals both signed observations | independent witnessing, authorization, policy correctness, or whole-language equivalence |
| compiled native re-execution | request-bound authentication and current tree/Meaning agreement remain valid; the artifact exactly re-derives from that source and the verified current Rust VM matches the same signed transcript | independent implementation equivalence, freshness, replay prevention, organizational identity, source or policy correctness, or external-action authority |
| general Topaz VM request, result, or comparison | what the exact installed non-Vouch engine observed for exact verified bytecode, with product lineage and zero fallback | authentication, compiled Vouch agreement, evidence, grant, independent equivalence proof, or external-action authority |
| Topaz AOT product, source map, artifact, executable, inspection, validation, or run result | exact generated and installed execution material plus bounded local observations and zero fallback | Vouch ingress, authentication, request-bound re-execution evidence, gate grant, publisher identity, or equivalence proof |
| four-route comparison receipt | one exact source/input/Core IR/bytecode request, four explicit route observations, semantic and comparable-resource mismatch axes, lineage, and zero-fallback state | authentication, a new implementation family, whole-profile proof, compiled Vouch evidence, a gate grant, or permission for an external action |
| local decision gate | live re-executed evidence exactly matches one required decision in the current Native invocation | transferable authority, freshness, replay prevention, identity, deployment safety, or permission for an external action |
| compiled local gate | live compiled re-executed evidence matches one required decision with basis csk.current-native-compiled-agreement/v1 | a reusable capability; the serialized report cannot be submitted as evidence or permission |
A common mistake
Hashes establish byte binding and internal consistency, not authenticity or honest generation. Re-execution agreement does not establish freshness, historical execution, independent witnessing, policy correctness, or whole-language equivalence.
The Topaz VM transport is intentionally disjoint from every live Vouch
constructor. A Topaz request/result, provider manifest, executable hash,
observation, or compare-vms receipt cannot replace the dedicated
source-derived compiled artifact or the current Rust VM step.
The same disjointness covers every AOT manifest, source map, executable,
compare-routes receipt, and report: inspectable or runnable bytes do not
become a live typed capability.
Keep going
Keep the Vouch overview nearby: it separates authentication, request binding, current execution agreement, and a local grant.