First Principles Thinking

First Principles Thinking

Overview

First Principles Thinking is a mode of inquiry that relentlessly questions assumptions to get to the fundamental truth of a problem, then builds a solution from scratch. It is the tool of the innovator, used to bypass "reasoning by analogy" (copying what others do).

When to Use

• Innovation: When the user wants to invent a new way of doing things.
• Stuck Points: When standard solutions are too expensive, too slow, or impossible.
• Debugging: When "it should work" but doesn't—strip away assumptions about why it should work.
• Cost Analysis: When you need to understand the absolute floor of a cost structure.

When NOT to Use

• Well-trodden problems: When analogical reasoning is sufficient and the cost of being wrong is low.
• Quantum/Biological systems: FPT assumes independence of atomic units; quantum entanglement and biological emergence violate this.
• Social/Human systems: Human behavior is not decomposable into physics axioms—consult domain experts instead.
• Time-critical decisions: FPT is computationally expensive; under deadline pressure, use decision-matrix or analogical reasoning.
• When expertise is available: If a domain expert can be consulted and the problem is within their validated expertise, rely on their map.

Domain Boundary Checklist

Before applying FPT, confirm:

• Problem is mechanical, supply-chain, or computational (not quantum/biological/social)
• Atomic units are empirically verifiable (not model-dependent)
• Cost of being wrong is high enough to warrant full deconstruction
• Time available exceeds 2x estimated analysis duration

Skill Integration Cross-References

• Before FPT: Use decision-matrix to confirm FPT is warranted (high-stakes, innovative)
• After FPT: Use systems-thinking to check feedback loops and emergent behavior
• Combined Protocol: When facing adversarial contexts, chain inversion-thinking → FPT
• Complementary: Use rubber-ducking to verify plain-English explanation of atomic units
• Avoid over-use: If FPT hits deadline frequently, the problem may be too ill-defined—consider escalating

Methodology

1. Identify & Question Assumptions (Socratic Method)

Goal: Expose the hidden beliefs limiting the current view.

Answer Classification

When "Why?" yields an answer, classify it before proceeding:

Timeboxing

• Maximum: 5 "Why?" iterations OR 30 minutes, whichever comes first.
• Stop at: (a) verified physical law, (b) unverified claim you cannot verify with Search/Read.
• Deadline fallback: Accept current best assumption with confidence label (verified/assumed/unknown) and proceed. Log deadline hits.

Pareto Prioritization

Before questioning an assumption, estimate:

• Centrality: How core is this to the problem? (1-5)
• Likelihood of being wrong: (1-5)
• Priority Score: Centrality × (5 - Likelihood)

Question assumptions with Priority Score ≥ 15 first. Low-likelihood assumptions are often correct—skip them.

• Prompt: "What are we assuming to be true here? Why do we think that?"
• Technique: Ask "Why?" up to 5 times.
  • CRITICAL: Do not answer from memory. Search/Read to verify the answer to each "Why?".
  • Stop: When you hit a physical law, a mathematical truth, or a verified hard constraint.

2. Deconstruct to Constituent Parts

Goal: Find the atomic units that cannot be reduced further.

• Action: Break the system down into:
  • Physics: Mass, energy, material properties.
  • Logic: Axioms and necessary truths.
  • Economics: Raw material costs, time units.

Validation Step

Label each atomic unit as:

• Verified — empirically confirmed under relevant conditions
• Model — theoretical construct (e.g., economic "spot price") with known limitations
• Assumed — no verification attempted

For Model/Assumed units, note confidence interval and conditions where they may not hold.

3. Reconstruct from Scratch

Goal: Build a 10x better solution using only the essential parts.

• Action: Ignore "how it's usually done." Combine the atomic units in the most efficient way possible to achieve the goal.

Second-Order Checkpoint

Before implementing, ask:

1. What new interactions does this solution create?
2. What feedback loops might emerge when it scales 10x?
3. What breaks if this solution becomes widely adopted?

Use systems-thinking if feedback loop analysis is complex.

Boundary Conditions

This framework rests on unquestioned assumptions:

• Breaking problems down is useful (may fail for emergent systems)
• Atomic units exist (may fail for quantum entanglement)
• Deconstruction reveals truth (may fail for social/human systems)

Document these as explicit limits. Re-evaluate if problem domain shifts.

Examples

The SpaceX Example (Cost Reduction)

User: "Rockets are too expensive." Analogy Reasoning: "Rockets define the market price. We can maybe save 10% by negotiating." First Principles Reasoning: "A rocket is just aluminum, titanium, and fuel. The spot price of these materials is 2% of a rocket's cost. The cost is inefficient manufacturing. We will buy raw metal and build it ourselves."

The "Chef vs. Cook"

Analogy (Cook): Follows a recipe. If an ingredient is missing, they stop. First Principles (Chef): Understands why the acid balances the fat. If a lemon is missing, they use vinegar, because the principle is acidity.

Self-Improvement Protocol

Log only if you found something genuinely new.

## [YYYY-MM-DD] {Brief Description}
**Assumption challenged**: {what was assumed}
**Breakthrough**: {what you found instead}
---

Promote after 3+ similar discoveries.

Resources

• Detailed Research Notes

Evaluations

Eval 1: Cost Reduction Problem

Scenario: User says "Our CD pipeline is too expensive." Conventional thinking suggests "negotiate with vendor." Expected: Breaks down to atomic costs (servers, bandwidth, labor), questions vendor markup assumption. Pass criteria: Reaches "2% of cost is raw materials" level decomposition, proposes building in-house.

Eval 2: Domain Boundary Check

Scenario: User wants to apply FPT to "how should we design our company culture?" Expected: Recognizes as social/human system, advises using domain expert instead. Pass criteria: Identifies domain as inappropriate for FPT, redirects appropriately.

Eval 3: Inversion-FPT Chain

Scenario: User asks "How could we accidentally build a monopoly?" in context of new product design. Expected: Chains inversion-thinking → FPT, uses saboteur mode first, then decomposes. Pass criteria: Applies inversion before FPT in adversarial context, identifies how to prevent the failure mode.