first-principles-thinking — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited first-principles-thinking (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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 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.
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:
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.
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?"
List every belief currently shaping the answer:
| Belief type | Test question |
|---|---|
| Observed fact | What was directly measured or seen? |
| Definition | What does the term mean by contract? |
| Constraint | What cannot be changed without violating physics, logic, law, safety, time, money, or human limits? |
| Value | What are we choosing to optimize? |
| Convention | What are we doing because others do it this way? |
| Analogy | What outside system are we importing a model from? |
| Derived claim | What conclusion depends on earlier premises? |
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.
| Lens | Inventory question | Typical hidden premise |
|---|---|---|
| Distinctions | What boundary is being drawn, and what is being excluded by that boundary? | The category split is natural rather than chosen. |
| Systems | What whole, parts, and nesting level are being assumed? | The current component, team, workflow, or market boundary is the right unit of analysis. |
| Relationships | What causal, dependency, ordering, or feedback relation is being assumed? | One variable drives another, or the relation is one-way rather than reciprocal. |
| Perspectives | Whose point of view defines the problem, value, risk, or success measure? | The user, operator, buyer, maintainer, regulator, or model all see the same problem. |
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.
For each belief, ask:
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:
| Question type | Purpose | Example |
|---|---|---|
| Clarification | Establish what the claim actually means | "What exactly does 'onboarding' include?" |
| Probing assumptions | Surface what is taken for granted | "Why do we assume the first step requires an email?" |
| Probing reasons / evidence | Find the warrant behind the claim | "What evidence supports the five-step flow?" |
| Viewpoints / perspectives | Test whether the claim holds from another angle | "What would a first-time user assume on arrival?" |
| Implications / consequences | Trace what follows if the claim is wrong | "If we removed this step, what actually breaks?" |
| Meta-questions about the question | Check whether the framing itself is correct | "Is 'improving onboarding' even the right problem?" |
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.
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:
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.
Use these tests before declaring anything foundational.
| Test | Pass condition | Failure signal |
|---|---|---|
| Irreducibility | It cannot be derived from a deeper premise in scope | It starts with "because we usually..." |
| Evidence | It is observed, measured, defined, or otherwise grounded | It is asserted from habit or authority only |
| Scope | It holds for this problem, not just for a similar one | It depends on an imported analogy |
| Necessity | Removing it makes the solution invalid | Removing it only makes the solution unfamiliar |
| Stability | It will not flip under ordinary variation | It depends on a temporary implementation detail |
| Source / warrant | It has a source, owner, definition, measurement, or explicit value decision | It is supported only by confidence, title, seniority, or repetition |
| Enforcer | A named force makes it binding: physics, law, contract, customer behavior, budget, time, or explicit value choice | Nobody can say what enforces it |
| Falsifier | There is a realistic observation or argument that would make it fail | It is protected from challenge by vague wording |
| Replacement cost | Removing or changing it creates a real cost that can be named | Removing it only causes discomfort or breaks precedent |
| Level fit | It belongs at the primitive level, not at the solution, implementation, or metric level | It already smuggles in the old solution |
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.
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 solutionEvery 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 solutionBad: "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:
First-principles reasoning can be internally clean and externally wrong if the primitives were incomplete. Stripping is only half the discipline. Before acting, check:
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 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.
| Status | Meaning | Next action |
|---|---|---|
| Grounded | Observed, measured, proven, or required — passed the primitive tests. | Retain as a primitive; record the evidence source. |
| Stipulated | A definition or value premise chosen by agreement, true by decision rather than by evidence. | Retain, but name it as a choice — never disguise it as a fact. |
| Provisional | Assumed pending evidence; plausibly primitive but unverified. | Assign a test or measurement before it can carry a conclusion. |
| Inherited | A convention or analogy not yet justified. | Reconstruct its original function (Chesterton's Fence), then promote, demote, or strip. |
| Derived | A conclusion that depends on other premises — not a primitive. | Keep only its supporting primitives in the foundation; re-derive it upward. |
| Stripped | Removed from the foundation. | Record the reason (false, redundant, or function now absent / served elsewhere). A strip with no recorded reason is not a strip. |
| Missing | An unstated constraint surfaced during the missing-premise search or reconciliation. | Add it to the ledger and re-run the tests; do not proceed until placed. |
For non-trivial problems, carry the working columns so each row is auditable end-to-end:
| Candidate belief | Type | Status | Source / owner | Falsifier | If removed, what breaks? |
|---|---|---|---|---|---|
| "Users must enter company size before activation." | Convention / derived claim | Provisional | Current onboarding flow, competitor comparison | Cohort data shows no downstream use or value | Personalization may degrade if size is actually used |
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 | Meaning | Example |
|---|---|---|
| Physical law | Cannot be violated by any design | Latency cannot be lower than propagation and processing time combined; thermodynamic heat/power limits. |
| Mathematical identity | True by definition or proof | Profit equals revenue minus costs under the chosen definition; a comparison sort cannot beat n·log n; Shannon channel-capacity limits. |
| Logical or structural constraint | A limit imposed by computation, information, or structure — independent of physical or economic resources, and distinct from a mere identity because it bounds what any design in the space can achieve | A distributed system cannot hold consistency, availability, and partition-tolerance at once (CAP); a step cannot run before the invariant it depends on holds (ordering constraint). |
| Human constraint | Stable limit of human attention, memory, time, or behavior | A user cannot compare twenty dense options accurately under time pressure (Miller's 7±2 working-memory limit). |
| Economic constraint | Resource tradeoff that cannot be wished away | Storage, review time, compute, and support load all have opportunity costs. |
| Legal or policy constraint | Binding rule from outside the design space | A required disclosure must be present before action. |
| Definition | Meaning chosen by the system or domain | "Active user" must be defined before optimizing activation. |
| Value premise | What the decision optimizes | Reliability over novelty, speed over completeness, or reversibility over throughput. |
| Cognitive fixation risk | A stable human tendency that makes a familiar frame, tool, or solution feel more primitive than it is | A team keeps selecting the inherited workflow because repeated exposure made it feel inevitable, not because it survived the primitive tests. |
Value premises are legitimate primitives, but only after being named honestly. Hiding a value premise inside a "fact" is a reasoning bug.
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.
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?"
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.
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.
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.
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:
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.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.
| User need | Use | Mechanism |
|---|---|---|
| Rebuild a decision, design, strategy, or explanation from load-bearing facts, definitions, constraints, and values | first-principles-thinking | Strips inherited beliefs, tests primitives, derives upward |
| Prove that a claim is sourced, qualified, current, and warranted | epistemic-grounding | Checks source-to-claim support and claim state |
| Model business entities, attributes, relationships, identity, and cardinality | conceptual-modeling | Builds an implementation-neutral domain model |
| Diagnose why a user, designer, operator, or agent has the wrong internal representation of a system | mental-models | Compares model-system fit and analogy effects |
| Investigate one observed failure, failing test, or contradictory runtime output | debugging or problem-locating-solving | Reproduces, isolates, and verifies a root cause |
| Find recurring issue classes across many instances and codify prevention | pattern-recognition | Clusters repeated observations and creates detection / prevention |
| Predict the downstream consequences of a decision already on the table | second-order-thinking | Traces ripple effects forward in time |
| Compare known options by probability-weighted payoff | expected-value | Scores options after the option space exists |
| Update belief weights after evidence | Bayesian reasoning | Revises probabilities, not primitive status |
| Ask how a plan could fail | inversion / pre-mortem | Reverses the goal to reveal failure paths |
| Anti-pattern | What it looks like | Correction |
|---|---|---|
| Physics cosplay | Treating social, product, or business claims as universal laws | Mark value and behavior premises as contingent and testable. |
| Premature axiom | "This is a requirement" with no evidence | Ask what happens if it is removed and who or what enforces it. |
| Analogy lock-in | "This is like X, so we should do Y" | Identify where the analogy breaks before deriving conclusions. |
| Abstraction escape | Staying so abstract that no decision changes | Rebuild upward until the conclusion constrains action. |
| Destructive skepticism | Discarding every prior belief and never rebuilding | Treat prior work as evidence, not authority or trash. |
| Incomplete primitive set | Stripping false assumptions correctly, then deriving from a true-but-partial set | Run the missing-premise search (Step 4); a clean derivation from missing constraints still fails. |
| Premature fence-clearing | Removing a specific rule, step, or boundary because no one present can explain it | Reconstruct the constraint's original function first; remove it only once you can show that function is gone, served elsewhere, or outweighed (Chesterton's Fence). An unexplained constraint is unexamined, not disproven. |
| Framework defaulting | Adopting a framework (microservices, generic RAG, a standard flow) without validating its underlying premises | Derive the need for the framework from system limits; build custom only if the framework violates a primitive. |
| Solution-smuggling | Naming the old solution as a primitive, e.g. "we need microservices" | Translate the solution label into the constraints it allegedly satisfies. |
| Axiomatic theater | Decorating a preference or solution with "first principle" language | Force the belief into the ledger and require type, source, falsifier, and removal cost. |
| Novelty bias | Rejecting prior art because the method feels like "starting from scratch" | Treat prior art as evidence; keep it if it encodes a real constraint or a successful derivation. |
| Over-reduction | Continuing to decompose after the answer would no longer change | Record the stopping rule: deeper premises are out of scope or decision-irrelevant. |
| Einstellung trap | Reusing a familiar method after the current problem makes a simpler or more direct path available | Ask what solution would be chosen if the familiar pattern were unavailable, then compare constraints directly. |
| Functional fixedness | Treating a tool, object, role, or concept as if its usual use is its only possible use | List alternate uses before concluding that a new component, workflow, or policy is required. |
| Model-autonomy laundering | Accepting a model's "I reasoned from first principles" as proof that it did | Inspect the premise ledger, evidence, and derivation chain. Longer thinking is not validation. |
| Cargo-cult reasoning | Copying the form of first-principles work (tables, chains, tests) without doing the assumption work | Every conclusion must trace to a tested primitive. |
| Self-deception pass | Letting the preferred answer survive because the ledger never tried to falsify its most convenient premise | Apply Feynman's test: name the premise you least want to test and make its falsifier explicit. |
| Proxy primitive | Optimizing a metric as if it were the goal | Name the value the proxy is supposed to represent. |
| Hidden value claim | Presenting a preference as an objective fact | Separate facts from values before deriving the answer. |
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.After applying this skill, verify:
epistemic-grounding.| Use instead | When |
|---|---|
debugging or problem-locating-solving | You have an observed failure and need root-cause isolation. |
epistemic-grounding | You need to prove that a claim is sourced, qualified, and warranted. |
conceptual-modeling | You need to model domain entities, attributes, relationships, identity, and cardinality. |
pattern-recognition | You need to cluster repeated issues and turn recurrence into prevention. |
second-order-thinking | You need to predict the downstream consequences of a decision already taken. |
inversion | You need to reverse the goal and ask how the plan could fail. |
expected-value or Bayesian reasoning | You need to update probabilities or compare options by probability-weighted payoff. |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.