Backcast: make the plan fail on paper first

A plan written by the agent that will execute it inherits every one of that agent's blind spots. This sequence borrows a different pair of eyes at each stage: a failure analyst, a sceptic, a rebuilder, a competitor. A worked example on an invented plan is in references/worked-example.md; read it once to see the shape of each stage's result.

The one rule at every stage: no generic advice. Every claim points at a sentence, a figure, a file or a date in the plan. A finding that would be true of any startup is not a finding. If you cannot cite where in the plan the weakness lives, cut it.

Before stage 1: read the whole plan, not the summary

Read, in this order, and take notes with file paths:

1. The plan itself (directive, roadmap, strategy, brief).
2. Whatever records what actually happened recently: a handoff note, a session log, the last week of commits. Compare what is done with what the plan says is done.
3. Any measurement the plan cites: analytics, cost ledger, target lists, test results. Open the data, not the paragraph about the data.
4. The owner's task list and the other projects competing for the same person's time.
5. Config that encodes the plan's numbers (ceilings, prices, deadlines). The code is what will run; the prose is what was hoped.

A plan's premises are often stale on the day it is written. Check each against git, the live system and the data before treating it as true.

Stage 1: forensic pre-mortem

Frame: it is six months later and the plan failed badly. Seven reasons, ranked most to least likely. For each:

• Cause: the mechanism, in one or two sentences.
• How it developed: the timeline from launch to failure; what it looked like at week one, month two, month six.
• The wrong assumption: the sentence in the plan that turned out false.
• The ignored early sign: something already visible today in the files.
• Evidence: the file, figure or line that supports the conclusion.

Look especially for: the owner's throughput as the critical path; external gates (legal, a registration, a partner) placed late in the sequence; a target pool selected for a property the method cannot observe; a ceiling that contradicts a promise; alarms routed to a channel nobody reads; a measured cost that is not the binding cost; an audience that is not the buyer.

Stage 1b: score it, so the next run can be compared

Every one of the seven modes gets a likelihood L and a damage D, each 1 to 5 on the scale in references/ledger-format.md. Score the plan as found today, not as hoped. Pipe the table through <skill-dir>/scripts/score.py (JSON on stdin: {"modes":[{"name","L","D"}]}) and record two numbers: chance of landing (0 to 100%, in steps of 5) and risk load (sum of L×D). Never compute by hand; the point is that a run next week is comparable with this one. If a ledger already exists for this project, read the previous run's AFTER now: stage 3 must explain any gap.

echo '{"modes":[{"name":"owner throughput","L":4,"D":3,"L_after":2,"D_after":3}, ...]}' \
  | python3 <skill-dir>/scripts/score.py

Stage 2: likely, damaging, assumption, evidence, flaw

Five answers, each short:

1. Most likely failure: usually the one already happening.
2. Most damaging: the one whose artefacts cannot be reused afterwards.
3. Why they differ: likelihood is about what is moving; damage is about what is irreversible. Note when the likely failure delays hearing about the damaging one.
4. The load-bearing assumption the plan states as an outcome. Find the sentence. Then list the cheapest evidence that would disprove it before more money or time goes in: things obtainable inside the plan's existing permissions and budget, in weeks not months.
5. The one structural flaw, if there is one, stated plainly. A structural flaw survives every gate clearing; it is in the incentives or the method, not the execution. Say if there is none.

Stage 3: rebuild

Same objective; change strategy, sequence, timeline, budget, dependencies or execution. For every change, name the risk from stage 1 it answers. Typical moves; use only the ones the findings call for:

• Move the demand test to step 1; freeze everything downstream of it.
• Re-select the target pool for what the method can observe.
• Split a shared ceiling; match every promise to the ceiling it runs under.
• Find the second buyer whose interest aligns with the plan's readers.
• Ask the external gatekeeper one question now, the rest on a yes; write the fallback for a no today.
• Cut the owner's list to three items in one sitting, dated.
• Route alarms to a channel the owner already reads; add a dead-man's check.

End with a pre-launch checklist of five checks, each with a numeric or observable threshold for GO, ADJUST and ABANDON, plus the rule for how many ABANDON readings end the plan. Add a precondition on owner throughput.

Re-score. With the rebuild adopted and its checklist worked, give every mode an L_after and D_after and run <skill-dir>/scripts/score.py again. The difference between AFTER and BEFORE is the de-risking on paper; the next run's BEFORE against this AFTER shows whether it was worked. A rebuild that does not move the number is not a rebuild; say so and try again, or say it cannot be moved.

Write the rebuild as a DRAFT file beside the original plan, for example <plan-name>-REBUILD-DRAFT.md. It is not in force until the owner ratifies it; say so at the top of the file and in any handoff note.

Stage 4: red team

Pick the competitor with the most to gain and the most leverage over the plan's surface: often a platform the plan observes or depends on, not a like-for-like rival. Play them in first person. Before launch, launch week, immediately after: concrete moves that cost the competitor little. Use the plan's own constraints as weapons: what it may never say, whom it may never contact, what it must always disclose.

End with the weakness the owner is least likely to notice, usually two of the plan's proudest rules interacting badly. Then fold that weakness back into the rebuild draft as a numbered change and, if it needs a decision the agent cannot make, as a question for the owner or their adviser.

Stage 5: record and route

• Append one line to <project>/memory/backcast-ledger.md in the format of references/ledger-format.md: date, plan, before%, after%, both loads, acted (this BEFORE minus the previous AFTER; blank on a first run), top mode. Create the file if absent.
• If the project keeps a session log, append a dated entry: findings ranked, the assumption, the flaw, the blind spot, what was written, what was skipped.
• Point at the draft from the handoff note with the words "not ratified; the prior plan still binds".
• If a finding crosses projects (the owner's time, a shared cost, a shared gatekeeper, a shared channel), raise it wherever the owner collects cross-project issues. Do not go and edit the other project.
• Nothing in this sequence sends a message, spends money, or changes a live system. It produces files and a decision for the owner.

Stage 6: report to the owner

Open with the two numbers: before → after, chance of landing, and the risk load beside it. On a repeat run, add the third: acted, this run's BEFORE against the last run's promised AFTER, in one plain sentence ("you were promised 60, you stand at 45: the plan was not worked", or "you beat the paper"). Then four sentences, bottom line first: the most likely failure, the most damaging, the assumption to test first, and the recommendation (ratify, strike, or keep the old plan). Then the checklist table. Then the decision that is theirs. Say once that the number is a calibrated judgement, not a measurement.

Repeat runs. Run again weekly or on demand on the same plan. Nothing in the sequence is skipped on a repeat, but stage 1 may reuse modes that still hold, re-scored; a mode that has been retired is scored L=1 and named as retired so the ledger shows what was actually removed.

Hand-offs

• task-shape: once the rebuild is ratified and a run goes unattended.
• A review gate: if the rebuild adds a workflow that produces binding or customer-facing output, put a human approval step in front of it.
• log: at the end of the session, for the memory checkpoint.