First Principles Thinking

Concept Card

What it is: First-principles thinking is a reasoning discipline that breaks a problem down to propositions, definitions, constraints, and values that cannot be derived from deeper premises inside the relevant domain, then rebuilds a solution from those primitives. Richard Feynman's governing axiom — "the first principle is that you must not fool yourself, and you are the easiest person to fool" — captures the epistemic core: the method is a defense against self-deception disguised as reasoning.

Mental model: Treat every accepted belief as a candidate, not a foundation. Sort candidates into observed facts, definitions, constraints, conventions, analogies, preferences, and derived claims. Keep only the load-bearing primitives, then derive the answer upward with explicit warrants.

Why it exists: It prevents inherited assumptions from masquerading as laws. Many bad solutions persist because a team copied a pattern, optimized a proxy, or accepted an old constraint without asking whether it was still load-bearing.

What it is NOT: It is not root-cause analysis after a failure, not inversion, not Bayesian updating, not expected-value scoring, not second-order reasoning about downstream consequences, and not an excuse to discard useful prior art.

Adjacent concepts: epistemic-grounding, Toulmin argument, DSRP systems thinking, conceptual modeling, inversion, Bayesian reasoning, expected value, second-order thinking, Chesterton's Fence, the Einstellung effect, functional fixedness, CAP-style structural limits.

One-line analogy: It is dismantling a problem to the structural beams, then rebuilding only what those beams can actually support.

Common misconception: The trap is thinking "from scratch" means "ignore history." History is evidence; first principles decide whether that evidence represents a primitive, a derived claim, or a stale convention.

First-Principles Thinking

Concept of the skill

First-principles thinking has three primitives: candidate beliefs, primitive premises, and derived conclusions. Candidate beliefs are everything currently accepted in the problem frame: facts, rules, conventions, analogies, preferences, constraints, and proxy metrics. Primitive premises are the subset that cannot be derived from another premise inside the relevant domain and that survives evidence, definition, or constraint tests. Derived conclusions are rebuilt from those primitives through explicit inference steps. The method moves downward from inherited belief to irreducible premise, then upward from premise to design, decision, or explanation.

Replaces reasoning by inheritance with reasoning by construction. Without it, teams copy existing solutions, argue from analogy, preserve outdated constraints, and optimize around proxy rules whose original purpose has been forgotten. First-principles thinking strips those inherited layers away until only load-bearing facts, definitions, laws, constraints, and values remain; then it rebuilds a solution that is justified by those primitives rather than by precedent.

Distinct from root-cause analysis, which starts after an observed failure and asks what caused that failure; first-principles thinking can be used before anything fails, when the problem frame itself may be wrong. Distinct from inversion, which asks what would make the goal fail; first-principles thinking asks what must be true before any solution is valid. Distinct from Bayesian reasoning, which updates belief weights after evidence; first-principles thinking identifies the premises whose truth or falsity should be weighted. Distinct from expected-value reasoning, which compares options once the option space exists; first-principles thinking may reveal that the inherited option space is wrong. Distinct from second-order-thinking, which predicts the downstream consequences of a decision; first-principles thinking establishes whether the decision should exist at all. First-principles thinking is like dismantling a machine to its load-bearing parts, discarding decorative casing and copied attachments, then rebuilding only the mechanism that the physics of the problem requires. The common misconception is that first-principles thinking means ignoring all prior work. It does not. Prior work is useful evidence and can supply candidate premises, but it is not automatically foundational. The test is whether a belief is derivable, contingent, negotiable, or merely conventional. A copied rule may survive as a primitive if it encodes a real constraint; it fails if it is only inherited habit.

Coverage

