A thin library sits between your app and the AI vendor. It captures each call, signs it with established cryptography in under a millisecond of CPU, and emits a receipt to your own store off the request path, so the AI response is never blocked and your application code is unchanged.
Wrap the client once; every call is captured, signed, and written where you choose. The signing key never leaves your HSM, and no data is routed to a third party.
The value is in the two moments coming apart. The receipt is created the instant the AI decides. It is checked later, by someone who was not there and does not trust you, using nothing but a public key and the math.
The receipt is the foundation. One layer sits before it, stopping an irreversible action until an independent reviewer clears it, and two sit on top: bundling a whole workflow into one verifiable artifact, and checking the decision against the rules it was meant to follow. These are the same four layers described in the architecture section below, with the same numbering.
Where each layer actually stands: all four ship in the open SDK today and are exported from its public API, and one runnable example walks a single action through every one of them. Layer 2 is the most hardened and the most used, and it is what the public verifier checks. Layers 1, 3 and 4 are newer and are being exercised with early users, so treat them as production-ready code with less mileage than Layer 2, not as roadmap. Two honest limits: AskLedger records and carries correctness evidence, it does not itself perform formal verification, and Layer 4's rule check is a bounded comparison of recorded values against recorded rules, which is not a mathematical proof and is labelled as a rule check in the receipt.
An independent verifier ships in every SDK. No new cryptography: every guarantee rests on published, reviewed RFCs. What those guarantees cover is integrity and authorship since signing, not whether the decision itself was right.
RFC 8785 gives every receipt one deterministic byte representation. The SHA-256 of those bytes is the receipt_hash. Every SDK produces the same canonical bytes and the same SHA-256 for the same input, which is exactly what our shared cross-language conformance vectors cover. Signed-receipt vectors are not frozen yet, so cross-language signature checking is not something we claim as proven.
Each receipt's previous_receipt_hash binds it to the one before. Alter any historical receipt and every later verification fails. Truncating the chain is a different attack: detecting it requires publishing periodic Merkle roots somewhere outside the environment that issues the receipts. The Merkle primitives and RFC 3161 timestamping ship today; the connector to an external transparency log does not, so until you publish roots externally the chain is tamper-evident against a third party but not against whoever holds the signing key.
Ed25519 over the canonical bytes, with the private key held in AWS KMS, Azure Key Vault, GCP KMS, or a PKCS#11 HSM so signing happens without the key being exported. Check Ed25519 availability for your provider, region and tier before you design around it, since support varies. Optional RFC 3161 timestamps anchor each signature to absolute time, which is what lets a signature survive a later key compromise.
Four technical layers are the proof engine. They prevent the wrong action and prove what happened, how, and why, every one cryptographically verifiable and each optional. A fifth layer is the program built around that engine. It turns the proof into governance, compliance, and business impact you can put in front of a board, with one rule that keeps it honest: every number is proven against signed evidence, never just claimed.
Prevents the wrong action. Before an irreversible step, an independent reviewer signs a verdict bound to that exact action. Approving one thing and running another is rejected, high-risk actions can require several reviewers, and the verdict itself is recorded.
Proves what happened. A signed, tamper-evident receipt for every AI action, linked into a per-tenant hash chain. Verify a single receipt, or an entire ledger, with a public key alone.
Proves how the process ran. Multi-step agent runs leave a linked graph of receipts that can be deterministically reconstructed and verified end to end, so a dropped or reordered step is caught.
Proves why the decision was sound. The governing policy is recorded and checked against the decision, and every receipt carries an assurance level from Declared to Anchored, so a verifier knows exactly how strong the evidence is.
Helps you adopt, govern and scale it, and measure business value against signed evidence. The four technical layers make every action verifiable. Layer 5 turns that into an operating model: an institutional governance framework, pre-built rule packs mapped to the frameworks your regulators enforce, guided enablement, and business impact measured against a signed baseline. Said precisely, because this is where vendors usually overreach: signing a baseline and a later measurement makes those numbers tamper-evident and attributable, so nobody can quietly revise them after the fact. It does not make them true. Whether a saving was caused by the change is a judgement about your business, and we do not claim the cryptography settles it. Layer 5 is delivered as a service engagement, not a library call.
A fair comparison, because an unfair one is easy to take apart. Well-run vendor logging is better than this table used to give it credit for: on WORM storage with object lock it is not editable, and retention is a policy setting on both sides. The real difference is narrower than "mutable versus immutable", and it still matters.
Where the honest limit sits: receipts live in your store, so you can delete them too. A hash chain makes a missing link visible, but an issuer who re-signs an entire chain can only be caught if Merkle roots were published somewhere that issuer does not control. That connector is not built yet, so we do not claim the property it would give us. See what a receipt does not prove.
Wrap your AI client and ship a receipt in one import: TypeScript, Python, Go, Rust, or Java.