Verify a signed receipt.

The receipt below is a demo v1 envelope generated by the reference implementation against a simulated write to /etc/sudoers. ZLAR blocked it under rule R032. The record is signed and verifiable with only the public key and bin/zlar-verify. No call to a ZLAR server is required.

A v1 envelope.

receipt.json is the full artifact. The payload field is a canonical JSON object base64-encoded; the sig field is an Ed25519 signature over that payload. Operational detail, such as path and attempted content, is hashed into detail_hash and does not appear in the envelope. The receipt can verify the chain without exposing the content.

{
  "v": 1,
  "id": "000069eb686d4ea342fe654a6b42d212ef750197a2d8",
  "kid": "bd8cbe32df788172",
  "iat": 1777035373,
  "type": "governed-action",
  "payload": "eyJhdWRpdF9ldmVudF9pZCI6ImRlbW8tcmVjZWlwdC12ZXJpZnktMDAxIiwiYXVkaXRfcHJldl9oYXNoIjoiZ2VuZXNpcyIsImF1dGhvcml6ZXIiOiJwb2xpY3kiLCJkZWxlZ2F0aW9uX2NoYWluIjpbXSwiZGV0YWlsX2hhc2giOiI0Y2Q0NjU3NDQwMzUwNjcwMjhiY2UyMWFmYjY5OTVhZWY4N2M1MTEwNTUyOTI2NmZhNWEyMjJiYjNkNDdhYmIyIiwiZG9tYWluIjoid3JpdGUiLCJtYW5pZmVzdF9hZ2VudF9pZCI6bnVsbCwibWFuaWZlc3RfcHJpbmNpcGFsIjpudWxsLCJvdXRjb21lIjoiZGVueSIsInBvbGljeV92ZXJzaW9uIjoiMS4wLjAiLCJydWxlIjoiUjAzMiIsInRvb2wiOiJXcml0ZSIsInRzIjoiMjAyNi0wNC0yNFQxMjo1NjoxMy4wMDBaIn0",
  "sig": "w7Oqctyi1mHnogRJyR6bXZNwWwBBppsHHAKDcAy5lw3ZF6ZIQeHvLgJHalX0Z6R935fgG_tQCeDH2BFjfZ-eBQ",
  "prev": null
}

Raw file: demo/receipt.json

Ed25519, PEM, 113 bytes.

The key that signed the receipt. Verification needs nothing else. No ZLAR infrastructure, no network call, no account.

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAKMpK9MhgPiyZExlIOf6fL98C5baux+xWD4+DEL7IR8U=
-----END PUBLIC KEY-----

Raw file: demo/receipt-signing.pub

One clone, one command.

Expected output:

VALID

Verified. Action "Write" in domain "write" was deny by policy at 2026-04-24T12:56:13.000Z.

--- Receipt Details ---
  ID:         000069eb686d4ea342fe654a6b42d212ef750197a2d8
  Version:    v1 (v1)
  Tool:       Write
  Domain:     write
  Outcome:    deny
  Rule:       R032
  Authorizer: policy
  Timestamp:  2026-04-24T12:56:13.000Z
  Policy:     1.0.0
  Audit ID:   demo-receipt-verify-001
  Signed by:  bd8cbe32df788172 (Ed25519)

Five structural facts.

• A specific action, writing to /etc/sudoers, was attempted through a surface routed to ZLAR.
• A signed rule evaluated the attempt. Rule R032 matched. No AI was involved in the decision.
• The authorizer was the rule, not a person. A person-authorized receipt would name the approver's signing key.
• The record is cryptographically sealed. Any modification to the payload invalidates the signature.
• The receipt is anchored to the audit chain via audit_prev_hash (here "genesis" — the first entry). A production chain links each receipt to the previous receipt's hash; reordering or dropping a receipt breaks the chain and is detectable.

The receipt does not prove the rule was correct, or that the AI had good intentions. It proves what counted as authorized effect: a decision was made by the stated authorizer, against signed rules, at the stated time, and the record has not been tampered with since.

Demo keys, throwaway, reproducible.

This page uses demo keys, not operational keys. Operational deployments choose their own keys and publish the public keys they want third parties to use.

Reproduce this receipt yourself: bash scripts/quickstart.sh generates fresh keys, runs the real gate against four tool calls, and verifies a v1 receipt. Nothing is simulated.