Watermelon status
You're in the delivery studio. What you're doing this lesson: compute project status from what actually passed the checks — not from "how do we feel." Green on the slide and red underneath is the watermelon. You do not need the earlier delivery lessons to start.
Every PM knows the watermelon: green on the outside, red on the inside. A workstream reports green for six weeks, then goes red the Thursday before the milestone, and everyone in the steering committee performs surprise. The watermelon was never a data problem — the truth existed — it was a sourcing problem. Status was collected by asking people, and people report hope. "90% done" has meant "I haven't started the hard part" since the first Gantt chart dried.
AI builders make this worse in a way that's easy to miss. With a human team, at least someone had ground contact — the developer knew, even if the report softened it on the way up. When an AI built the thing overnight, nobody in your standup has ground contact. The builder's own report is generated text: fluent, confident, and capable of going quiet about the check that failed and padding the report with green it wasn't asked for. Asking an AI builder "how's it going?" and typing the answer into a status field is laundering autocomplete into a steering-committee slide.
Status from the checks, not from the room
Here's the good news: if you already wrote acceptance checks (the "done" tests from the last lesson), the honest status source already exists. Every deliverable now carries a record — which checks passed, which failed, which were never run, how many attempts it's taken. If you skipped that lesson: an acceptance record is a list of named checks with pass / fail / not-run. That record has a property no verbal update has: it can't be optimistic. A check either has a pass recorded by something that ran it, or it doesn't. There is no "basically passing."
So this lesson inverts the status meeting. Instead of collecting status (asking people and models how they feel about the work), you derive it (computing task, workstream, and project RAG — red / amber / green — from the acceptance records). The rules are small enough to say out loud:
- A task is green when its deliverable was accepted. Not "demoed well." Accepted, at the gate, on the record.
- A task not yet accepted goes amber the first time it bounces, red when it's overdue or on its second bounce — because a second bounce usually means the spec, the frontier, or a dependency. A PM problem, wearing a task's clothes.
- A workstream is exactly as healthy as its sickest task. A project, as its sickest workstream. Worst-of, all the way up. Averaging is how watermelons are made: four greens and a red average to "pretty green," and the red is the one holding the launch.
Derived status has one more property worth the price of this whole chapter: it's arguable. When the roll-up says red, anyone can trace it — this workstream, this task, this failing check on this attempt. The conversation stops being "are we really red?" and becomes "what do we do about C1?" That's the meeting you actually wanted to run.