assumption-grading

# Assumption Grading

## Overview
Systematically assess assumptions to identify which ones need validation and prioritize research efforts.

## When to Use
- At project start to grade initial assumptions
- During Define phase when framing the problem
- Before phase transitions to assess remaining risks
- When deciding what to research next

## How to Apply

### 1. List Assumptions
Identify what you're assuming to be true. Common sources:
- Beliefs about user behavior
- Market or business conditions
- Technical feasibility claims
- Resource availability
- Timeline estimates

### 2. Grade Each Assumption
Assess on two dimensions:

**CERTAINTY** — How confident are we this is true?
- **High**: Strong evidence, validated with users/data
- **Medium**: Some evidence, but not thoroughly validated
- **Low**: Gut feeling, no validation yet

**RISK** — What's the impact if we're wrong?
- **High**: Project fails, major wasted resources, wrong direction
- **Medium**: Significant rework needed, delays, budget impact
- **Low**: Minor adjustments, easy to correct

### 3. Prioritize Validation
Focus on assumptions that are:
1. **Low certainty + High risk** — VALIDATE IMMEDIATELY
2. **Low certainty + Medium risk** — Validate before major commitments
3. **Medium certainty + High risk** — Validate before proceeding
4. **High certainty + Low risk** — Can proceed with monitoring

### 4. Plan Validation
For each high-priority assumption, define:
- What would prove this true or false?
- What's the cheapest/fastest way to test it?
- Who can provide evidence?
- When do we need to know?

### 5. Update currentstate.json
Record each assumption with:
```json
{
  "id": "a1",
  "description": "Users want automated reporting",
  "certainty": "low",
  "risk": "high",
  "validation_plan": "Interview 5 users about reporting needs and current workflows",
  "status": "open"
}
```

## Example Assessment

**Assumption**: "Users will adopt mobile app over desktop"
- **Certainty**: Low (based on industry trends, not our users)
- **Risk**: High (entire platform strategy depends on this)
- **Priority**: VALIDATE IMMEDIATELY
- **Validation Plan**: Interview current users about device usage patterns and preferences

**Assumption**: "API can handle 1000 requests/second"
- **Certainty**: Medium (vendor specs, but not tested)
- **Risk**: High (performance is core requirement)
- **Priority**: Validate before prototyping
- **Validation Plan**: Load testing with production-like data

**Assumption**: "Users understand technical jargon"
- **Certainty**: Low (no evidence)
- **Risk**: Low (can adjust language easily)
- **Priority**: Test during iteration, easy to fix

## Tips
- Be explicit about what you're assuming
- Don't confuse hope with certainty
- High certainty still means "could be wrong"
- Update grades as you learn
- Re-grade assumptions at phase transitions