Assumption map

Assumption Map

Surface hidden assumptions behind a plan, feature, or decision. Rank them by risk (probability × impact if wrong), then propose the cheapest experiment that would credibly validate each.

Usage

/assumption-map "<feature or decision to analyze>"   # map assumptions for a specific thing
/assumption-map                                       # map assumptions behind the current task context
/assumption-map --technical                           # focus on technical/architecture assumptions only
/assumption-map --product                             # focus on user/market/business assumptions only

Behavior

Step 1 — Establish the subject

If $ARGUMENTS is provided, use it as the subject. Otherwise, ask:

What are we mapping assumptions for? (feature, technical decision, architecture choice, or product bet)

Step 2 — Extract assumptions by category

Generate assumptions across these four layers, using the subject as context:

Desirability assumptions (do users want this?)

• Users have the problem we think they have
• Users will change their current behavior to use this
• The UX we plan is how users expect to solve it
• The benefit is compelling enough to overcome switching cost

Feasibility assumptions (can we build it?)

• The technology stack can support this without major re-architecture
• The performance characteristics will meet requirements at scale
• The required third-party APIs / data sources are accessible and reliable
• The team has the skills to deliver this in the timeframe

Viability assumptions (is it sustainable?)

• The economics work (build + operate cost < value generated)
• We can acquire users at acceptable cost
• No regulatory or compliance blocker

Technical / architecture assumptions (for code/design decisions)

• The abstraction will hold as requirements evolve
• The chosen library / framework will remain maintained
• The data model is flexible enough for anticipated variation
• Performance under load will match our estimates

Step 3 — Rate each assumption

For each assumption, assign:

• Confidence (how sure are you this is true?): High / Medium / Low
• Impact if wrong (what breaks?): Catastrophic / Major / Minor
• Risk tier = Confidence × Impact:

	High confidence	Medium confidence	Low confidence
Catastrophic if wrong	Monitor	Validate soon	Validate now
Major if wrong	Monitor	Validate soon	Validate soon
Minor if wrong	Accept	Accept	Monitor

Step 4 — Propose validation experiments

For each "Validate now" or "Validate soon" assumption, propose the cheapest credible test:

Assumption	Cheapest test	Cost	Time	What counts as validated
Users have this problem	5 user interviews asking about current behavior	~2h	1 week	4/5 describe the problem unprompted
API supports feature X	Write a proof-of-concept calling the API	~4h	1 day	Call succeeds with real data
Performance at scale	Load test with realistic data volume	~1 day	1 week	p95 latency < 500ms at 10× expected load
Abstraction holds	Implement two concrete cases against the interface	~1 day	3 days	No leaky abstraction required

Step 5 — Output the assumption map

ASSUMPTION MAP — <subject>

VALIDATE NOW (highest risk)
  [1] Users will abandon their spreadsheet workflow for this tool
      Confidence: Low | Impact if wrong: Catastrophic
      Test: Interview 5 current spreadsheet users — ask about switching triggers
      Validated when: 3/5 name a specific pain point our tool eliminates

  [2] The vector database can handle 10M embeddings at p95 < 100ms
      Confidence: Low | Impact if wrong: Catastrophic
      Test: Benchmark with synthetic 10M-record dataset (1 day spike)
      Validated when: Benchmark confirms p95 < 100ms

VALIDATE SOON
  [3] SendGrid API supports batch sends > 10k recipients per call
      Confidence: Medium | Impact if wrong: Major
      Test: Read SendGrid docs / call with test batch
      Validated when: Confirmed in API docs or test succeeds

  [4] The chosen data model handles multi-tenancy without schema changes
      Confidence: Medium | Impact if wrong: Major
      Test: Model two tenants with different configs against the schema
      Validated when: Both cases work without adding columns

MONITOR (low risk — check at next milestone)
  [5] The team can deliver this in 6 weeks
      Confidence: High | Impact if wrong: Major

ACCEPT (low risk — not worth testing)
  [6] Markdown rendering will work in the UI
      Confidence: High | Impact if wrong: Minor

Edge Cases

• Too many assumptions: Focus the map on assumptions that affect the go/no-go decision in the next sprint or milestone. Defer long-horizon assumptions.
• Technical decision only: Use the Technical/Architecture layer only; skip Desirability and Viability.
• Already in progress: Flag assumptions that were never validated but have already been acted upon — these are the riskiest.

Token Optimization

Expected range: 300–900 tokens

Patterns used: Progressive disclosure (map first, experiments on request), early exit (if subject is clear from context, skip asking)

No caching needed: Each assumption map is context-specific and not reusable across sessions.