An AI auditor asks a simple question, and it is not the one most vendors prepare for. They do not ask whether you have a policy. They ask whether the control worked.
The difference is the whole engagement. A policy is a claim about intent. A control is an effect. Most of the evidence a company assembles for an AI audit answers the first question. Very little of it answers the second.
This post is about where a signed receipt fits, and where it does not. We sell verification, so read the limits closely. They are the useful part.
What the frameworks actually ask for
Three frameworks come up repeatedly in regulated AI conversations. They ask for different things, and one of them has a category that fits our work.
AIUC-1 is the certification scheme from the Artificial Intelligence Underwriting Company. Its evidence templates use four tags: legal policies, technical implementation, operational practices, and third-party evals (AIUC evidence registry). The certificate is valid for one year, and the agent has to be evaluated each quarter (AIUC, Q3-2026 update). The current requirement set and its changes are in the official changelog.
The category that fits is third-party evals. The evidence templates attach third-party evaluation evidence to A009.1, B001.1, C010.1, and D004.1, and ask for records of the assessor’s qualifications and independence. Whether an accredited auditor accepts a given evaluation is their decision. AIUC-1’s evidence page does not publish an acceptance policy for unaccredited third parties, and we are not one of its accredited auditors. A receipt does not make an agent AIUC-1 compliant.
ISO/IEC 42001 is the AI management-system standard. Its certification audit runs in two stages. Stage 1 reads the design: scope, policy, risk method, Statement of Applicability. Stage 2 samples the reality: control records, logs, interviews, and a traced path through the system (Teleport’s audit-evidence guide, ISMS.online’s checklist). A common finding is a control that exists on paper and has no runtime record.
NIST AI RMF is voluntary and not certifiable. MEASURE 2.3 asks for AI system performance or assurance criteria to be measured and demonstrated for conditions similar to deployment, and says the measures are documented. MANAGE 2.4 asks for mechanisms to supersede, disengage, or deactivate a system whose performance or outcomes are inconsistent with intended use (NIST AI 100-1). Both require you to show what was done, not only what you intend to do. Neither tells you what the record should contain.
That gap is where an auditor spends their time. They are not checking that a document exists. They are checking whether it describes something that actually happened.
The questions, and the receipt
A signed receipt is one narrow artifact: a claim, the ground truth it was checked against, the re-run, and a verdict. It is useful because it makes one effect checkable by someone who does not trust the company that produced it.
Here is what it can and cannot answer.
| The question an auditor asks | What a receipt can answer | What it cannot |
|---|---|---|
| Did the control work, or is it only documented? | The claim was re-run against the ground truth and signed: falsified, not_falsified, certified, or indeterminate. The record names the test and the effect. | Whether the test suite was sufficient, or the environment representative of production. |
| Are the evaluations current? | Each receipt carries an RFC 3161 timestamp from an independent time-stamping authority, bound into the signed envelope. A quarterly cadence is visible as a series of receipts. The TSA token itself is verified by our publish gate against the pinned CA, not by the browser verifier. | That every quarter was run, or that the sample covered every system in scope. |
| When the outcome was wrong, what did you do? | An indeterminate record can name the missing record and its writer. A re-run receipt links back to the one it answers with rerun_of. | That the system was actually deactivated, or that the remediation worked outside the re-run. |
| Who wrote the evidence, and could they change it? | A version 3 receipt names each writer, gives a locator or an explicit null, and records whether that writer could alter the record afterwards. | That the writer told the truth at the time of writing. |
| Was the record altered after the fact? | The content hash and the Ed25519 signature are checkable in a browser with only the public key. On a version 3 receipt, changing the timestamp breaks the signed envelope. The TSA token itself is checked by the gate, not the browser. | That the ground truth was right, or that nothing important was omitted. |
One row is worth an example. In the SymPy catch, a coding agent said it had fixed a bug. We cloned the repository, ran the test the fix was supposed to make pass, and it still failed. The claim was falsified. The receipt carries the repository, the instance, the patch, the test output, and the verdict. The content address is SHA-256 over the canonical {schema, outcome} record; the signature is Ed25519 over that address. You can open the receipt and check both yourself. What you cannot conclude from it is that our test suite was complete. It was one test, on one bug.
What a receipt is not
It is not a certification, and it does not claim completeness. We are not an accredited auditor under AIUC-1, ISO 42001, or any other scheme. A version 3 receipt carries a coverage block only when an independent authority counted the events. When there is no independent count, the field is absent and the page says not checked. A completeness number we produced ourselves would be a self-assessment.
It is not a correctness claim. A signature proves the record was not altered after signing. It proves nothing about whether the record is right. A wrong finding with a valid signature is still a wrong finding. The same rule applies to this post: a source link is not a guarantee that the source says what I think it says. Check it.
What to bring to the auditor
If you are preparing for an AI audit, the receipt is the easy part. The harder part is the discipline around it.
Write the claim down before the run. Name the ground truth and the person or system that produced it. Keep the command and the inputs, so a third party can re-derive the result. Record the writer of every piece of evidence, and whether they could change it afterwards. Publish the misses with the same detail as the passes. An auditor learns more from one honest indeterminate than from a page of clean summaries.
The auditor’s job is to disbelieve the document until the effect is shown. That is our job too. A receipt is useful because it makes one effect checkable, and because it says what it does not cover.
If you want to see the shape, start with the SymPy catch. If you want the other direction, read our independence self-assessment, which lists the criteria we fail.