REQUIRED: Activate UltraThink mode before proceeding.

First Principles Reasoning

Core belief: Most complexity is accumulated cruft, not necessity. Question everything.

The Three Models

1. The Idiot Index

Idiot Index = Cost of Finished Product / Cost of Raw Materials

High ratio = hidden inefficiency. Ask: "Why does this cost 10x the materials?"

Apply to: time, money, complexity, code, process. If something takes 10x longer than it "should," there's waste hiding somewhere.

Example: A feature takes 2 weeks. The actual code is 50 lines. Where did the other 9.5 days go? Meetings? Unclear requirements? Waiting? Find it.

2. First Principles Decomposition

Not: "How has this been done before?" Instead: "What is actually true? What's possible from there?"

Process:

1. Identify the fundamental truths (physics, constraints, actual requirements)
2. Ignore how it's "normally done"
3. Reason up from the fundamentals

Example:

• Convention: "We need a CRM integration"
• First principles: "We need to know when a lead's status changes"
• Reframe: Maybe a webhook, maybe polling, maybe the CRM isn't even needed

3. The Algorithm (5-Step Optimization)

Execute IN ORDER. Do not skip steps.

Step 0: Establish Ground Truth (Before Everything)

Before optimizing anything, verify you understand reality:

1. QUESTION THE REQUIREMENTS
   - Who made this requirement? Why?
   - Is it actually necessary or just assumed?
   - The most dangerous requirements are the smart people's requirements
   
2. DELETE THE PART/PROCESS
   - Best part is no part. Best process is no process.
   - If you're not adding back 10% of what you delete, you're not deleting enough
   
3. SIMPLIFY/OPTIMIZE
   - Only after you've deleted. Don't optimize something that shouldn't exist.
   - Simplify before optimizing
   
4. ACCELERATE CYCLE TIME
   - Only after simplifying. Speed up what remains.
   - Faster iteration beats better planning
   
5. AUTOMATE
   - LAST, not first. Don't automate waste.
   - Automating a broken process just makes it fail faster

Critical: Most people start at step 3 or 5. This is wrong. Always start at step 1.

Deep Dives

For detailed examples and anti-patterns on each step:

Application Framework

When approaching any problem:

1. State the goal - What are we actually trying to achieve? (Not the solution, the outcome)

2. List the requirements - Then for each one:

   • Who made this requirement?
   • What happens if we delete it?
   • Is this a real constraint or an assumption?

3. Calculate the Idiot Index - Where is the waste hiding?

4. Run The Algorithm - In order, steps 1-5

5. Sanity check - Does this solution pass the "explain to a smart outsider" test?

Anti-Patterns

The Meta-Rule

If you find yourself adding complexity, stop. The goal is REMOVAL, not addition. The best solution is the one with the fewest parts that still works.

When in doubt: delete, simplify, then stop.

Red Team Checkpoint (After Planning)

Before presenting conclusions:

1. Attack your own plan - What's the weakest point?
2. Steelman alternatives - What's best case for options you rejected?
3. Identify hidden assumptions - What must be true for this to work?
4. Express confidence honestly - Where are you most/least certain?

See also: references/truth-seeking.md for epistemic framework.