PRD-04 · SEC. 04 Product & Planning

Keep a Running Assumption Ledger Through Planning

Log every silent planning assumption in a ledger and force confirmation before you build on it.

FORMAT: loop
DIFFICULTY: advanced
TIME: 5 min per session, ongoing
TOOLS: universal
MODELS: any
COPIES: 0 so far

When to use this

Planning spans multiple sessions (a spec one day, tickets the next, architecture the day after), and each session quietly assumes things the last one didn't write down. Run this across the whole planning arc to catch assumptions before they calcify into decisions nobody actually made.

The pattern

Pastes as plain text

For all planning work on this project from now on, keep an assumption ledger.

Every time you make a judgment call I didn't explicitly specify (a default value, a "probably means," an inferred priority, a guessed constraint), add a row:
- Assumption: what you assumed
- Why: what forced the guess (nothing in the spec covered it, conflicting signals, etc.)
- Risk if wrong: LOW / MEDIUM / HIGH, one line on the blast radius
- Status: UNCONFIRMED

At the start of each new planning session, show me the full ledger sorted by risk (HIGH first) before doing new work. I'll mark each row CONFIRMED or FLIPPED. Anything still UNCONFIRMED after two sessions gets flagged for a decision. Block work only when the assumption is HIGH risk or the work already depends on it; ask instead.

Real example output

"LEDGER (session 3):
1. Assumption: 'monthly report' means calendar month, not billing cycle. Why: spec says 'monthly' without defining the boundary. Risk: MEDIUM (affects report date-range logic in 2 files). Status: UNCONFIRMED (2nd session flagged).
2. Assumption: bulk CSV upload caps at 500 rows. Why: no limit specified, picked a default. Risk: LOW (easy to change later, not architectural). Status: CONFIRMED (approved in session 2).

BLOCKING: item 1 is UNCONFIRMED after 2 sessions and MEDIUM risk, and report logic already partially depends on it. Stopping report date-range work until you confirm calendar month vs. billing cycle."

Why it works

Most planning drift isn't a wrong decision, it's an unmade decision that got treated as settled because nobody wrote it down. A ledger that resurfaces high-risk unconfirmed items at the start of every session turns "I assumed X" from a postmortem line into something caught while it's still cheap to fix.

Related patterns

MKT-12The Riskiest Assumption Kill LoopRank a plan's load-bearing assumptions, then loop cheapest-test-first until each is validated or killed.ENG-03Ambiguity Halt and AskMake the agent name exactly what's unclear and stop, instead of guessing silently and building on it.DBG-05Assumption Audit Before DebuggingList every assumption behind a bug theory and mark each confirmed, unconfirmed, or false.