hypothesis-discipline

Hypothesis Discipline

Core Principle

A hypothesis is not a guess. A hypothesis selected for validation needs a clear decision, evidence criteria, and a stopping condition.

Hypothesis Characteristics

• Hypotheses exist at every level of the OST hierarchy (see product-principles skill)
• Each hypothesis has a target level attribute indicating which OST level it addresses
• Hypotheses follow an ADR-style lifecycle — a single file tracks the full journey from draft to conclusion
• Preserve rejected and invalidated hypotheses as learning assets

Hypothesis Lifecycle

draft → testing → validated → adopted
                            → rejected (validated but not adopted)
              → invalidated (disproven by evidence)
              → inconclusive (evidence gathered but insufficient to confirm or deny)
              → timeout (deadline passed, decision needed: continue or stop)

Hypothesis File Schema

The authoritative schema is defined in references/hypothesis-template.md. Key fields:

• id: HYPO-NNN
• level: outcome / opportunity / solution / assumption
• status: draft / testing / validated / invalidated / inconclusive / adopted / rejected / timeout
• confidence: scores for the risk dimensions that can change the hypothesis decision, on the product-principles 0-10 scale
• time-budget and deadline: include when time or calendar limits affect the validation decision

Validation Criteria Requirements

A hypothesis entering validation defines:

1. We believe that — the hypothesis statement
2. We'll know we're right when — measurable success criteria
3. We'll know we're wrong when — measurable failure criteria
4. Validation method — how we will test (prototype, data analysis, interview, code spike, market research)
5. Stopping condition — the evidence, time limit, or cost limit that ends this validation

Time Budget and Cutoff

• Give a validation a time budget when exploration or evidence collection can expand
• Add a deadline when a calendar cutoff changes the decision
• When deadline passes without conclusion → status becomes timeout
• Timeout forces a decision: extend (with justification), pivot, or abandon
• End validation at its evidence, time, or cost boundary