Product

The toolchain premortem

A premortem is written before the thing fails, not after. You imagine it is some date in the future, the project has failed, and you write the headlines. Then you rank the reasons and work backward to the fixes.

Run afterwards, it is not a premortem. It is a postmortem with the dates changed, and it will quietly find the reasons you already know about.

Not written yet, waiting on P-4, P-5, P-6, P-7, P-8

A premortem needs a scope to fail. There is no spec or shipped code for fieldpack, runlog, evalset, fixturegen or skilldiff, so there is nothing concrete enough to imagine failing. The exercise needs the toolchain to be defined first, not the other way round.

Checked 2026-09-21.

The second blocker

The Premortem app that is supposed to produce this is built but not live, so it is not linked from this desk. It runs the exercise properly: a named project, a date to look back from, a timed five-minute window, and then a ranking by likelihood and impact so the output is a list rather than a wall of worry.

Running the exercise in a text file instead would work. Running it in a text file and then claiming it was the product's own output would not, so I will wait.

What it will look like when it is written

The memo shape the app produces:

And then, months later, the part that makes it worth anything: going back and marking which ones actually happened. That is what turns a premortem from a ritual into a calibration score.

The date to look back from

T-5 recorded

2026-10-11, wave 2 starts, gated on Bryan's sign-off on company/product-facts.md.

Source: Bryan, product-facts kickoff request, 2026-09-21. Last verified 2026-09-21.

That is the obvious horizon. If wave 2 has not started by then, or started and went badly, the reasons will be on this page already or they will not be, and that is the test.