Lispex Vouch

The decision being checked

Every Vouch workflow protects one concrete, repeatable decision. A reviewed Lispex rule reads one exact input and returns one result that is ordinary data, such as a refund approval. The party who ran the decision is the issuer, and the party who checks it later is the consumer. Vouch connects those roles across people, machines, and points in time.

Instead of answering the broad question “should I trust this JSON?”, Vouch asks four precise questions, each with its own check and its own failure.

1. Authentication. Did an allowed key sign these exact bytes?
2. Request binding. Do those bytes describe the exact source and input chosen by this consumer?
3. Current execution agreement. Does the current Native interpreter reproduce the same complete result?
4. Local decision. Does that live result exactly match the decision required by this call?

Each stage consumes the named result of the preceding stage. That separation is the core of Vouch.

The evidence a decision leaves behind

When the issuer runs Native vouch issue, the run is captured as evidence rather than as a bare answer. Here is what the signed context pins.

• the exact rule source bytes
• the exact input bytes the rule read
• the fixed checked profile (csk.checked-profile/v1) under which the rule ran and whose forms participate in Vouch
• the complete execution transcripts. Native evaluates the rule twice, once on the built-in interpreter that reads your source directly and once through the Meaning path, the lowered form that same source is first converted into. These docs write that pair as tree/Meaning, and issuance keeps both full transcripts, not just the final value
• the issuer engine identity, a short fingerprint of the bytes of the exact Native executable

Issuance signs this context with the issuer's Ed25519 key, producing a signed container in the DSSE format called the envelope. With --emit-bundle, Native also packs the envelope together with the source and input bytes into one transport file that has a fixed size limit, the bundle.

What the portable artifacts record

A bundle transports the envelope with its exact source and input bytes between machines. lispex vouch inspect checks the file's schema, hashes, and internal bindings. The consumer's trust policy supplies the allowed key, engine identity, and reviewed source for authentication.

The first real claim is authentication. lispex vouch verify checks the envelope against a trust policy, a file written the same way every time, which the consumer creates from a public key, a short fingerprint of the exact program that runs the rule, and rule source they reviewed independently. A successful verify records this result. A key allowed by my policy signed exactly this context. Request binding, current re-execution, and the local gate answer the next three questions in order.

Why the request must come from you

A bundle carries the source and input selected by the issuer. The consumer selects the request by supplying their own exact source and input.

For that second question, the request must arrive from outside the bundle. You supply your own --source and --input, and Vouch checks that the signed context is byte-for-byte equal to them. The bundle is the authentication target. Native re-execution and gate take both external paths as the consumer-owned request and reject an incomplete pair before reading the file.

A fully validated Lispex Image may supply the exact source bytes through --source-image. It changes only how the source is carried. Input choice, trust policy, re-execution, and gate remain separate.

How each tool consumes the evidence

Choose the operation by the question you actually need answered. The table also names the verified Rust VM, a virtual machine that runs compiled instructions instead of reading your source directly.

Re-execution answers the third question. Native runs the rule again now and compares the current complete transcripts with the signed ones. The gate answers the fourth. Within one Native call, the live re-executed result must exactly equal the decision the caller names with --require-decision. That local pass, the grant, lives inside that process and reaches the calling application as the gate result. The report records the decision and its checked context.

The safe default journey uses the pieces in this order.

1. Build a trust policy from a public key, the exact program that runs the rule, and rule source that the consumer reviewed independently.
2. Let the issuer create a bundle for exact source and input bytes with Native.
3. Supply the consumer's own --source and --input as the request.
4. Authenticate with Native or npm.
5. Add Native re-execution only when current execution agreement matters.
6. If you also require the verified Rust VM, build and validate a compiled artifact from that exact source, then add --compiled-artifact.
7. Use the Native gate only when the application requires one exact decision in that same call.

The end-to-end Vouch workflow gives the commands in that order.

The optional compiled route

Vouch can additionally require agreement from the verified Rust VM. The compiled route starts from the same externally supplied exact source and input, re-derives a canonical lispex.vouch-compiled-artifact/v1 container, checks the bytecode, and runs the verified Rust VM. The source request, authentication, current tree/Meaning agreement, compiled observation, and live gate transition remain named stages of one chain.

The Topaz bytecode VM provides a separate diagnostic comparison route. Its installed product emits request and result JSON, execution output, resource observation, and a compare-vms receipt. The Native Vouch route owns the process-local gate grant.

Vouch authority and scope

• A valid signature authenticates an approved key over the exact checked bytes. The recipient trust policy maps that key to its organization and deployment.
• Exact request equality binds the supplied source and input. The calling application manages freshness, expiry, revocation, and replay policy.
• Tree/Meaning and VM agreement records two execution routes within one shared Rust lineage and the exact profile checked by this call.
• Compiled agreement verifies the exact artifact, source, input, transcript, and limits checked by this call.
• A gate grant lives inside the current Native call and reaches the calling application as one local decision.
• Reports, bundles, images, bytecode, VM results, and Bridge artifacts remain inputs to the live verification chain.
• The calling application owns approval and side-effect control for payments, refunds, deployments, and every other external action.

Keep going

Run the end-to-end workflow, or use Artifacts and Reports to look up the exact role of each file.