What a receipt proves, and what it doesn’t.

Every receipt is signed by the operator's Ed25519 key over RFC-8785 canonical bytes. The operator can't later deny, backdate, or quietly alter a record it already produced. Change a single byte and the signature no longer verifies.

When an action is gated, an approver co-signs the same bytes under a distinct, NUL-terminated domain tag, so an operator's authorization can never be replayed as a human's approval. The approve or reject verdict is itself a signed one-byte value, so flipping it on the wire breaks the signature.

Verification is a pure function of the receipt plus the signer public keys. No network, no clock, and no trust in heso. The same Rust canonicalizer runs natively, in the browser via WebAssembly, and in Python, so what was signed always equals what is on the wire.

Receipts in a session are linked by a domain-separated, length-prefixed BLAKE3 chain. Dropping, reordering, inserting, or re-pointing a receipt breaks the chain and names the failure, so tampering is evident to anyone who checks.

An optional RFC-3161 timestamp anchor binds an existed-no-later-than bound to the assembled, post-approval body. Read it narrowly: it proves the approved action existed by that time, not the moment a human decided. Verifying the anchor requires the CLI or backend build. The in-browser verifier fails a present anchor closed rather than pretend to check it.

A receipt records the actions that were wrapped. Nothing forces every action into a receipt, since an operator can simply not instrument a call. The chain catches tampering within a session, but it does not prove the session is the whole story.

A receipt over a wrong, hallucinated, or hostile tool output is still a perfectly valid receipt. It faithfully records that the output happened. heso is evidence of an authorized action, not a correctness oracle for the model and not a counterparty-grade guarantee that the result is true.

A receipt proves a decision was signed under policy. It does not prove the downstream system executed it, that a payment cleared, or that a write persisted. heso sits at the agent/operator boundary, not inside the target system.

Cloud-mirrored receipts are admitted to an RFC-6962 transparency log whose signed checkpoints are anchored to public logs (Rekor, OpenTimestamps), so rewriting history that a checkpoint has covered contradicts the published anchors. Read the boundary: receipts that never reach the cloud mirror are not in the log, a short window exists before the next checkpoint, and no independent third party co-signs our checkpoints yet. So we say "publicly anchored and tamper-evident," not "independently witnessed."

The heso backend imports only the verify surface of the cryptography. It never references sign, mint, or key-generation primitives. The cloud can verify your receipts and mirror them, but it cannot forge one. At every trust level, signing and co-signing keys are held by you and your approvers.

Operator signing and human approval are separate planes with disjoint domain tags. A signature minted for one construction is cryptographically unable to verify as another, so the two roles can never be confused or substituted.

Every record is scoped to its organisation and enforced at the database with row-level security, so one tenant's receipts are never reachable from another's session.

The cloud mirror of your receipts is database-level append-only. It is a convenience copy: the local audit trail is the source of truth and stays independently verifiable even after a cloud copy expires.

The transparency log narrows the rewrite window, but it does not close it. Once a mirrored receipt is covered by an anchored checkpoint, a replacement chain contradicts the public anchors and a verifier that requires transparency proofs rejects it. What remains exposed: receipts kept purely local and never mirrored, the interval before the next checkpoint covers a new leaf, and the absence of independent witness co-signatures on our checkpoints. That last one is the remaining roadmap item.

Approver co-signing uses a non-extractable WebCrypto key bound to the approver's authenticated session. It is not a passkey or hardware token yet, so page-level malware or a hijacked session could co-sign. Hardware approver keys are on the roadmap. Until then we say "non-extractable browser key," not "hardware-protected."

Without an RFC-3161 anchor a receipt carries no trusted time. The captured timestamp is the operator's own clock and is informational only. Even with an anchor, it bounds when the assembled action existed, never when a human decided.

heso signs captured content after the fact at the SDK seam. It is not TLS, not HTTP message signing, and it does not attest the real-world identity of an agent, person, or organisation. The signing key proves control of a key, and who that key belongs to is established out of band by your key management.

A receipt is a signing and evidence artifact, not an encryption envelope. Redaction removes sensitive fields before hashing so secrets never enter the signed bytes, but any field that is not redacted is visible to anyone holding the receipt.

These are not yet shipped, and we will not imply otherwise. "Court-grade admissibility" is likewise a legal determination involving custody, jurisdiction, and testimony, not a property we claim. What we offer is a cryptographically verifiable audit trail designed to support evidentiary use.