Vouch Artifacts and Reports

A native differential receipt binds a declared checked rule, input context, lowering/evaluation observations, hashes, and contract version in csk.differential-receipt/v0.

Current guarantees

  • 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 --reexecute emits csk.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-decision emits unsigned diagnostic csk.native-gate-report/v0; the report records whether a live grant was minted but is never itself a capability or accepted gate input.
  • 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

GroupBinds or recordsDoes not establish
trust policy v1 source allowlistconsumer approval of the authenticated receipt source identity for the selected keya new receipt claim, normalized-source approval, input approval, report promotion, or transferable authority
input bundleexact untrusted envelope/source/input bytes supplied to the existing verifierreceipt status, signature authority, trust, report promotion, freshness, replay prevention, or source approval
contract/typecsk.differential-receipt/v0 and schema versionfuture-schema compatibility
source/inputexact checked rule and pinned datum bytes/hashescorrectness or completeness of host data conversion
executionlowering/evaluation transcript and observed resultsemantic equivalence outside the checked profile
identitydeclared generator/version and artifact hashesauthenticity, issuer identity, or timestamp truth
verificationschema and recomputable byte bindingshonest 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 reportshistorical execution, freshness, identity, honest deployment, or implementation independence
native re-executionboth current Native evaluators agree and their complete canonical transcript equals both signed observationsindependent witnessing, authorization, policy correctness, or whole-language equivalence
local decision gatelive re-executed evidence exactly matches one required decision in the current Native invocationtransferable authority, freshness, replay prevention, identity, deployment safety, or permission for an external action

Boundaries

  • 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.