Pre register

Pre-Register

A postmortem written after the outcome grades a story; one written against a pre-registered record grades the reasoning. The value is temporal: register the tree, the claims, and the triggers while the outcome is unknown, then let the world mark the homework.

When to fire

All three, or don't bother:

1. A decision is being made now and will stand (the EV math says proceed).
2. It carries a live tail — a low-probability branch that genuinely hurts.
3. Someone will plausibly ask "what went wrong?" if the tail fires.

The point is not to change the decision — mental-models owns that. The point is that rare events against you become calibration data instead of arguments.

Protocol

1. Build the tree. Every branch (MECE, probabilities sum to 1), payoff per branch, EV of the chosen arm vs the rejected one. If the EVs are within noise, say so — "this was close" is itself registrable.
2. Name the load-bearing claims. Each one falsifiable, with a condition and a date: "falsified if X by DATE". A claim no outcome can falsify is decoration — cut it or sharpen it.
3. Compute flip thresholds. For each claim, the probability at which the decision reverses ("sell wins only if p(YES) ≥ 3.2% — 3× our estimate"). These are what the postmortem checks first: was the miss inside or outside the registered sensitivity?
4. Set concrete triggers. The conditions that fire a review: any outcome outside the modal branch, or a deadline passing with no outcome (the silent branch — delays need triggers too).
5. Write the postmortem questions now, per branch. What would each failure say about the reasoning — stale data, over-trusted source, wrong reference class? Post-outcome you'll know which branch fired; pre-outcome you're honest about what it would mean.

Template

# Pre-registered: <decision> (<date>)

**Decision:** <chosen arm, size/stakes>. Rejected: <alternative + its EV>.
Approved by: <who>. This document grades the reasoning below as written.

## Context at registration
<the 3-5 facts the tree stands on, dated>

## Tree (registered <date>, before outcome)
| Branch | P | Payoff |
|---|---|---|
| <modal branch> | 0.xx | ... |
| <tail branches, MECE, sum to 1> | 0.0x | ... |

EV(chosen) vs EV(rejected): <numbers>.

## Load-bearing claims (each falsifiable)
1. <claim> — falsified if <condition> by <date>.
2. ...

## Flip thresholds
- <decision reverses if p(claim k) exceeds X — N× the registered estimate>

## Triggers and postmortem questions
**Trigger:** <any non-modal outcome>, or <no outcome by DATE>.
- If <branch A>: <what it would say about the reasoning>
- If <branch B>: ...
- Meta: trees claiming X% should fire ~X% across the accumulated sample.
  One firing is a data point, not a verdict.

Storage and triggers

• Git-backed, next to the work: docs/premortems/YYYY-MM-DD-<slug>.md in the relevant repo. Never memory-only, never chat-only — the record must survive the session that wrote it.
• Put the trigger where the operator already looks: the repo README's TODO list, the tracking ticket, or a calendar entry — one line, pointing at the registered file, stating the firing condition. A premortem nobody re-opens is a diary.

Grading (when a trigger fires)

1. Quote each registered claim verbatim; mark CONFIRMED or FALSIFIED. No paraphrasing — paraphrase is where hindsight sneaks in.
2. Check the flip thresholds: did reality land inside the registered sensitivity (bad luck) or outside it (bad model)? Only the second demands a reasoning fix.
3. Diagnose only after grading, using the branch's pre-written questions.
4. One tail firing changes nothing by itself. Policy changes when the accumulated record says the trees are miscalibrated — X% branches firing far more often than X% — across several distinct events.