Detailed reference for detecting and fixing reasoning failures specific to first principles thinking.
Pattern: Start with a known conclusion, then construct a "from scratch" derivation that inevitably arrives there. The reasoning looks rigorous but was never at risk of reaching a different answer.
Detection:
- The "derivation" mentions the conventional solution by name before reaching it through reasoning
- Every reasoning step narrows toward one answer with no forks or alternatives considered
- Removing the "first principles" framing changes nothing about the output
- The conclusion matches the first Google result for the question
Fix: Before concluding, identify at least one branch point where different evidence would have led to a different answer. If you can't find one, acknowledge that you're confirming convention, not reasoning from fundamentals.
❌ Let's think from first principles about project management. Projects have tasks, tasks have dependencies, dependencies need tracking. Therefore, you need a Gantt chart.
✅ Project management reduces to: coordinating parallel work streams under resource and time constraints. A Gantt chart solves the dependency-visualization part but assumes sequential planning. If your constraint is rapid iteration rather than dependency management, a kanban board addresses the actual bottleneck. The choice depends on which constraint is binding: dependency complexity or iteration speed.
Pattern: Breaking something into its components (parts list) instead of its underlying principles (constraint space). The decomposition mirrors the existing architecture, guaranteeing the same architecture in the rebuild.
Detection:
- "Fundamentals" are nouns (engine, database, header) rather than relationships or constraints (force, throughput, attention)
- The decomposition would only make sense to someone who already knows what the thing looks like
- Rearranging the "fundamentals" doesn't produce any novel configuration
Fix: Restate each "fundamental" as a constraint or requirement, not a component. "Database" → "persistent state with X consistency and Y latency requirements."
❌ A web application fundamentally consists of: frontend, backend, database, and authentication. Let's optimize each.
✅ A web application must: (1) present interactive state to users at <100ms latency, (2) persist state changes durably, (3) verify user identity. These constraints can be met by a traditional 3-tier stack, but also by edge-computed static sites with serverless functions, or local-first architectures with sync engines. The binding constraint determines which approach — if latency is dominant, push compute to the edge; if data consistency is dominant, centralize.
Pattern: Applying one domain's version of "fundamentals" to a problem that lives in a different domain. Typically: using physics/engineering decomposition for coordination problems, or using abstract philosophy for concrete engineering.
Detection:
- Reasoning about social/organizational problems in terms of physical costs or material constraints
- Reasoning about engineering problems in terms of "values" or "principles" without quantifying
- The word "fundamentally" followed by a claim from a different discipline than the problem domain
- Ignoring emergent properties that only exist at the problem's native level
Fix: Name the domain explicitly. Then name what counts as ground truth in THAT domain.
❌ Healthcare costs from first principles: a hospital bed costs $X in steel and fabric, an MRI machine costs $Y in magnets and electronics. Therefore healthcare should cost much less than it does.
✅ Healthcare costs from first principles: the binding constraints are (1) information asymmetry between provider and patient, (2) regulatory barriers to entry that limit supply, (3) emergency demand that eliminates price negotiation, (4) principal-agent problems in insurance. Raw material costs are <5% of the issue. Reducing healthcare costs requires addressing coordination and incentive structures, not material costs.
Pattern: Applying a memorized first-principles template (usually "what are the raw costs?") to every problem regardless of fit. The template was correct in its original context but is being applied without checking whether the same logic holds.
Detection:
- The phrase "what does X actually cost?" applied to a service, not a product
- Decomposition always landing on material/energy costs regardless of the domain
- Ignoring that the "fundamental cost" might be time, coordination, trust, attention, or risk — not dollars and atoms
- Quoting the SpaceX or Tesla battery example as justification for the approach
Fix: Before decomposing, ask: "What is the binding constraint in this specific problem?" The answer determines the decomposition axis.
❌ Education from first principles: a textbook costs $3 to print, a classroom is a room with chairs, a teacher's knowledge is freely available online. Therefore education should cost almost nothing.
✅ Education from first principles: the binding constraints are (1) sustained student attention over months, (2) feedback loops that correct misunderstanding in real-time, (3) credentialing that employers trust. Content delivery is largely solved (free online). The unsolved problems are motivation, personalized feedback, and signal value — none of which are material cost problems.
Pattern: Treating first principles as "ignore everything and start from zero." Discarding all prior knowledge, including validated knowledge, because it's labeled as "assumption." The result is either naive re-derivation of known truths or confident ignorance.
Detection:
- Dismissing established findings without checking if they're empirically grounded
- "Let's forget everything we know about X" as an opening move
- Re-deriving well-established results poorly, producing a worse version of known knowledge
- Confusing "question the assumption" with "discard the assumption"
Fix: Audit, don't erase. For each piece of prior knowledge, classify it: (a) empirically verified → keep as ground truth, (b) conventional but unverified → flag for examination, (c) contradicted by evidence → discard.
❌ Let's think about nutrition from first principles. Forget everything you've heard. The body needs energy. Food provides energy. Therefore, any calorie-dense food is equally good nutrition.
✅ Nutrition from first principles: the body requires specific micronutrients, essential amino acids, and essential fatty acids — these are empirically verified constraints, not conventions. The convention to audit is food categorization (the "food pyramid," "superfoods") — these are cultural constructs layered on top of biochemical requirements. The ground truths are metabolic pathways; the conventions are dietary guidelines.
Pattern: Adding first-principles language ("fundamentally," "at its core," "from the ground up") to a standard analysis without changing the reasoning process. The output looks like first-principles thinking but follows the same path as default reasoning with different decorations.
Detection:
- Remove all instances of "fundamentally," "at its core," "from first principles" — does the text change meaning? If not, it's decoration.
- The "principles" listed are mid-level abstractions from common knowledge, not actual foundational truths
- No convention was identified, questioned, or discarded during the analysis
- The analysis would be identical if prompted with "explain X" instead of "reason about X from first principles"
Fix: Apply the discard test: name at least one thing you previously accepted that this analysis revealed to be convention rather than ground truth. If you can't name one, you haven't done first-principles work.
❌ From first principles, a good team fundamentally needs: clear goals, strong communication, mutual trust, and accountability. These are the core building blocks of team performance.
✅ Most team advice assumes co-located, full-time, stable membership — these are conventions, not givens. The actual constraints are: (1) shared mental model of the goal state, (2) information reaching decision-makers before deadlines, (3) consequences for commitments being credible. An async team of contractors can satisfy all three without "strong communication" or "mutual trust" in the traditional sense. The conventional team playbook optimizes for one configuration; the principles permit many.
When reviewing your output for first-principles anti-patterns, scan in this order:
- Opening → Structural mimicry? (Did I just add "from first principles" as decoration?)
- Decomposition → Theater? (Am I listing parts or identifying constraints?)
- Domain → Mismatch? (Are my "fundamentals" from the right discipline?)
- Template → Cargo cult? (Am I applying the "raw cost" template by default?)
- Prior knowledge → Blank slate? (Did I audit or just erase?)
- Conclusion → Retroactive justification? (Could my reasoning have landed elsewhere?)