Receipts, not logs

One of the design decisions we made early in the Handshake spec was to treat signed receipts, not logs, as the primary audit primitive. This is the right call for the agent era, and it's worth explaining why.

The difference, technically

A log is something you write. A receipt is something you sign.

Logs are produced by the systems doing the work, on their own initiative, in whatever format they choose. They are mutable until persisted, often mutable after that, and require trusting the producer. They are useful for debugging and rough accountability. They are not evidence.

A receipt is produced after an action by the executing party, signed with a key bound to a verifiable identity, sealing a specific factual claim: "I, this service, executed this action, on behalf of this agent, with this delegation chain, producing a result whose hash is X." The receipt is short, structured, immutable once signed, and can be verified by anyone who has the executor's public key, without trusting the executor at all.

One of these things scales to a regulator. The other does not.

What receipts unlock

Once every meaningful action produces a receipt, a few things become possible that are awkward or impossible with logs:

• Cross-organizational accountability. When Agent A from Company X calls a service at Company Y, Y produces a receipt that X can verify. No log-sharing agreements, no trust between the orgs, no shared infrastructure.
• Tamper-evident audit. Receipts can be linked into a Merkle DAG and anchored to a transparency log. Any modification, anywhere, becomes detectable.
• Verifiable history without trust. A regulator inspecting an action three years later can verify what happened by checking signatures, without trusting any party's logs.
• Composable accountability. Receipts reference upstream receipts. The full graph of "what happened, why" can be reconstructed from any leaf back to the root.

Why now and not 10 years ago

The receipt primitive isn't novel, Certificate Transparency uses it for TLS certificates, Sigstore uses it for software supply chains, various protocols have used variants for decades. What's new is the use case.

For traditional software, accountability is per-deployment: the audit is "did the right binary run on the right server, signed by the right team." That's a relatively low-volume, low-frequency question. Logs work fine.

For agents, accountability is per-action, and the action volume is enormous, the actions span organizations, and the consequences are increasingly material (real money, real data, real customer-facing decisions). At that scale and stake, "trust the producer's logs" is no longer adequate. The infrastructure has to produce evidence that doesn't require trust to verify.

What we're not doing

We are not building a new observability tool. We are not replacing Datadog or Langfuse or Galileo. Those tools are great at the operational job they do, debugging, performance, eval. Receipts solve a different problem: the legal-and-regulatory problem of proving what happened.

We expect every team that adopts Handshake will keep their existing observability stack. The receipts produced by Handshake can be ingested into those tools, or into compliance archives, dispute resolution systems, regulator portals, without modification.

What's next

The v0.1 spec defines the receipt format, signing requirements, and the basic chaining model. v0.2 (Q3 2026) adds the optional Handshake Registry, a Certificate-Transparency-style append-only log where receipts can be anchored for additional tamper-evidence guarantees. v0.3 adds the Handshake Console, which gives security teams a UI for inspecting, filtering, and exporting receipt graphs for compliance evidence.

If receipts-as-evidence is something you've been wanting and not finding, the spec is here, and the design partner cohort is open.