A vendor selling accountability infrastructure has an obvious temptation: describe cryptography as though it settles questions it cannot reach. It is an easy sale and it collapses the first time a competent auditor or a motivated opposing counsel reads the fine print.
So this page is deliberately unflattering. If you are evaluating AskLedger, read it before the marketing pages, and hold the rest of the site to it. If anything elsewhere on askledger.org contradicts this page, this page is correct and we want to know about the contradiction.
A signature proves that a specific key signed these exact bytes, and that the bytes have not changed since. It says nothing about whether the statement inside them was accurate when it was made. If a system records a credit score of 690 and the real score was 640, the receipt faithfully and permanently preserves the wrong number.
This is the single most important limit on this page. Cryptography moves the question from "has this record been altered?" to "was this record honest when created?" It does not answer the second question. Nothing cryptographic can.
The signing key belongs to whoever runs the system, usually you. A party holding the key can sign any statement it likes, and can re-sign an entire chain from scratch. A hash chain makes a single alteration or a missing link obvious. It does not, on its own, stop wholesale rewriting by the keyholder.
Detecting that requires publishing periodic Merkle roots somewhere the keyholder does not control. The Merkle primitives and RFC 3161 timestamping ship today. The connector to an external transparency log does not, so we do not claim the property it would give us. Until you publish roots externally, treat the chain as tamper-evident against a third party, not against the keyholder.
By default a receipt records a hash of the input and output, not the content. That is a privacy feature and it is why no confidential data needs to leave your environment. It also means a receipt alone cannot show anyone what was actually said. A hash proves a document matches; it cannot reproduce the document.
To answer "what exactly did the model output?", you need the receipt and the retained content it hashes, in a store you control. If that content is gone, the receipt proves only that something with that hash existed.
The short version: a receipt is strong evidence about a record, not a guarantee about the world. We hold that line deliberately, including where it costs us a stronger-sounding claim.
These are real gaps in the product today, not hypotheticals. We would rather you learn them here than discover them during diligence.
Merkle commitment and RFC 3161 timestamping ship in the SDK. A connector that publishes roots to a log outside your environment, such as a Rekor-pattern transparency log, does not. Until it does, wholesale re-signing by the keyholder is not detectable. This is the most significant open item and it is why assumption 2 above is worded the way it is.
Canonicalization under RFC 8785 and SHA-256 hashing are cross-verified across all five language SDKs by shared conformance vectors. Signed-receipt and chained vectors are not frozen yet, so we do not claim that a receipt signed in one language has been proven to verify in another. Each non-TypeScript SDK currently round-trips against its own verifier.
The drop-in adapters wrap LLM and agent-framework calls. A classic credit scorecard or fraud engine is not captured automatically; you record those decisions explicitly at the point of decision. That is a small amount of code, not an integration project, but it is not zero-touch, and any claim that implies otherwise is wrong.
Chain height continuity lets you detect that a receipt is missing. It cannot force one to exist. If a process dies between the AI call and receipt persistence, you get a detectable gap rather than a silent hole, which is better than a log, but it is not proof that every decision produced a receipt.
No external cryptographic audit, penetration test, or SOC 2 report exists yet. The threat model, hardening checklist and control framework are public so you can review them yourself, and 63 of 66 hardening controls are machine-checked, but that checker verifies that a control is documented rather than exercising it. Treat all of it as our own assessment until a third party has looked.
Our mappings to the EU AI Act, RBI, CBUAE, SAMA, ISO/IEC 42001, NIST AI RMF and others are written by AskLedger from each regulator's published text. No regulator or standards body has reviewed, approved, or endorsed them. A citation records which article a receipt carries evidence for. It is not a compliance determination.
If you find a claim anywhere on this site or in the SDK that this page does not support, that is a bug and we want the report. The code, the threat model and the hardening checklist are public so you can check rather than trust.