Three of the four outcomes, on one delivery note
A worked example with invented claims and an invented record, showing three of the four classes the checker prints, with a plain-language gloss on each. The invented note says four things. The invented record behind the job answers each one:
"Designed the landing page hero and wrote the copy."
Matched. A receipt in the record speaks to this step, and it recomputes clean.
"Checked the price against three suppliers."
Matched. The price call is in the record, with its saved result intact.
"Sent the invoice draft to the accountant."
No receipt. Nothing in the record speaks to it. It may have happened; the record cannot show it, and the record is what you are paying against.
"Migrated the full order history."
Contradicted. A receipt speaks to this step, but its own checks fail: the saved bytes no longer match the commitment fixed when the call ran. The proof offered does not hold.
Two of the four claims are backed, one is a promise, and one is contradicted by the record itself. That is the whole decision, in one screen, before any money moves. The claims the note never made matter too: the checker also lists the steps that sit in the record but were never claimed, so work done quietly still shows up.
Run it yourself
The checker is the claims command in the free aer1-verify package (version 0.2.25 and later). It runs on your machine and recomputes every receipt it touches, the same way the single-receipt check does:
pip install aer1-verify # one claim per line: the worked example's invented claims, as a sample claims file cat > claims.txt << 'EOF' Designed the landing page hero and wrote the copy Checked the price against three suppliers Sent the invoice draft to the accountant Migrated the full order history EOF # against single receipts, by ID or /run/ link aer1-verify claims --claims claims.txt --receipt <receipt-id> # or against the whole job at once, by its workflow (handover) record aer1-verify claims --claims claims.txt --workflow <workflow-id>
Matching is mechanical and the report says so: the claim's words are matched against the receipts' tool names, job summaries, and step tools, plus any receipt ID the claim names outright. It checks coverage, not meaning, so read the four classes the way they are labeled: matched means the record backs the claim, no receipt means the record is silent, contradicted means the record refuses, and not checked means a receipt speaks to the claim but the record withholds the bytes it committed to, so the receipt cannot be recomputed and cannot back the claim. Add --json for the machine-readable report. Exit code is 0 only when every claim matched a receipt that verifies.
If there is no record to check against
Plenty of delivered work has no receipts behind it at all: the job ran in a chat window, the summary is all that exists. The checker cannot invent a record, and this page will not pretend a summary checks itself. For that job your options are the old ones: pay on trust, hold payment, or argue. What you can change is the next job. Ask for the handover link as a deliverable before work starts, or write it into the contract: the acceptance clause generator on this hub produces the clause that makes the handover the acceptance event, so the record exists by the time anyone asks to be paid.
Questions, answered
How do I check a freelancer's work before I pay them?
Split what they sent you into claims, one per line: each sentence that says something was done is a claim. Then match every claim against the record behind the work, its receipts. A claim with a receipt that recomputes is backed. A claim with no receipt is a promise. A claim whose receipt fails its own checks is contradicted by the record itself. A claim is not checked when a receipt speaks to it but the record withholds the bytes it committed to, so the receipt cannot be recomputed and cannot back the claim. The free checker on this page does the matching for you: aer1-verify claims reads your claims file and the receipts and prints a class for every claim, plus the steps that sit in the record but were never claimed.
What do I need from the freelancer to run the check?
The receipt IDs (or the /run/ links) for the job, or the handover link, whose step record carries every step's receipt ID. If the work ran on Zambo, every call already has one. Ask for the handover link before you pay, the same way you would ask for the files. If no record exists for the job, there is nothing to check against, and that is the answer for this job: pay on trust, or do not, with your eyes open. For the next job, put the record in the contract first; the acceptance clause generator on this hub writes that clause.
What does a contradicted claim mean?
The record speaks to the claim, but the receipt behind it does not recompute: the saved bytes no longer match the commitment fixed when the call ran. The record itself refuses to back the claim. That is different from a missing receipt. Missing means unproven; contradicted means the proof offered does not hold.
What does a matched claim prove?
That the saved result behind that step was not changed after it was saved, checked on your machine, not on the seller's page. It does not prove the work is good. Judgment stays yours. What the check removes is the factual fog: which steps are backed by a record, which are promises, which are contradicted, and which cannot be checked because the record withholds its bytes, before money moves.
What does the checker cost?
Nothing. aer1-verify is a free package (pip install aer1-verify), checking is free, and zambo.dev/verify is free with no account. The layer that costs money is creating work at volume: the free tier on Zambo is 20 calls + 1 wrap-up free every day, a Day Pass is $0.99 one time for 24 hours, the Zambo Pass is $29 for 30 days ($19 for $ZAMBO holders), and a Lifetime Pass is $250, one payment. Verification stays free on every tier, so the person checking never needs the plan the person working used.