What an AI work audit is
The short answer
An AI work audit is a review of finished AI work run against the record the work left while it ran. The auditor takes the delivery's claims one by one, matches each to the step that supposedly produced it, recomputes that step's record, and sorts every claim into three lists: what verified, what failed, and what was never checked. It differs from reading the delivery or the agent's summary, because the record under audit was saved at execution time by the layer that ran the work, and any later edit to it shows up when the record is recomputed.
Zambo is the verifiable work layer for AI: every call run through it leaves a verifiable receipt in the AER-1 format, published as an IETF Internet-Draft (draft-zambo-aer1-25), and a finished job closes under one record that gathers its steps. That record is what makes an AI work audit possible at all. Without it, there is no audit, only an opinion about a delivery. AER-1 is an Internet-Draft, not a finalized standard.
What the audit examines
- The claims. Every assertion the delivery makes about itself: sources consulted, steps completed, checks run, files produced. The audit starts by listing them, in the delivery's own words, before judging any of them.
- The steps behind each claim. A claim with no step record under it is unverified, however polished it reads. A claim whose step record recomputes clean stands on the record, not on trust.
- The completeness of the set. The job's closing record commits to the exact ordered set of steps. Drop a step, add one, or reorder two, and the close no longer matches. This is the check that catches the quiet omission, the failed attempt edited out of the story.
- The decisions. What a person approved, what changed scope mid-job, and who accepted the finished work. An approval that happened off the record leaves nothing to audit, so the audit names it as a gap instead of assuming it.
The audit ends in three lists
A finished AI work audit is not a verdict and not a vibe. It is three lists, and the discipline is that every claim in the delivery lands on exactly one of them:
What verified
Claims whose step records exist and recompute clean: the saved result on the record matches what was saved when the call ran. These claims stand on evidence either side can re-check.
What failed
Claims whose records do not hold: a digest that no longer matches, a closing record that disagrees with its steps, a step recorded as failed or refused that the delivery describes as done. Failed does not always mean dishonest. It always means the claim cannot be taken as stated.
What was never checked
Claims with no record under them at all, and steps in the record that nobody recomputed. Naming this list out loud is the audit's main protection against its own overreach: it marks the edge of what the evidence covers, instead of letting a clean sample quietly stand in for the whole job.
The public handover records on this hub model the shape: they carry a not-checked list on their face, naming the steps no one verified, beside the steps that were. An audit that hides its third list is marketing. An audit that publishes it is evidence.
How to run an AI work audit
- Get the record link first. Before the delivery, before the walkthrough call. One link carrying the job's steps, their receipts, the sources, and the decisions. If it does not exist, stop: the finding is that the work cannot be audited, and that finding is worth having before money moves.
- Freeze the claims. Write down what the delivery asserts, in its own words, so the audit tests the claims that were actually made rather than the ones that survive questioning.
- Match claims to steps. For each claim, find the step that produced it. No matching step means the claim goes to the never-checked list, not into an argument about intentions.
- Recompute. Check steps free at zambo.dev/verify, one receipt at a time, or recompute a whole trail offline with an independent implementation of the open AER-1 draft. Then recompute the job's closing record from its steps and compare.
- Write the three lists. Verified, failed, never checked, with the step IDs beside each claim. That document is the audit. It is short, it is checkable by the other side, and it gives the payment conversation one shared record to argue from, instead of two competing memories.
The record an audit reads, counted
An audit is only as real as the record underneath it, so here is that record at production scale. Counted from Zambo's public receipt stream at 21:57 UTC on October 22, 2026, over the trailing 24 hours: 2,367 receipts, written for 543 distinct callers across 102 different tools. Of those, 249 were workflow_close calls, the operation that seals a finished job's steps under the one closing record an audit recomputes. Every receipt in that count is a public page a stranger can open and check.
The count proves the record exists at scale, nothing more. It does not prove any single job in it was done well, and this page keeps that line bright on purpose: a receipt shows the saved result was not changed since it was saved, never that the result was right. The audit's job is to turn that narrow, solid fact into a decision about a specific delivery.
Which review do you need?
AI work audit: the finished delivery, before it is accepted
The review on this page. It runs after the work, against the work's own record, and it answers the payer's question: which of these claims can I stand on? Use it before paying, before shipping a client's deliverable onward, and whenever a delivery will be relied on by someone who was not in the room.
Agentic workflow audit: the run itself, step by step
The agentic workflow audit rebuilds one multi-step run from its records: what ran inside the workflow, what each step's claims rest on, and what was decided along the way. Reach for it when the question is about a process you operate, not a delivery you received.
Deliverable sampling: the output, read closely
Auditing AI-generated work samples the deliverable itself against the record: read some of the output properly, and check that the record agrees about how it was made. It pairs with the work audit rather than replacing it: sampling judges quality, the audit judges whether the story of the work is true.
Underneath all three sits the same raw material: the activity log the work left while it ran, gathered into the audit trail a checker reads. No record, no audit. That is the whole dependency, and it is why the record has to be written by the run rather than reconstructed for the review.
Questions, answered
What is an AI work audit?
An AI work audit is a review of finished AI work run against the record the work left while it ran. The auditor takes the delivery's claims one by one, matches each to the step that supposedly produced it, recomputes that step's record, and sorts every claim into three lists: what verified, what failed, and what was never checked. It differs from reading the delivery or the agent's summary, because the record under audit was saved at execution time by the layer that ran the work, and any later edit to it shows up when the record is recomputed.
How do I audit AI work before I pay for it?
Ask for the record before you ask for anything else: one link carrying the job's steps, each with its verifiable receipt, the sources used, the decisions made, and the acceptance state. Walk the delivery's claims against that record. Recompute any step free at zambo.dev/verify, with no account. Claims with a step that verifies stand. Claims resting on a step with no record are unverified, however polished the delivery looks, and they are the ones to price, question, or refuse. If the person who did the work cannot produce a record, the audit has already found its first result.
What does an AI work audit check?
Four things. That every claimed step actually ran, shown by a record saved when it ran. That the saved results still match what was saved, shown by recomputing each step's digest. That the order and the set are complete, shown by the job's closing record matching its steps, so a dropped or added step changes the close. And that the human decisions are in the record: what was approved, what changed scope, and who accepted the finished work. What it does not check is taste. Whether the work is good is a judgment the audit informs but never makes.
What does an AI work audit not prove?
It does not prove the work was correct, wise, or worth the price. A job can be perfectly recorded and still reach a wrong answer, and the audit will faithfully show the wrong answer arriving, step by step. What the audit proves is narrower: the record is complete, the record is intact, and the claims in the delivery either match step records or are labeled unverified. That narrowness is the value. The argument stops being about whose memory is better and starts being about a record both sides can read.
What do I need from the person who did the AI work to audit it?
One thing: the record link. Not screenshots, not a transcript, not an export they assembled afterward. The link to the job's record, carrying each step's verifiable receipt, the sources, and the decisions, in the form they were saved while the work ran. With that link you can run the whole audit yourself, or hand it to someone who can. Without it, there is nothing to audit, only a delivery to believe. Work run through the Zambo MCP at https://zambo.dev/mcp leaves this record on every call, so asking for it costs the person who did the work nothing.