This site is taking shape.

Enter the preview passphrase to read what is ready so far.

back to Work Receipts

How a Work Receipt works.

Someone uses an LLM to help prepare a short quarterly report and checks the figures against the supplied data. The report is correct, but the person receiving it can't see those checks in the finished file. A Work Receipt lets the producer show what was requested, what they delivered and how they checked it.

We'll use a deliberately small report, with two regions and two margin calculations, so it's easy to see the difference between a useful receipt and a thin one.

Start with the request and the report being handed over.

The request asked for one row per region, the supplied revenue and cost figures, and a margin calculated as revenue minus cost. Recording it matters because the report alone doesn't tell the next reader whether every region was required, whether the figures came from a named source, or what the calculation was meant to be.

The producer identifies the actual report file and the inputs used to make it. A receipt can record checksums for available files so another person can tell whether they have the same bytes; those checksums say nothing about whether the contents are correct.

The work named in this receipt
Request, input and output named in the example Work Receipt
Requestreport-request.md. One row for every source region, with revenue, cost and calculated margin.
Inputservice-data.csv. North: 120 revenue, 70 cost. South: 95 revenue, 60 cost.
Outputquarterly-service-report.md. The report being handed to the next person.

The useful part is what the producer checked.

Both receipts below name the same correct report. The first admits that its figures weren't compared with the source. The second shows the checks behind the producer's confirmation: every source region appears once, the figures match the input, and the margins were recalculated. A reader can examine that evidence instead of relying on a general assurance that the report was reviewed.

The same report with two different receipts
Comparison of a thin and substantial Work Receipt
Thin receiptThe report is identified, but its figures weren't compared with service-data.csv. There isn't enough here to confirm the requested calculations.
Substantial receiptNorth: 120 - 70 = 50. South: 95 - 60 = 35. The figures and regions agree with source rows 2–3; the report's table contains each region once.

Even the substantial receipt has a limit: it checks the report against the supplied data, not whether the data was collected correctly in the first place. Stating that limit is part of making a useful case.

The next person reads the case and decides.

The receipt names who prepared it and puts the request, output, inputs and checks in the order the recipient needs them. They might accept the report, ask to see the source data or repeat a calculation that matters to their decision. A receipt doesn't turn the longer record into a score or announce that the report is trusted.

If the report later becomes input to a presentation, the presentation's producer can attach its receipt and say which earlier checks they relied on or performed again. They also have to make a new case for the claims and changes introduced by the presentation; an earlier receipt cannot do that job for them.

This can all begin by hand. Deterministic checks or AI assistance may help collect evidence, but they aren't required to make or read a Work Receipt.