occams-razorlisted

# Occam's Razor ## Overview Among explanations that fit **all** the evidence equally well, prefer the one that requires the fewest new assumptions. Simplicity is a **tie-breaker between equally-good fits** — never a license to ignore evidence. The boring explanation that accounts for the facts beats the interesting one that also accounts for the facts. **This is scoped to explanation-selection: diagnosis, root-cause, and "which theory is right."** It is NOT "always build the minimal thing" — that's a different principle. Don't apply this razor to trim requirements, features, or scope. ## When to Use - Diagnosing a bug, outage, or unexpected behavior - Picking between two+ candidate root causes - An intermittent / "works sometimes" failure (these especially tempt exotic theories) - You catch yourself reaching for: a race condition, an ABI/native-layer fault, a compiler bug, cosmic bit-flips, a "subtle" interaction — before ruling out the mundane **Do NOT use for:** design/architecture scope decisions, feature cutting, or anything where "simplest" means "do less work." Those aren't explanation-selection. ## The Recipe (produce these parts, in this order) 1. **Evidence & constraints.** List what must be true. Include the discriminating facts (e.g. "*sometimes* fails" rules out any theory that would fail *every* run). 2. **Candidate causes, cheapest-assumption first.** Order by how many new/unverified assumptions each needs. High-prior mundane causes go first: config/perm