Analyst Field Guide · First-Principles Thinking
Most of the time we reason by analogy — "this is like that, so do what worked before." It's fast and usually right. First-principles thinking is the other tool: strip a problem down to what is actually, verifiably true, and rebuild the answer from there. This guide is when to reach for it, how to run it, and the honest limit — a method is not a guarantee of being right.
A first principle is something you can't take apart any further — a fact or constraint that isn't true because something else is. First-principles thinking is the discipline of finding those bedrock truths, noticing everything you'd merely assumed on top of them, and rebuilding the answer from the bedrock up. The idea is old — Aristotle's archai, Descartes rebuilding knowledge from what he couldn't doubt — but the working point is practical: when the usual answer keeps failing, stop copying it and go down to what's actually true.
There are two ways to get to an answer. Reasoning by analogy maps the current problem onto one you've seen — "this looks like the outage last month, do what fixed that." Reasoning from first principles ignores what looks similar and asks what is fundamentally true here, then derives an answer from those truths alone.
The distinction isn't "smart vs. lazy." Analogy is how experts move quickly, and re-deriving a solved problem from scratch is usually a waste. The skill is knowing which tool the situation calls for — the subject of the next section.
First-principles reasoning is expensive — it's slow, effortful, and easy to do badly. Spend it deliberately. The signals that it's worth the cost:
Reach for first principles when the cost of a wrong borrowed answer exceeds the cost of the extra thinking — and stay with analogy when a proven pattern fits. Most work is analogy; first principles is the tool you pull out at the specific moments above, not a way of life. Using it everywhere is its own failure mode (§8).
First-principles thinking is a repeatable loop, not a flash of insight. Run it in order, and expect to go around more than once.
You can't test an assumption you haven't noticed, and the load-bearing ones hide precisely because they feel obvious. They betray themselves in language. When you hear yourself or a colleague use these words, stop and write down the belief underneath:
| The tell | The hidden assumption to examine |
|---|---|
| "We can't …" | Is it physically impossible, contractually forbidden, or just never tried? Only the first two are real constraints. |
| "It must / it has to …" | Says who, and by what mechanism? A requirement, or a habit dressed as one? |
| "We always / never …" | A convention or a policy — rarely a law of nature. Why was it set, and does the reason still apply? |
| "Obviously …" / "everyone knows" | The most dangerous tell: it discourages the question. Ask it anyway. |
| "That's just how it works" | An inherited decision whose rationale has been forgotten. Recover the rationale or discard the constraint. |
1. How do we know this is true — what's the actual evidence? 2. Is it fundamental, or does it rest on something else (and what)? 3. What would have to be true for it to be false — and can I check that? 4. If it weren't true, what would that make possible? Explaining the claim from scratch, in plain words, as if to someone new (the "explain-it-simply" test) exposes the gaps you've been gliding over.
The method lives or dies on one judgment: which of your "constraints" are bedrock and which are movable. Get this wrong and everything downstream is wrong. A rough sorting:
| Bedrock — keep | Movable — test, then keep or discard |
|---|---|
| Physical and logical law (a link is up or it isn't; a hash matches or it doesn't) | Conventions and defaults ("we always image machines this way") |
| Contractual, legal, and regulatory requirements | Inherited decisions whose rationale is forgotten |
| Facts you have verified in this specific environment | Analogies to other situations, and untested beliefs |
Note the asymmetry: a "verified fact" is only bedrock if it was actually verified here, not assumed from a similar system. The moment you catch yourself importing a fact by analogy, it drops out of bedrock and back into the movable pile.
The method is concrete or it's nothing. Two everyday cases from IT and security work.
The assumption is the solution ("a VPN"), not the need. State the need from first principles: a named person, on a healthy device, should reach specific internal resources, with the traffic encrypted and every access authorized. A full-network VPN is one way — but it grants network-wide reach and puts an internet-facing concentrator in front of everything (see the VPN guide). Rebuilt from the need, per-application brokering (ZTNA) may fit better. The point isn't "VPNs are bad"; it's that "a VPN" was an inherited answer standing in for an unstated requirement.
First-principles reasoning is only as good as the truths at the bottom, and in support and incident work those truths usually come from a person — a user, a client, a customer — describing something you didn't see. People report conclusions, not observations: "the internet is down," "your update broke it," "nothing changed." Each is an interpretation, and if you feed interpretations into the method as if they were fundamentals, you've poisoned the bedrock.
When you gather facts, pull the reporter back to the observable: what did you see on the screen, what were you doing when it happened, when did it last work, what exactly changed. "Nothing changed" almost never survives "walk me through what you did this morning." Ask open, non-leading questions — a leading question ("did the power flicker?") plants an answer and manufactures a false fundamental. Getting accurate, relevant information out of a non-expert reporter is a discipline of its own, and it's the input this whole method depends on. It pairs with the diagnostic intake in the Troubleshooting guide and the evidence discipline in Root Cause Analysis and Incident Response.
The method has sharp edges. Most bad first-principles reasoning fails in one of these ways:
| Failure | What it looks like |
|---|---|
| False bedrock | Treating an assumption as a fundamental (or a real constraint as "just a habit"). The classification in §5 is wrong, so the rebuild is confidently wrong. |
| Analysis paralysis | Re-deriving solved problems from scratch. You don't need first principles to decide to use TCP; analogy is correct and free here. |
| Motivated reasoning in disguise | Selecting the "fundamentals" that happen to support the answer you already wanted. First-principles framing lends false authority to a foregone conclusion. |
| Incomplete premises | Reasoning validly from a true but partial set of facts — and missing the one you never gathered (§7). |
This is the honest limit, and it's worth stating plainly: reasoning from first principles does not make a conclusion correct. It is only as sound as its premises and their classification, and "I reasoned from first principles" is not evidence that you did so well. The output is a hypothesis to be tested — which is exactly where the calibration and competing-hypotheses discipline of the Critical Thinking guide takes over. Treat a first-principles conclusion as your best current model, held with the confidence its evidence actually supports, not as a proof.
First-principles thinking isn't a rival to the other reasoning guides — it's the layer that questions the frame the others operate inside.
Read together: first principles decides whether you're solving the right problem at all, troubleshooting and RCA work the problem, and critical thinking keeps the confidence honest.
| Belief | Reality |
|---|---|
| "First-principles thinking is always the smarter approach" | It's expensive and often wasteful. Analogy is the right default; first principles is for when the default fails or the stakes justify the cost. |
| "If I reason from first principles, I'll be right" | A method isn't a guarantee. It's only as good as the premises and their classification; the output is a hypothesis to test. |
| "It means questioning everything" | It means questioning the load-bearing assumptions. Questioning settled fundamentals is just paralysis. |
| "Experts don't need it — they know the patterns" | Expertise is mostly good analogies, which is why experts are also the ones most anchored when the pattern quietly stops applying. |
| "Get to the fundamentals and the answer is obvious" | Only if you classified the layers correctly and gathered complete facts. Both are where it goes wrong (§7–§8). |
Analogy reuses a past solution (and its assumptions) — fast, usually right. First principles strips to what's verifiably true and rebuilds. Reach for it when the usual fix keeps failing, the case is novel, or the stakes make an unexamined default too risky.
State the problem (not the fix) · surface every assumption · test each (truth or belief?) · decompose to fundamentals · rebuild from the true parts · check, and iterate.
"can't," "must," "always/never," "obviously," "that's just how it works." On each: how do we know? is it fundamental? what if it's false? what would that make possible?
Keep: physical/logical law, contracts & law, facts verified here. Test then discard: conventions, defaults, inherited decisions, analogies, beliefs. Misclassifying a layer breaks everything downstream.
Garbage in: you can't reason from a reporter's conclusions — get to observations. And a method is not a proof: the result is a hypothesis to test with the Critical Thinking discipline, held at the confidence the evidence supports.
This guide is method, not standards — its claims are about reasoning, and the honest caveat is built in: first-principles reasoning is a way to generate better hypotheses, not a guarantee of correct ones. It is only as sound as its premises and their classification into fundamental vs. assumed, and it depends on accurate, observation-level facts rather than a reporter's conclusions. The intellectual lineage (Aristotle's archai; Descartes' method of doubt) is noted as background, not as authority. Companion to Troubleshooting (applied decomposition under pressure), Critical Thinking (calibrating the hypotheses this produces), Root Cause Analysis (the shared "keep asking why," aimed at causes), and — for the facts this method runs on — the diagnostic intake in Troubleshooting and the evidence discipline in Incident Response. A dedicated guide on eliciting accurate information from a client or customer is a natural next companion in this family.