Occams Razor

Simplest Sufficient Explanation

[The winner and why]

Distinguishing Evidence

[What would confirm or rule out alternatives] </output_format>

Observations to Explain

• P95 latency increased from 200ms to 800ms last Tuesday
• No code deployments that day
• Database CPU is normal
• Only affects the /search endpoint
• Traffic volume unchanged

Candidate Explanations

Simplest Sufficient Explanation

Upstream search provider experienced degradation. This requires only one assumption (provider incident), explains why only /search is affected (it's the only endpoint calling that provider), and fits the Tuesday timing without needing a code change.

Distinguishing Evidence

Check the provider's status page for Tuesday incidents. If clean, run curl directly against the provider API to measure current latency. If provider is fast, re-examine the search index. </example>

Key Instructions

• A simpler explanation that doesn't account for all known facts is not Occam's Razor — it's an incomplete explanation; simplicity cannot come at the cost of explanatory coverage.
• Does not prescribe investigation steps; identifies the most parsimonious explanation to test first.

Anti-Pattern Guards

1. Discarding evidence to achieve simplicity — the simplest explanation must fit all known facts; simplifying by ignoring inconvenient observations is not Occam's Razor.
2. Conflating common with simple — a common explanation requires fewer assumptions only if its commonness doesn't itself require additional assumptions to explain.

Handoff

Receives: A phenomenon or problem with multiple possible explanations and a set of known observations Produces: A ranked candidate explanation table with the simplest sufficient explanation and distinguishing evidence Chainable to: 5-whys (to drill into the chosen explanation's root cause), map-vs-territory (to check whether the observations themselves are accurate)