First-principles thinking covers the reasoning move from inherited problem frame to load-bearing primitives and back to a justified conclusion. It includes assumption inventory, primitive classification, irreducibility tests, missing-premise search, premise validation, derivation-chain reconstruction, constraint checks, tactical stripping aids (Socratic questioning, the Five Whys, Feynman's anti-self-deception discipline), and anti-pattern detection when precedent, analogy, or local optimization has displaced the real problem.

Use this skill when the question sounds like:

• "Why are we assuming this has to work that way?"
• "What is actually true underneath the copied pattern?"
• "If we could not use the old solution, what would the problem require?"
• "Which constraints are real, and which are inherited habit?"
• "What do we know for sure, and what are we just repeating?"

Philosophy of the skill

First-principles thinking is useful because many constraints are second-hand. A rule that began as a physical limit, legal requirement, customer need, or economic fact can degrade into ritual after the environment changes. Once that happens, teams optimize inside a false box.

The discipline is not skepticism for its own sake. It is controlled reduction followed by reconstruction. The reduction phase prevents stale assumptions from entering as axioms. The reconstruction phase prevents analysis paralysis by requiring every conclusion to climb back from the primitives it retained.

The quality bar is not originality. A first-principles answer may converge on the conventional answer. The difference is that the answer is now justified by primitives rather than copied from precedent.

First principles are contextual, not magic bedrock. In mathematics or formal logic, a primitive may be an axiom, postulate, definition, or rule of inference. In product, strategy, architecture, and documentation, most primitives are narrower: measured facts, binding constraints, chosen values, definitions, and provisional assumptions that are irreducible for this decision at this time. Treat them as load-bearing, not eternal. If new evidence changes a primitive, rebuild the derivation instead of defending the old frame. The discipline has two halves, and both are required: Descartes-style doubt prevents inherited beliefs from entering as foundations; Euclidean-style derivation prevents the rebuilt answer from being a pile of unconnected observations. A good pass therefore ends with a premise ledger and a derivation chain, not just a list of challenged assumptions.

The trap this skill counters is well documented in cognitive science. The Einstellung effect — named from Luchins' 1942 water-jar experiments — is the finding that a method which worked before will block a simpler available solution: prior experience actively suppresses the better answer. Functional fixedness — Duncker's 1945 candle problem, where subjects could not see a tack-box as a shelf because they were fixed on its use as a container — is the same failure applied to objects rather than methods. Both are special cases of mental set: approaching a new problem with the frame that fit an old one. First-principles thinking is the deliberate countermove that drags the inherited frame into the open so it can be tested instead of silently assumed. Modern engineering popularized the same move as "reasoning from first principles rather than by analogy" — boiling a problem down to fundamental truths and reasoning back up, instead of copying what others did with slight variations.

Underneath all of it sits Feynman's first principle: you must not fool yourself, and you are the easiest person to fool. It is the governing axiom of the entire method. Every assumption test, every irreducibility check, every derivation step is an instance of that principle applied to a specific claim. Without it the technique becomes mechanical theater — tables, chains, and tests with the actual self-deception left intact.

The Workflow

1. Frame the exact question

State the decision, design problem, or explanation being sought. A vague prompt creates vague primitives. Frame the problem, not a candidate solution — strip implementation, technology, and solution bias out of the question itself.

Bad frame: "Rethink onboarding."

Better frame: "What is the smallest set of steps a new user must complete before they experience the product's core value?"

2. Inventory current beliefs

List every belief currently shaping the answer:

Do not discard anything in this phase. The goal is visibility.

DSRP deconstruction scan

Use DSRP as a formal scan for assumptions the first inventory missed. It is a discovery scaffold, not proof that a premise is true.

Feed any premise found by this scan into the Premise Ledger below. Do not let the DSRP label promote it to a primitive; it still needs the source, enforcer, falsifier, and removal-cost tests.

3. Strip inherited assumptions

For each belief, ask:

1. What would make this false?
2. Is this directly observed, defined, or required, or is it inferred?
3. If it is inferred, what premise supports it?
4. If it is a convention, what problem did the convention originally solve?
5. If it is an analogy, where does the analogy break?

A belief survives this step only if it is primitive for the problem or if its derivation is made explicit.

Chesterton's Fence — strip, do not bulldoze. Question 4 is load-bearing, and there is a discipline for answering it honestly. G.K. Chesterton's rule (The Thing, 1929) is: do not clear away a fence until you can explain why it was put up. Applied here: a convention or constraint you cannot explain is not therefore wrong — it is merely unexamined. Reconstruct the function it was serving first, then remove it only once you can show that function is now absent, served elsewhere, or outweighed. This is precisely what separates first-principles reduction from blind iconoclasm: you earn the right to delete a constraint by understanding it, not by failing to understand it. Chesterton's rule is not conservatism — it permits removal; it forbids uninformed removal.

Tactical stripping aids

These tools surface candidate premises and buried support chains. Frame them strictly as premise-discovery aids, not as proof that the resulting primitive is true.

Socratic questioning. Use the six Socratic question types to pressure-test each belief:

Five Whys (adapted). Ask why a belief must hold until the answer reaches an observed fact, definition, binding constraint, chosen value, or unsupported habit. A belief that collapses into convention after a few whys is not a primitive. Stop when the chain leaves the task scope or stops changing the decision. (This is the Toyota Production System technique, adapted here to expose premise support chains — not to replace the debugging / root-cause workflow it was originally built for.)

Anti-self-deception check. Name the answer you most want to be true, then identify which premise would be most painful to test or falsify. That premise is where self-deception hides. Feynman's principle is the epistemic floor: make it hard for the preferred answer to pass as a primitive just because the agent, team, or stakeholder wants it to be true.

4. Search for missing primitives

Assumption stripping is incomplete if it only removes false beliefs. Removing false assumptions does not guarantee the retained set is complete — a solution derived from a true-but-partial primitive set fails in exactly the place the missing constraint would have governed. Before testing and rebuilding, actively search for the load-bearing premise that no one stated. The inherited frame often omits realities that were taken for granted. Walk these categories explicitly:

• Physical / technical: latency floor, throughput limit, storage cost, failure mode, hardware or network constraint.
• Logical / structural: proof, impossibility result, algorithmic complexity, information-theoretic limit, consistency requirement, CAP-style tradeoff, invariant, or required ordering relation.
• Human: attention, memory, trust, fatigue, incentive, comprehension, risk tolerance.
• Economic: marginal cost, opportunity cost, willingness to pay, support load, distribution cost.
• Legal / policy / safety: binding rule, auditability requirement, consent, disclosure, operational risk.
• Definition: ambiguous term that must be fixed before reasoning can continue.
• Value: what the decision optimizes when tradeoffs conflict.
• Time: deadline, reversibility, learning rate, decay, migration window.
• Dependency: external system, stakeholder, vendor, interface, data owner, or upstream source of truth.

Add anything found to the ledger and run it through the tests. The highest-risk error is not keeping one stale assumption; it is rebuilding from an incomplete primitive set and getting a clean derivation to the wrong answer.

5. Test candidate primitives

Use these tests before declaring anything foundational.

In practical domains, "primitive" means "irreducible enough for the decision at hand." If a deeper premise would change the answer and is discoverable within the task scope, keep reducing. If deeper reduction would not change the decision, record the stopping point and move to reconstruction.

6. Rebuild upward

Construct the answer as a derivation chain:

Primitive 1 + Primitive 2 -> Derived conclusion A
Derived conclusion A + Primitive 3 -> Design requirement B
Design requirement B + Constraint C -> Candidate solution

Every conclusion must point back to the primitives that support it. If a conclusion cannot be derived, either add a missing primitive with evidence or remove the conclusion.

Derivation hygiene

Derive in layers, and do not jump straight from a primitive to a solution:

Primitive -> constraint or value implication -> requirement -> option space -> candidate solution

Bad: "Users have limited attention -> use a three-step wizard."
Better:
Users have limited attention.
+ The task has one high-risk irreversible decision.
-> The interface must reduce simultaneous choices and make the irreversible point explicit.
-> Candidate solutions: progressive disclosure, one-page checklist, wizard, or guided review.
-> Choose only after comparing which option satisfies the requirement with least cost.

Every derivation chain should make visible:

• Which premises are empirical and need measurement.
• Which premises are definitions and need stakeholder agreement.
• Which premises are values and need decision-owner acceptance.
• Which conclusions are requirements versus merely candidate solutions.
• Which single premise would most change the answer if it moved.

7. Reconcile with reality

First-principles reasoning can be internally clean and externally wrong if the primitives were incomplete. Stripping is only half the discipline. Before acting, check:

• Which primitives are still missing? Re-walk the failure modes, edge cases, and stakeholders not in the room; each often points to an unstated constraint that belongs in the set.
• Which primitives are empirical and need measurement?
• Which primitives are definitions and need stakeholder agreement?
• Which primitives are constraints and need expert verification?
• Which derived conclusions are brittle if one primitive changes?
• Which conventional solution did the derivation recover, and why?

When a primitive is an empirical or performance limit (e.g., "this database can't sustain X writes/sec"), code-assisted verification is a legitimate optional check: use a simulation, benchmark, or formal proof to test whether the limit is a hard physical/structural constraint or merely an unoptimized artifact. Keep it bounded to measurement and simulation — a passing benchmark is evidence about one configuration, not automatic proof that the primitive is true everywhere.

The Premise Ledger

The workflow above is a sequence of judgments. The ledger is the artifact that makes those judgments explicit and reproducible: one row per belief, carried from inventory through stripping, testing, and reconstruction, with a status label that records where each belief currently stands. Without it, assumption state stays in the reasoner's head and a reviewer — human or agent — cannot tell which constraints were tested, which were assumed, and which were removed and why. Use a ledger whenever the problem has more than a few beliefs.

Each belief carries one status at a time; the status changes as the belief moves through the workflow.

For non-trivial problems, carry the working columns so each row is auditable end-to-end:

A worked ledger row reads end-to-end:

Belief: "Onboarding needs five steps."        Type: Convention   Status: Inherited
  -> reconstruct function: steps 1-2 collect legally-required consent; 3-5 are habit
  -> Status: Stripped (3-5, reason: no load-bearing function) + Grounded (1-2, reason: legal constraint)

The ledger is the recommended output of a first-principles pass: it lets anyone audit the derivation by checking that every retained primitive is Grounded or Stipulated, every Provisional has a test, every Stripped has a reason, and no conclusion rests on an Inherited belief. Do not promote a Provisional belief to a primitive because it sounds plausible — either ground it, stipulate it, name it as a chosen value, or keep the uncertainty visible.

Primitive Types

Value premises are legitimate primitives, but only after being named honestly. Hiding a value premise inside a "fact" is a reasoning bug.

Common Applications

Product design

Start with the user's job-to-be-done, attention budget, risk, and required trust. Do not start with competitor screens or inherited flows. Rebuild the flow from the minimum sequence needed for the user to make progress safely.

Technical architecture

Start with invariants, failure modes, latency budgets, data ownership, reversibility, and operational constraints. Do not start with a fashionable architecture label ("we need microservices because Google does," "we need Kafka"). Rebuild boundaries from what must remain true when components fail or scale — e.g., instead of "we need Kafka," ask "what persistence, ordering, and latency does this message flow actually require?"

Strategy

Start with customer value, constraints, distribution reality, margins, and capability asymmetries. Do not start with category norms. Rebuild the strategy from what must be true for the system to win.

Skill and documentation authoring

Start with what behavior the reader must perform differently after reading. Do not start with a table of contents copied from neighboring artifacts. Rebuild the document from primitives: trigger, boundary, mental model, procedure, verification.

AI Agents and Modern Tooling

Why agents especially need this skill

An AI agent often answers by analogy — it completes the most familiar pattern for a request, which tends toward "what others did, with slight variations." That default is fast and usually adequate, but it is prone to importing an inherited solution wholesale (a copied architecture, a conventional schema, a standard five-step flow) without testing whether the problem's primitives actually require it. The convenient pattern is not, by itself, evidence that the pattern is correct for this problem. Apply this skill deliberately when the cost of the default pattern is high or the context is unusual: name the primitives the task truly constrains, then check whether the pattern-matched answer is derivable from them or merely familiar.

The validation boundary (the load-bearing point)

Stronger reasoning models, extended-thinking modes, "think" tools, web search, retrieval, and agent frameworks help execute this workflow, but they do not replace it. A model thinking longer can generate better candidate premises; it cannot by itself prove that a premise is true, current, complete, or load-bearing. A retrieved "fact" can be stale, a confidently generated constraint can be a hallucinated convention, and no amount of fluent generation tells you which primitives are missing. Tool results and citations are evidence inputs, not automatic validation.

So the division of labor for agent work is:

• Use the model to propose candidate beliefs and missing-premise classes (Step 2 and Step 4).
• Use tools to verify empirical primitives against files, tests, docs, measurements, or the actual law/spec — not against the model's own confidence (Step 5 and Step 7).
• Use agents to stress-test: argue for and against a premise to surface confirmation bias; build a simulation or benchmark to test whether a performance limit is a hard constraint or an optimization artifact; analyze existing documentation to extract "background-noise" assumptions a team internalized as immutable.
• Hand a primitive or derived claim that must be source-supported in the final artifact to epistemic-grounding. This skill owns the decomposition and reconstruction, not the citation audit; when a primitive depends on current external facts, route that verification to epistemic-grounding or a web-capable research workflow.
• Keep context tight: load the facts and constraints needed for the derivation, not every related document. Record uncertainty explicitly when a premise remains provisional.

Upstream-displacement check. No reasoning model, search tool, context-management method, or agent framework displaces first-principles thinking. These tools improve decomposition, retrieval, and execution, but the skill still owns deciding which beliefs are primitive, which are inherited, and how conclusions are rebuilt. Treat model output as a candidate-premise generator, never as the validator of primitive truth — and never accept a model's "I reasoned from first principles" as proof that it did.

Boundary Routing

Anti-Patterns

Output Shape

When applying this skill, prefer this structure:

Question:
The exact decision, design, or explanation being rebuilt.

Candidate belief inventory:
- Facts / Definitions / Constraints / Values / Conventions / Analogies / Derived claims

DSRP scan:
- Distinctions / Systems / Relationships / Perspectives

Premise ledger:
| Candidate | Type | Status | Source / owner | Falsifier | If removed, what breaks? |

Missing primitives checked:
- Physical / Logical-structural / Human / Economic / Legal-policy-safety / Definition / Value / Time / Dependency

Retained primitives:
1. ...

Derivation:
Primitive(s) -> implication -> requirement -> option space -> candidate solution

Reality checks:
- Empirical checks needed / Stakeholder definitions needed / Value tradeoffs needing owner decision / Most brittle primitive

Result:
The action-constraining conclusion, with uncertainties marked.

Verification

After applying this skill, verify:

• The exact question was framed before decomposition, free of implementation bias.
• Current beliefs were inventoried (a ledger for non-trivial problems) before anything was discarded.
• Distinctions, systems, relationships, and perspectives were scanned for hidden premises.
• Candidate primitives are classified as facts, definitions, constraints, or values.
• Inherited conventions and analogies were tested rather than accepted; Socratic questioning or the Five Whys was used to surface buried premises.
• Every convention slated for removal had its original function reconstructed before it was stripped (Chesterton's Fence), not removed merely because it was unexplained.
• A missing-primitive search was run across the categories (physical, logical-structural, human, economic, legal-policy, definition, value, time, dependency) before reconstruction — not only a strip of false beliefs.
• Logical / structural limits were checked separately from empirical technical constraints.
• Every retained primitive passed irreducibility, evidence, scope, necessity, and stability checks.
• Each belief carries an explicit status (Grounded, Stipulated, Provisional, Inherited, Derived, Stripped, or Missing); every Stripped belief records its reason; every Provisional has a test.
• Cognitive-fixation traps were checked: familiar pattern, familiar tool use, and preferred answer.
• The derivation separates requirements from candidate solutions and was rebuilt through explicit steps.
• Empirical primitives have a measurement plan, benchmark, or evidence source.
• Value premises are named as values, not disguised as facts.
• A self-deception check was run ("what would it take for this conclusion to be wrong?") and the answer was recorded.
• No model or tool output was treated as validation without source or environment evidence; any external/current primitive was verified or explicitly handed to epistemic-grounding.
• The final answer constrains action; it is not merely an abstract restatement.

Do NOT Use When

Key Sources

• Aristotle's Metaphysics frames wisdom as concern with primary causes and starting-points, and treats the principle of non-contradiction as a fundamental axiom of reasoning. The Greek term Aristotle uses for such a starting-point is archē — the first thing from which something is or is known.
• Aristotle's Physics opening, as summarized in public reference sources, describes inquiry as moving from what is clearer to us toward what is clearer by nature, seeking first principles, causes, and elements.
• Euclidean and formal-logical traditions treat axioms, postulates, definitions, and primitive notions as starting points from which further propositions are derived — and separate those starting points from the propositions derived from them.
• Descartes' method of doubt and foundationalism show the destructive-then-constructive pattern: remove doubtful inherited beliefs, then rebuild from clearer foundations. His practical method also prescribes dividing difficulties, ordering reasoning from simpler to more complex, and reviewing for omissions — a direct ancestor of the premise ledger, derivation chain, and missing-premise search.
• The modern engineering articulation, popularized in Elon Musk's widely circulated 2013 interviews, frames the method as reasoning "from first principles rather than by analogy" — boiling a problem down to its most fundamental truths and reasoning up from there, instead of copying "what other people are doing, with slight iterations on a theme." The canonical worked example ignores a finished product's market pric

…(truncated)