Every AI Answer Should Come With a Receipt

The Same Number, Twice

Two AI systems answer the same question. What was net revenue retention last quarter? Both return 118 percent. One of those answers is trustworthy and one is not, and from the number itself you cannot tell which. The digits are identical. The confidence in the prose is identical. What differs is everything you cannot see: whether an approved definition of the metric was used, what actually executed, which exact result was produced, and how far any of that can be proven.

This is the uncomfortable part of putting AI in front of finance, risk and data teams. The failure mode is not a system that is obviously broken. It is a system that is fluently, confidently, unaccountably plausible. It produces a number, wraps it in a paragraph that sounds like reasoning, and offers no way to check any of it. When the number is later challenged in a board pack, an audit or a regulatory response, the honest answer to "where did this come from?" is a shrug dressed up as a citation.

A receipt is the alternative. Not a receipt in the sense of a friendly footnote the model writes about its own work, because a model narrating its confidence is exactly the thing we do not trust. A receipt in the sense a business person means it: a structured, machine-checkable record of what was bought, from whom, for how much, that a third party can verify without taking the seller's word for anything.

What a Receipt Actually Is

A receipt is a set of claims that can each be checked independently, by something other than the model that produced the answer. That last clause is the whole point. Explainable-AI marketing usually offers you the model's own account of itself, which is a story, not evidence. A real receipt is verified by machinery the model does not control and cannot talk its way past.

Useful receipts answer four distinct questions. Which approved meaning was selected? What actually executed, and where? Which exact result was produced? Where does the proof stop?

It helps to keep them distinct because they fail in different ways and are proven by different means. The first three are things you can build. The fourth is the one most vendors omit, and it is the one that tells you whether the first three are being described accurately.

Product Identity: Which Approved Meaning Was Used

Before you ask what ran, ask what it was supposed to mean. In MLX, a Twin query does not answer from whatever definition the model improvises. It answers from a published product, and the query helper produces a structured product citation as proof of that.

The mechanism is deliberately unforgiving. The helper requires a successful catalog query. It selects exactly one published manifest for the requested slug and version. It requires a separate, successful tool event that traces the specific published relation the manifest names. And it requires the answer's final structured marker to match that manifest's slug, version and source watermark.

Only when all of that lines up does it return a citation carrying the slug, version, published relation, source watermark, catalog relation, catalog event ID, relation event IDs and answer marker.

Read plainly, that citation proves the answer used a governed catalog and a published relation, and that the marker on the result matches the product that was supposed to serve it. It is a strong claim about provenance of meaning. It is also a bounded one. It does not prove the number is semantically correct, and it does not give you universal transaction-level lineage. It proves you drew from the approved well, not that the water is clean by some independent standard.

Execution Identity: What Ran, and Where

Product identity tells you which definition was in force. Execution identity tells you what the machine actually did with it. This is a separate evidence layer, and current MLX code implements it as an execution certificate.

The version 0 certificate binds together, for a single scoped invocation, the organisation, run, attempt, invocation ordinal, specific tool call, a hash of the SQL, the tables that were queried, the engine version, the canonicalisation version, the canonical result hash, and, where available, an observed evidence cut. Some certificates bind more: product coverage authority, governed artefact closure, or compact fact envelopes. The rows are append-only, and the certificate JSON is hash-checked when it is read, so a certificate that has been altered does not silently pass.

Note what "scoped invocation" buys you. The certificate is pinned to one attempt, one ordinal and one tool call, not to a vague session in which many things happened. When an agent runs several steps, each governed execution can carry its own certificate, at invocation cardinality, assembled and persisted by a worker collector. That lets you point at a single figure and identify which of the machine's actions produced it, rather than gesturing at a transcript.

There is an important design choice here for the agent-platform reader. Candidate Twin querying is typed and no-SQL for the caller: the agent asks a structured question and never sees or writes raw SQL. In a governed candidate run, that query can still yield a certificate draft carrying build, catalog, release and evidence-cut provenance, while the runtime keeps the raw SQL and draft internals out of the agent's result. The evidence is captured underneath the agent, not handed to it to summarise. The thing being audited does not get to write its own audit.

Result Identity: The Exact Bytes, Not a Lookalike

