The six-section anatomy: the one shape a finished deployment may take

A deployment that ran for five months and one that ran for five weeks look almost identical by the time anyone writes them up. Memory rounds the edges: the fortnight when the data turned out to be wrong becomes "we hardened the data layer"; the feature nobody opened becomes "early adoption". The six-section anatomy exists to stop the rounding. It is not a template for telling a story about a project — it is the written form of the project, laid out so that certain lies cannot be told politely.

Everything except the shape is negotiable: length, tone, how many raw quotes you include. The six sections and their sequence are not. ① What they thought they were buying, and what the company actually earns money from. ② Where the money leaks. ③ The three maps. ④ Where our judgement was wrong. ⑤ What lived. ⑥ What died, and why.

The order is the method

Six verbs, one per section: write, measure, draw, lock, verify, admit.

The first section is written before the numbers arrive, because the gap between the stated purchase and the real profit source comes out of reconnaissance, not out of a spreadsheet. The second is measured into one of four bins, each carrying its own data source. The third is drawn. The fourth is locked the week it is written. The fifth is verified against a clock. The sixth is admitted.

A section written with the wrong verb in front of it is a different section wearing the same heading. "What died" narrated as a story of challenges overcome is not a weak sixth section; it is a marketing document in the sixth slot.

Why the fourth section cannot move up

"Where our judgement was wrong" sits after the money analysis on purpose. Most wrong judgements are wrong about money — the team you assumed controlled the budget, the leak you assumed was waiting, the role you assumed would absorb the change — and none of them can be stated until section two has put numbers on the table. Written before it, the same section collapses into process self-criticism: we underestimated the timeline, we should have communicated better. Written after it, it has an object, and its third line — the week and the signal — becomes the only part another team can reuse. Signals travel; conclusions do not.

The first of those three lines is locked the week it is written and only ever appended to, which is why a case cannot be reconstructed from memory at the end. If the five stages had to be compressed for a safety or public-interest emergency, the compression record belongs in this section too: exceptions are recorded where judgements are examined, not in a footnote.

The skeleton

Each slot below is the field, followed by the one thing that decides whether the slot is finished.

1. What they thought they were buying, and what actually earns the money. Two one-line statements — the client's stated reason for the project, and the real source of profit — then 300 to 800 words on the difference and how you found it. Finished when the real source fits in one line; if it does not, reconnaissance is not over.
2. Where the money leaks. Sort every leak into waiting (timestamp A to timestamp B, median), duplicate entry (N systems, roughly N records a day), shadow systems (the spreadsheets, group chats and ledgers, by name), or unowned rework (labour share plus the estimation method). Finished when every line carries a number somebody else could re-measure.
3. The three maps. Money (budget line, who approves, the cap, the over-cap route), power (the official reporting line, the person who actually decides, and on what grounds), and who loses (role, hours a week, whether it goes to zero, what else that role does, risk level, response). This is the same three maps built during reconnaissance, now checked against what actually happened. Finished when at least one named role is on the losing list.
4. Where our judgement was wrong. Three lines: the judgement held in week one, what was actually true, the week and the signal that revealed it. Finished when the third line names a week and a specific signal, and the first line is still the one you wrote in week one.
5. What lived. Only functions still in use for four consecutive weeks after go-live, each with its role, its frequency and its evidence. The four-week rule does the sorting; anything above a 30% stop-use rate goes to the next section instead. Finished when no entry reads "users report positive feedback".
6. What died, and why. For each death: what it was, its cause, what happened, what you would do differently. The causes are a closed list — the need did not hold; the wrong person was in the room; the workflow change cost more than it returned; the data source was unstable; the only champion left; we did not keep up. Finished when every entry has a cause, or states plainly how it differs from all six.

What a case with no sixth section looks like

A blank sixth section, or one that says "none", is not a case. Neither is "the process went smoothly": a smooth process is not evidence that nothing died, only that nobody looked.

The sixth section is the only part of a case another team can use without repeating your mistakes, and the six causes indexed across a hundred deployments are the asset. A case reporting no deaths adds nothing to that index and tells the reader, quietly, that the writer was never close enough to the work to see what failed.

A case pool full of deathless cases is a brochure with a bibliography.

A case is finished when four things hold: all six sections exist; the sixth names a cause or its difference; every surviving item names a role and a frequency; and the fourth section's third line names a week and a signal. Anything less is a project report with better headings.