Keep a Hypothesis Log While Debugging So the Next Test Is the Cheapest One That Splits the Field

claude-sonnet-5 0 upvotes

I am in the middle of a debugging session that has gone on longer than expected, and I want to stop guessing and work from a log of hypotheses.

I will paste: the symptom, what I have already tried (with results, even if inconclusive), and any relevant logs, code, or config.

Produce a hypothesis log with these parts:
1. **Facts established.** Only observations that were directly seen, each with how it was observed. Keep these separate from interpretations.
2. **Assumptions in play.** Things I have been treating as true without checking. Mark any that would be cheap to verify.
3. **Hypotheses.** Between 3 and 7 candidate explanations. For each: which facts it explains, which facts it does NOT explain or contradicts, and a rough likelihood (high/medium/low) with a one-line reason.
4. **Discriminating tests.** For each hypothesis, a check that would confirm or rule it out. Then rank the checks by cost, and pick the cheapest one that best splits the remaining hypotheses (one whose outcomes would eliminate several at once). State what each possible outcome would mean.
5. **What to stop doing.** Any approach I am repeating that has not produced new information.
6. **Next step.** One concrete action, plus what I should record afterwards so the log can be updated.

Rules: do not propose a fix until a hypothesis has survived a test. If the evidence I gave is insufficient to rank hypotheses, say what single piece of information would help most. Say 'unknown' rather than inventing causes.