Now consider a subtler failure. Suppose you hash a raw result to prove it was not altered. Two runs return the same typed rows in different orders and their hashes differ. Or one serialiser emits an integer while another emits a decimal with explicit scale, and a loose comparison collapses a distinction the business may care about. Your integrity check either fires on incidental representation or quietly erases meaningful type information.

The fix is to canonicalise before you hash. The canonical result schema, version 1 in current code, represents decimals as scale-carrying strings and integers as explicit integers. It also defines dates, UTC timestamps, booleans and explicit reasons for missing values, with declared columns and stable keys, then emits deterministic JSON bytes.

This means 100 as an integer and 100.0 as a decimal are not casually conflated. Their type and scale are explicit. Rows receive a deterministic ordering rather than inheriting whatever order a database or serialiser happened to return.

This is why the result hash in the certificate is worth anything. It is the identity of a specific, unambiguous result, not a fingerprint that changes with incidental row ordering or hides distinctions between types. But keep the claim honest: the hash proves the identity and integrity of those bytes. It does not prove their business meaning is correct. A perfectly canonicalised, faithfully hashed result of a subtly wrong definition is a perfect receipt for a wrong answer. Integrity and truth are different properties, and a receipt only delivers the first.

Evidence Timing: Observed Is Not Enforced

Here is where honest boundaries often get quietly crossed. The certificate can record an observed evidence cut: what the system observed about the data around the moment of execution. It is tempting to present that as proof that the query read exactly that cut, no more and no less.

It is not. Until cut-bound reads are fully enforced, it must not be described that way. Observed timing is a witness to what was seen; enforced timing is a guarantee about what was read. Presenting the first as the second is how a governance story overstates itself.

The larger version of this honesty applies to replay. Full replay of the execution environment and retained evidence, reconstructing the exact conditions of a past run, is destination architecture. It is where the system is going, not a shipped guarantee. A receipt that implies you can already rerun history bit for bit is writing a cheque the system does not yet cash.

What the Receipt Cannot Prove

State the limits as plainly as the capabilities, because a vendor who only lists strengths is telling you where to stop reading.

A receipt does not prove semantic truth. That someone approved the definition and reviews it periodically is a human accountability claim, not something a hash or certificate establishes. Runtime correctness is conditional: it assumes the planner, executor and engine are themselves correct, and the receipt inherits their faults.

Aggregate-to-source-row drill-down exists only where a source reference or explicit lineage mapping was preserved, not everywhere by default. Product approval and certificate hashing are also different mechanisms, and neither should be presented as a cryptographic signature by a named person.

None of this weakens the receipt. It is what makes it credible. A boundary you can see is a boundary someone thought about.

A Checklist to Take to Any Vendor

Ask these questions and listen for whether the answer names a boundary or dodges one.

• Which approved definition did this answer use, and can you show me the published product, its version and the relation it resolved to?
• What exactly executed: which tables, which engine version, and can you tie it to one scoped invocation rather than a whole session?
• Is the result canonicalised before hashing, with type, scale, missing values and ordering made explicit?
• Is your evidence of timing observed or enforced, and are you claiming the query read exactly a given cut?
• For this metric, can you drill from the aggregate to the source rows, and if not, where does the lineage stop?
• What here is shipped in the code today, and what is destination architecture that has not yet been deployed?

The last question is the tell. A system worth trusting can answer it without flinching, because it already knows where its own proof ends.

Where Proof Stops

The instinct is to sell certainty: this number is correct, trust the machine. That is the claim you cannot actually back, and finance, risk and data professionals can smell it. The stronger position, and the harder one to build, is a precise account of exactly how far the proof reaches and exactly where it stops.

Which approved product. Which scoped execution. Which canonical bytes. And then, plainly: here the receipt ends, and beyond this line you are relying on human approval, periodic review and the correctness of the engine underneath.

Two systems can return 118 percent. Only one of them can hand you the receipt and, just as importantly, tell you where the receipt runs out. That second sentence is not a weakness in the pitch. It is the whole product.

---

Previous: One Twin, Many Interfaces. How different callers reach the same governed product and evidence contract.

Next: A Connector Is Not Context. Why access to source evidence is necessary but cannot establish approved business meaning.

Related: Letting an LLM Write SQL Against Your Warehouse Safely. The safety story before execution, where this article defines the evidence contract after it.