First Principles Thinking

A systematic approach to decomposing complex problems into irreducible truths and reasoning upward from there — avoiding the trap of reasoning by analogy, convention, or "best practice".

When to Use

• Evaluating whether an architecture, design, or strategy is truly optimal
• Questioning "best practices" that may not fit the current context
• Breaking through when conventional solutions feel inadequate
• Making foundational decisions with long-term impact
• Challenging inherited assumptions in legacy systems or legacy thinking
• Any moment where "we've always done it this way" is the primary justification

When NOT to Use

• Trivial decisions (use Occam's Razor instead — just pick the simplest)
• Time-critical emergencies (act first, analyze later)
• Well-validated problems with proven solutions (don't reinvent the wheel)
• When you lack domain expertise AND can't acquire it (first principles without knowledge = naive solutions)

Core Methodology: 6 Phases

Phase 0: Frame the Question — Establish Axioms

Before analyzing anything, define the irreducible truths that constrain this domain.

Axioms = facts that are independently verifiable, cannot be further decomposed, and violating them definitely causes failure.

How to identify axioms:

• Ask: "Can this be further decomposed?" — If yes, it's not an axiom yet.
• Ask: "Is this provably true, not just commonly believed?" — If uncertain, it's an assumption.
• Ask: "Would violating this definitely cause failure?" — If maybe, it's a preference.

Gate: Must produce ≥3 axioms before proceeding. Each axiom stated in one sentence with a "why irreducible" justification.

### Axioms
1. [Axiom] — [Why this cannot be further decomposed]
2. [Axiom] — [Why this is provably true]
3. [Axiom] — [Why violating this causes failure]

Deep methodology: references/axiom-based-reasoning.md

Phase 1: Identify the Problem's Essence

Strip away implementation details to find the core problem.

1. State the problem clearly — What exactly needs to be solved?
2. Separate symptoms from causes — Is this the real problem or a manifestation?
3. Define success criteria — What would a perfect solution achieve? (Measurable.)

Key questions:

• What is the fundamental job to be done here?
• If this system/process didn't exist, what would we actually need?
• What outcome matters, independent of how we get there?

Gate: Must produce a one-sentence problem statement + measurable success criteria.

Phase 2: Surface and Challenge All Assumptions

This is the highest-leverage phase. Most "best practices" are assumptions disguised as facts.

1. List explicit assumptions — What are we taking as given?
2. Surface implicit assumptions — What conventions are we following without questioning?
3. Test each against axioms — Is this actually a constraint (traces to axiom), or just how it's always been done?

Minimum: Produce an assumption table with ≥5 rows.

Red flags (likely false assumptions):

• "We've always done it this way"
• "Industry standard says..."
• "Everyone uses X for this"
• "That's too simple to work"

Depth standard: Each row must include why you're questioning it and which axiom informs the verdict. "Maybe not needed" without reasoning = not deep enough.

Gate: ≥5 assumptions challenged with verdicts. Each verdict must reference at least one axiom.

Deep methodology: references/axiom-based-reasoning.md § "Identify and Challenge Assumptions"

Phase 3: Establish Ground Truths

From the wreckage of challenged assumptions, identify what IS irreducibly true for this specific problem.

Ground Truth test:

• Can this be further decomposed? → If yes, decompose it.
• Is this provably true, not just commonly believed? → If unsure, it's still an assumption.
• Would violating this definitely cause failure? → If not, it's a preference.

Gate: Must produce ≥3 ground truths. Each must be specific and falsifiable — not generic truisms.

❌ "Users need fast response times" (too vague)
✅ "P99 latency must be < 200ms per SLA contract §3.2" (specific, verifiable)

❌ "The team is small" (relative)
✅ "Team is 3 engineers, no new hires possible before Q3" (concrete constraint)

Phase 4: Reason Upward

Build solutions from ground truths only. Each layer must justify its existence.

Ground Truth → Minimal Solution → Justified Additions → Final Design
     ↑              ↑                    ↑
  (proven)     (sufficient)        (each defended)

1. Start minimal — What's the simplest thing that satisfies all ground truths?
2. Add only what's necessary — Each addition must reference a ground truth or axiom.
3. Challenge each layer — Does this layer earn its complexity?

Gate: Must produce a reasoning chain where every step traces to a ground truth.

### Reasoning Chain
GT#1 (latency < 200ms) + GT#3 (3-person team) → Eliminate distributed architecture
GT#2 (read-heavy 95%) + GT#1 → Add read cache with 30s TTL
→ Conclusion: Monolith + in-memory cache

Phase 5: Validate and Stress-Test

Ensure the reasoning is sound before acting.

Three validation questions (Completion Gate):

Stress-test with complementary models:

Full model toolkit: references/thinking-models-toolkit.md

Gate: All 3 validation questions answered "yes". At least one stress-test model applied.

Reasoning Discipline Protocol

Problem: AI tends to skip steps, get distracted mid-analysis, or do each step shallowly.

Phase Gates (Mandatory Artifacts)

No artifact → no next phase. If a gate is not met, stop and complete it.

Progress Tracker (Anti-Drift)

Maintain a running checklist throughout the analysis. After each phase completion, output:

## 🧭 FP Progress
- [x] Phase 0: Frame — ✅ 3 axioms
- [x] Phase 1: Essence — ✅ "..."
- [→] Phase 2: Assumptions — 3/6 checked
- [ ] Phase 3: Ground Truths
- [ ] Phase 4: Reason Upward
- [ ] Phase 5: Validate

If conversation drifts (user asks a tangent, discussion expands on a side topic), after addressing it, immediately output:

📍 Returning to FP analysis: Phase N has M items remaining. Continuing.

Depth Standards (Anti-Shallow)

Trellis Integration

When used within a Trellis-managed project, the analysis artifacts integrate with the task system.

File Placement

.trellis/tasks/{MM-DD-slug}/
├── task.json              # Existing
├── prd.md                 # Existing — FP feeds into this
├── fp-analysis.md         # ← FP analysis output (Phases 0-5)
├── fp-progress.md         # ← Phase progress tracker (anti-drift)
├── implement.jsonl        # Existing — fp-analysis.md auto-added
├── check.jsonl            # Existing — fp-analysis.md auto-added
└── ...

Brainstorm Integration

During /trellis:brainstorm, when the task is classified as "Complex":

1. Trigger: User says "从第一性原理分析" or AI detects the problem has ≥3 unvalidated assumptions
2. Execute: Run Phases 0-3, saving output to fp-analysis.md in task directory
3. Feed into PRD:
   • Ground Truths → PRD Requirements and Constraints
   • Assumption Table → design.md Trade-offs
   • Reasoning Chain → design.md
4. Continue: Phases 4-5 inform implementation decisions

Context Injection

After FP analysis completes, add to context files:

python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "fp-analysis.md" "Ground truths and reasoning chain"
python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "fp-analysis.md" "Verify implementation traces to ground truths"

Completion Recording

After Phase 5, update task.json:

{
  "fp_analysis": {
    "completed": true,
    "axioms_count": 3,
    "assumptions_challenged": 6,
    "ground_truths_count": 5,
    "validation_passed": true
  }
}

Output Format

When applying first principles thinking, structure the final output as:

## First Principles Analysis: [Topic]

### Axioms
1. [Axiom 1] — [Why irreducible]
2. [Axiom 2] — [Why irreducible]
3. [Axiom 3] — [Why irreducible]

### Problem Essence
**Core problem:** [One sentence]
**Success criteria:** [Measurable outcomes]

### Assumptions Challenged
| Assumption | Challenge | Axiom(s) | Verdict |
|------------|-----------|----------|---------|
| ... | ... | A1, A2 | Keep/Discard/Modify |

### Ground Truths
1. [Specific, falsifiable fact]
2. [Specific, falsifiable fact]
3. [Specific, falsifiable fact]

### Reasoning Chain
GT#1 + GT#3 → [Inference] → [Step] → [Conclusion]

### Conclusion
**Recommended approach:** [Description]
**Key insight:** [What FP analysis revealed that convention missed]
**Trade-offs acknowledged:** [What we accept and why]

### Validation
- [x] Every conclusion traces to a ground truth
- [x] Every ground truth is covered
- [x] No phases skipped
- [x] Stress-tested with: [model name]

Common Traps

The Complexity Trap

Symptom: Solution is more complex than the problem warrants. FP Check: Remove one component — does it still solve the core problem? If yes, that component wasn't essential. Repeat.

The Analogy Trap

Symptom: "Company X does it this way, so we should too." FP Check: What problem was Company X solving? Is ours identical in all relevant dimensions? What constraints differ?

The Legacy Trap

Symptom: Maintaining compatibility with decisions that no longer serve us. FP Check: What was the original reason? Do those conditions still exist? What's the true cost of change vs. cost of maintaining?

More patterns and case studies: references/case-studies.md

Complementary Tools Quick Reference

Full toolkit with examples: references/thinking-models-toolkit.md

Bias Awareness

The 5 most dangerous biases for first-principles analysis:

Full 12-bias catalog with debiasing: references/bias-and-debiasing.md

Problem Decomposition

Before applying FP to a complex problem, you may need to decompose it first. Quick selection:

Full 15-framework catalog: references/decomposition-frameworks.md

Reference Files