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. The number alone tells you nothing about which definition was used, what ran, or how the result can be checked. Open the receipt below to see the difference supporting evidence makes.

The problem appears when someone challenges the figure. A plausible explanation does not establish the definition, source or calculation. The reader needs a record they can inspect independently of the model’s account of its own work.

That record is the receipt: structured evidence connecting an answer to its definition, execution and result.

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 identifies the definition used without proving that the definition is correct.

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.

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. The existence of a receipt alone does not establish bit-for-bit replay.

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.