/assumption-classification

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`.