---
title: "Assumption Classification"
description: "> Reference for: Common Ground > Load when: Classifying assumptions, determining type or tier"
type: skill
canonical_url: https://claudary.paisolsolutions.com/skills/assumption-classification
source: "Claudary"
difficulty: intermediate
author: "Claude Code Knowledge Pack"
date: 2026-07-10T11:08:00.169Z
license: CC-BY-4.0
attribution: "Assumption Classification — Claudary (https://claudary.paisolsolutions.com/skills/assumption-classification)"
---

# Assumption Classification
> Reference for: Common Ground > Load when: Classifying assumptions, determining type or tier

## Overview

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

---

Source: [Claudary](https://claudary.paisolsolutions.com/skills/assumption-classification) · https://claudary.paisolsolutions.com