tools-only Assumption Classification
Reference for: Common Ground Load when: Classifying assumptions, determining type or tier
Assumption Types
Types indicate how an assumption was derived. Types are immutable once set (audit trail).
stated
Direct user statements captured from conversation.
- Evidence: Explicit quote from user
- Confidence: High
- Markers: User said, user requested, user specified
- Example: "Use TypeScript for all new code" - user explicitly stated this
inferred
Logical conclusions derived from code patterns, configuration, or context.
- Evidence: Code analysis, config files, project structure
- Confidence: Medium-High
- Markers: Config shows, code uses, pattern observed
- Example: "Project uses ESLint with Airbnb config" - inferred from .eslintrc.js
assumed
Best-practice defaults applied without explicit confirmation.
- Evidence: Industry standards, common patterns
- Confidence: Medium
- Markers: Best practice, common convention, typically
- Example: "Tests should have >80% coverage" - assumed based on industry standard
uncertain
Gaps or ambiguities requiring clarification before proceeding.
- Evidence: None, conflicting, or incomplete
- Confidence: Low
- Markers: Unknown, unclear, conflicting signals
- Example: "Legacy browser support required?" - no browserslist found, unclear requirement
Assumption Tiers
Tiers indicate confidence level and how Claude should act on assumptions. Users can change tiers freely.
ESTABLISHED (High Confidence)
User-validated facts that can be treated as premises.
- Action: Act confidently without re-asking
- When to use:
- User explicitly validated the assumption
- Verified through direct observation
- Documented in project configuration
- Example: "TypeScript strict mode enabled" validated by user AND tsconfig.json
WORKING (Medium Confidence)
Reasonable inferences that should be used but surfaced if contradicted.
- Action: Use as basis for work, but flag if contradicted
- When to use:
- Inferred from code/config patterns
- User confirmed informally ("yeah, that's right")
- No contradicting evidence found
- Example: "No class components" - no classes found in codebase
OPEN (Low Confidence)
Unvalidated assumptions requiring user input before acting.
- Action: Ask before making decisions based on this
- When to use:
- Uncertain type assumptions
- Conflicting signals observed
- High-impact assumption without validation
- Example: "SSR required?" - could be SPA or SSR, architecture depends on answer
Tier Transitions
| From | To | Trigger |
|---|---|---|
| OPEN | WORKING | User confirms informally in conversation |
| WORKING | ESTABLISHED | User explicitly validates ("yes, that's correct") |
| ESTABLISHED | WORKING | User says "usually but..." or exception noted |
| WORKING | OPEN | Contradiction found in code/config |
| Any | Archived | Superseded by new information |
Classification Process
When identifying assumptions, follow this process:
Step 1: Identify Source
| Source | Typical Type | Typical Tier |
|---|---|---|
| User statement | stated | ESTABLISHED |
| Config file | inferred | WORKING |
| Code pattern | inferred | WORKING |
| Convention | assumed | WORKING |
| Unknown/gap | uncertain | OPEN |
Step 2: Assess Evidence Strength
| Evidence | Tier Adjustment |
|---|---|
| Explicit user confirmation | -> ESTABLISHED |
| Multiple corroborating sources | -> WORKING |
| Single source, no contradictions | -> WORKING |
| No evidence or conflicting | -> OPEN |
Step 3: Consider Impact
High-impact assumptions (architecture, security, data handling) should start at OPEN unless strongly evidenced.
Classification Examples
Architecture & Tech Stack
| Assumption | Type | Tier | Reasoning |
|---|---|---|---|
| "Uses TypeScript" | inferred | WORKING | tsconfig.json present |
| "React 18 with hooks" | inferred | WORKING | package.json shows react@18 |
| "No server-side rendering" | inferred | OPEN | High impact, needs validation |
| "Monorepo structure" | inferred | WORKING | Multiple packages/ dirs |
Coding Standards
| Assumption | Type | Tier | Reasoning |
|---|---|---|---|
| "ESLint Airbnb config" | inferred | WORKING | .eslintrc extends airbnb |
| "Prettier for formatting" | inferred | WORKING | .prettierrc present |
| "2-space indentation" | inferred | ESTABLISHED | Consistent across all files |
| "Prefer named exports" | assumed | WORKING | Convention, not enforced |
Testing
| Assumption | Type | Tier | Reasoning |
|---|---|---|---|
| "Jest for unit tests" | inferred | WORKING | jest.config.js present |
| "80% coverage target" | assumed | OPEN | No config found, assumed |
| "Integration tests required" | uncertain | OPEN | Unknown requirement |
User Preferences
| Assumption | Type | Tier | Reasoning |
|---|---|---|---|
| "Prefers verbose explanations" | stated | ESTABLISHED | User said "explain thoroughly" |
| "Wants minimal changes" | inferred | WORKING | User often requests targeted fixes |
| "Likes TypeScript annotations" | assumed | WORKING | Convention, not stated |
User-Added Assumptions
When users add new assumptions via "Other", they specify both tier and type:
Format: {assumption text} [tier] [type]
Examples:
- "Must work offline [ESTABLISHED] [stated]" - user explicitly stating a requirement
- "Prefer functional style [WORKING] [stated]" - user preference
If type not specified, default to [stated] since user is directly adding it.
If tier not specified, default to WORKING.