thinking-occams-razor

What this skill does

# Occam's Razor

## Overview

Occam's Razor states: among competing hypotheses that fit the evidence equally well, prefer the one with the fewest assumptions. This skill operationalizes that principle for debugging: **test the simplest hypothesis first, and escalate to complex explanations only when evidence forces it.**

The skill has a **trigger-shrink gate**: if the simplest hypothesis can be tested in one step, just test it — don't run the full enumeration-and-scoring procedure. Reserve the full procedure for situations where multiple hypotheses genuinely compete and the simplest is not obviously testable.

**Core Principle:** "Everything should be made as simple as possible, but no simpler." — Einstein

## When to Use

- Multiple hypotheses could explain a bug and the simplest is NOT obviously testable in one step
- You're about to investigate a complex hypothesis without first testing a simpler one
- Architecture or design decisions where several approaches are viable and differ in complexity
- Root cause analysis where several causes seem plausible

Decision flow:

```
Multiple explanations exist?
  → No → Use the available explanation
  → Yes → Can the simplest be tested in one step?
      → Yes → JUST TEST IT (trigger-shrink — skip full procedure)
      → No → Do they explain the evidence equally well?
          → No → Prefer the better explanation
          → Yes → RUN FULL OCCAM'S RAZOR PROCEDURE
```

## When NOT to Use

- **Evidence already points to a specific cause.** Follow the evidence; don't downgrade to a "simpler" hypothesis it contradicts.
- **The domain is irreducibly complex** (distributed consensus, concurrency, security threat models). The simplest model is wrong; don't oversimplify ("but no simpler").
- **Only one plausible explanation exists.** There's nothing to compare — just test it.
- **"Simple" would mean ignoring a known interaction or skipping a load-bearing safeguard.** Local simplicity that creates systemic risk isn't parsimony.
- **The trigger check resolves it.** If you can test the simplest hypothesis in one step and it's confirmed, you're done — don't enumerate for completeness.

## Trigger Card

Before running the full enumeration-and-scoring procedure, ask one question: **"Can I test the simplest hypothesis in one step?"**

1. **Identify the simplest hypothesis** — the one with the fewest assumptions that still explains the evidence.
2. **Can you test it in one step?** → Yes → **Just test it.** If confirmed, report and stop. If refuted, move to the next simplest.
3. **If it can't be tested in one step** → run the full Occam's Razor procedure (enumerate, count assumptions, verify explanatory power, test in order).

If evidence already points to a specific cause, follow the evidence — don't downgrade to a "simpler" hypothesis it contradicts. For irreducibly complex domains (distributed consensus, concurrency), the simplest model is wrong.

## Procedure

### Trigger Check (Fast Path)

Before running the full procedure, ask: **"Can I test the simplest hypothesis in one step?"**

- Yes → Test it. If confirmed, report and stop. If falsified, move to the next simplest.
- No → The simplest hypothesis requires non-trivial investigation → run the full procedure below.

### Full Procedure: When the Trigger Check Doesn't Resolve

#### Step 1: Enumerate Competing Hypotheses

List all plausible explanations for the observed behavior:

```
Bug: Users intermittently can't log in

Hypotheses:
A. Session token expiration edge case
B. Race condition in auth service
C. Database connection pool exhaustion
D. Complex interaction between CDN cache, load balancer, and session service
```

#### Step 2: Count Assumptions per Hypothesis

| Hypothesis | Assumptions |
|------------|-------------|
| A. Token expiration | 1. Token validation has an edge case |
| B. Race condition | 1. Concurrent requests possible, 2. Shared mutable state exists |
| C. DB pool exhaustion | 1. Pool is undersized, 2. Connections are leaking |
| D. Complex interaction | 1. CDN caches auth, 2. LB sticky sessions fail, 3. Session sync delayed |

Count each independent assumption: +1 per assumption, +1 per component involved, +2 per external dependency, +2 for timing-dependent behavior, +3 for rare conditions, +5 for "perfect storm" scenarios.

#### Step 3: Verify Explanatory Power

Ensure simpler hypotheses actually explain the evidence:

```
Evidence: Failures correlate with high traffic periods
Hypothesis A (token edge case): Doesn't explain traffic correlation ✗
Hypothesis C (DB pool exhaustion): Explains traffic correlation ✓ — fewer assumptions than D
→ PREFERRED by Occam's Razor
```

#### Step 4: Test in Order of Fewest Assumptions

Investigate hypotheses from fewest to most assumptions. Do not skip to complex hypotheses until simple ones are ruled out.

#### Step 5: Escalate Complexity Only When Evidence Forces It

When simple explanations are ruled out with evidence, move to more complex ones. Never escalate on intuition alone.

## Output Contract

A completed Occam's Razor analysis produces:

1. **Trigger Check Result** — whether the simplest hypothesis was testable in one step
2. **Hypothesis Ranking** — ordered by assumption count, with each hypothesis' assumptions listed
3. **Explanatory Power Check** — which hypotheses fit the evidence
4. **Test Order and Results** — which hypotheses were tested, in what order, and the outcome
5. **Conclusion** — the confirmed hypothesis (or the next to test if unresolved)

For trigger-shrink cases, the output may be a single line: "Tested simplest hypothesis X — confirmed/refuted."

## Anti-Patterns

| Anti-Pattern | Symptom | Correction |
|---|---|---|
| **Oversimplifying irreducible domains** | Applying "simplest" to distributed consensus or security models | "But no simpler" — respect domain complexity |
| **Complexity bias** | Assuming complex = sophisticated, testing complex hypotheses first | Test fewest-assumption hypotheses first, always |
| **Trigger inflation** | Running the full enumeration for a one-step test | If the simplest is one-step testable, just test it |
| **Ignoring explanatory power** | Choosing the simplest hypothesis that doesn't fit the evidence | Fewer assumptions doesn't beat not fitting the data |
| **Local simplicity, systemic risk** | Choosing a simple local fix that creates fragility elsewhere | Prefer systemic simplicity over local simplicity |
| **Ritualistic assumption counting** | Spending more time counting assumptions than testing | The point is prioritization, not precision; rough count is enough |