Uncertainty Reduction

trending_down Core principle · Guideline

Every transition between lifecycle steps must reduce uncertainty by a named, recorded amount.

The framework's purpose is not to ship code — it is to reach the moment when shipping is the least uncertain remaining option.

The Rule

Plans that do not reduce uncertainty are blocked at their gate. Without this rule, the lifecycle decays into a build pipeline that ships features regardless of whether the team actually understands the problem.

1. At every step, name the uncertainty you intend to reduce before you start work
2. At every gate, record what was actually reduced in the plan's evidence: block
3. Gatekeeper subagents block transitions where the recorded reduction is empty, generic, or only restates the plan's Goal
4. Backward jumps are not failures — they are the system working as intended when uncertainty increases

Four Types of Uncertainty

Each lives in a specific artifact and is reduced by a specific activity

Type	Where it lives	How it gets reduced
About the problem	Problem Statement	Reading, interviews, observing existing users
About the approach	Hypotheses	Prototypes, benchmarks, side-by-side comparisons
About what could go wrong	Risks	Cheap failure-mode tests, counter-evidence search
About the implementation	EXP plan + PRD	Acceptance criteria, validation runs

Per-Step Contract

A step that "completes" without reducing its assigned uncertainty is incomplete

Step	Must reduce	Recorded in
Context	What the problem is & who has it	Problem Statement, Hypotheses, Risks, evidence block
Exploration-A	Whether the problem framing is right	Updated Hypotheses (confirmed / killed), insights.md
Exploration-B	Which solution is best	Side-by-side prototype, ADR, insights.md, Challenger
Production	Whether the solution actually ships & behaves	Validation results, updated insights.md, regression checks

The Evidence Block

The operational form of this rule

evidence:
  hypothesis: "We believed users would prefer X over Y because Z"
  result:     "Side-by-side prototype with 5 users — 4/5 preferred Y, citing Z'"
  reasoning:  "Hypothesis refuted; switching to Y. Insights file logged. Proceeding with Y."
      

The block is not a summary — it is an uncertainty ledger entry. Three things must be true:

1. hypothesis names a belief the team could have been wrong about
2. result is something observable, not an opinion
3. reasoning is the bridge from result to action — proceed, fall back, or kill

A block where hypothesis is "we want to add feature X" fails because wanting to add a feature is not a hypothesis. A block where result is "the team agreed" fails because agreement is not an observation.

Anti-Patterns

When the rule is being violated

Anti-pattern	Why it breaks the rule
Treating Context as documentation	Documentation does not reduce uncertainty unless writing it forces the team to confront what they did not know
Skipping Exploration-A and going straight to building	The team has assumed the problem framing instead of testing it
Approving G2 with empty evidence block	Approval is no longer attached to evidence — rubber-stamp returns
Plans without Kill Criteria	No exit ramp — the team works past the point where evidence has refuted them
insights.md written after G2 approval	Story retro-fitted to the decision; no actual learning occurred
One hypothesis only in hypotheses.md	Pretending to explore but already decided
Risks all marked "low"	Either the team is in denial or has not actually thought about risks
Generic Challenger output ("schedule slip")	The Challenger has not engaged with the specific proposal

menu_book

Read the source guideline

guidelines/uncertainty-reduction.md open_in_new