First Principles Thinking

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.