AI systems are very good at sounding finished.
They can explain what they planned, describe what they changed and summarise why the result should work. The language can be fluent, specific and reassuring.
None of that proves the work happened.
As AI moves from answering questions to editing files, updating systems, preparing decisions and running workflows, teams need a better standard than confidence.
AI work needs receipts.
A receipt is evidence, not bureaucracy
A receipt is a lightweight proof trail that connects a claim to something inspectable.
It does not need to be a long report. It needs to answer the questions that matter for the risk and value of the work.
For a small local edit, the receipt might be a file path, a diff and a passing check.
For an external message, it might be the approved text, destination, send timestamp and provider message identifier.
For an analysis, it might be the source set, method, important uncertainty and the decision a human still needs to make.
For an automation, it might be the trigger, inputs, run result, delivery result and recovery action.
The principle is simple:
The stronger the claim and the greater the consequence, the stronger the evidence should be.
Why confidence is not enough
A system can be wrong in several different ways while still producing a convincing answer.
It can misunderstand the request.
It can use stale or incomplete sources.
It can prepare the right action but fail to execute it.
It can execute the action in the wrong place.
It can receive a successful technical response without producing the intended human outcome.
It can omit an exception that changes the decision.
A confident summary hides those distinctions. A receipt makes them visible.
What a useful receipt contains
I use a small set of questions.
1. What was the intended outcome?
Start with the human result, not only the system instruction.
“Updated the card” is an activity. “The live task board now shows the accepted work as complete” is an outcome that can be checked.
2. What sources or inputs were used?
Name the current evidence that informed the work.
This is especially important when an AI system is summarising research, interpreting a policy, preparing a recommendation or using personal context. A receipt should make stale sources and missing inputs easier to detect.
3. What action occurred?
Separate planning, drafting and execution.
“I prepared a command” is different from “the command ran”. “I drafted an email” is different from “the email was sent”. “I proposed a schedule” is different from “the calendar changed”.
Those verbs carry different levels of consequence and need different proof.
4. What was verified?
Verification should inspect the result, not repeat the intention.
That might mean reading the saved file, checking the destination, running a test, opening the rendered page, comparing before and after state, or obtaining a provider receipt.
A successful process exit can be useful evidence, but it may not be enough on its own.
5. What remains uncertain or gated?
A trustworthy receipt includes the boundary.
What was not checked? What assumption remains? What needs human approval? What could not be reached? What will not happen automatically?
This is not weakness. It prevents a partial result from being mistaken for completion.
Receipts improve design, not just audit
Receipts are often treated as compliance artefacts created after the work.
They are more useful when they shape the workflow before it is built.
If a team cannot say what would prove the outcome, it may not yet understand the outcome clearly enough.
Designing the receipt exposes missing ownership, vague success criteria, weak source contracts and hidden handoffs. It forces the team to distinguish technical completion from customer or operational value.
That makes the workflow easier to test and easier to improve.
Keep proof proportionate
Not every action needs the same level of evidence.
A reversible formatting change may need only a diff and a quick visual check.
A customer-facing message needs approval, destination and send proof.
A change to access, money, legal position, health information or public visibility needs a much stronger control path.
The goal is not to document everything.
The goal is to make the important claims inspectable without creating more process than the work deserves.
A simple completion line
For many AI-supported tasks, one compact completion line is enough:
- Outcome: what changed for the person or system
- Proof: what was inspected or tested
- Boundary: what remains unknown or out of scope
- Gate: what still requires human approval
That is a small habit, but it changes the quality of the relationship between people and AI.
Confidence asks the user to trust the system's account of itself.
A receipt gives the user something they can verify.
As AI systems take on more work, that difference becomes foundational.