The one-page readout

A readout is not a status update and not a demo. It is the meeting where a decision is made: continue, narrow, or stop. Everything on the page exists to make that decision easy for a person who has ten minutes and no interest in your architecture.

The six blocks

1. The claim, in one sentence. What we said we would find out, in the customer's words. Whether invoice matching can run without a human reading the attachment.

2. The baseline. The number as it was before anything was built, with the date it was measured. A claim without a baseline is a preference.

3. What we changed. Two or three lines, plain language, no component names. We now read the attachment automatically and flag the 12% that the model is unsure about; a person checks those.

4. The evidence. One table, at most five rows: metric, baseline, now, window, source. Include the metric that did not move. The row that did not move is the most credible thing on the page, because it proves you were not selecting.

5. What did not work, and what we do not know. Three lines minimum. This is the block that determines whether the audience trusts blocks 1–4, and the block most often cut for time.

6. The decision, with options. Not "shall we continue". Three options with costs: continue at this scope for four more weeks; narrow to the disputed subset and stop after two; stop and hand over the analysis. Each option names who bears what.

A filled example

Block	Content
Claim	Whether invoice matching can run without a person reading the attachment
Baseline	4.1 min median per invoice, 400/day, measured 2026-09-14, source: AP team's own log
Change	Attachments read automatically; the 12% below confidence go to a human queue
Evidence	Median 1.9 min (n=2,080, 4 weeks); auto-clear rate 68%; dispute rate unchanged at 0.4%
Did not work	Supplier-name matching still fails on 3 legacy spellings; the model is unreliable on scanned faxes (4% of volume)
Decision	Continue: extend to the fax subset for two weeks, owner: AP lead, review 2026-11-13

Note what the evidence block does not contain: no accuracy number for the whole pipeline, because nobody acts on that number. Every row corresponds to something a person in the room is accountable for.

Four ways the meeting fails

The demo swallows the decision. Thirty minutes of working software, four minutes left, and the decision is deferred to "next time". Fix: demo runs last, for ninety seconds, and only if someone asks.

The number has no baseline. A result without a before is a claim about effort. Fix: if you cannot reconstruct the baseline, say so and present the observation as a ratio instead — from 4.1 minutes to 1.9 on the same cases.

The unknown list is empty. An empty unknown list reads as either dishonesty or inexperience, and the audience will silently discount everything else. Fix: write three, minimum, even in a good week.

The decision has no owner or date. "Everyone agreed it went well" is how a deployment enters limbo. Fix: end with a sentence containing a name and a date, and read it back.

Who should be in the room

The sponsor for the decision, the process owner for the objection, and — if the deployment's next phase depends on adoption — one operator. Not the whole team. An audience over six people converts a decision meeting into a presentation, and presentations do not decide.

What happens to the page afterwards

It is not a one-off. Three of its blocks become the first three rows of the next readout, so the measurement is continuous rather than reconstructed. The "did not work" block is the seed of the post-deployment review, and the decision sentence is what the sunset clause eventually counts backwards from.

If the readout's honest conclusion is that the metric will not move, saying that is the highest-value thing this document can do. A deployment stopped in week five is a success of the method; one stopped in month nine is a failure of the people who were in the room for this meeting.