Uncertainty & Hypotheses

"Might be … but I haven't verified yet" — very low confidence: unverified, explicitly flagged as uncertain.

Confidence scale from lowest to highest:

• Lowest: "might be" / "could be" / "possibly"
  → "It might be related to the memory leak, but I haven't verified yet"

• Low-medium: "I suspect" / "I think it could be"
  → "I suspect the memory leak is involved, but I need to check the heap dump"

• Medium: "likely" / "probably" / "I believe"
  → "This is likely the memory leak — the pattern matches"

• High: "I'm fairly confident" / "strong evidence suggests"
  → "I'm fairly confident this is the memory leak — heap dump shows growing retained objects"

• Highest: "I confirmed" / "I verified" / "the root cause is"
  → "I confirmed the root cause is a memory leak in the event listener — heap snapshot shows 140MB of unreleased handlers"

Why this matters: mis-calibrated confidence — saying "definitely" when you mean "might be" — can cause teams to act prematurely on unverified hypotheses, wasting engineering time.

Option B — states a high-confidence hypothesis, shows supporting evidence, and flags the one remaining verification step.

Structure of a well-hedged hypothesis with evidence:

"[Confidence phrase] [Hypothesis] — [Supporting evidence]. [Remaining verification needed]."

Examples:
• "It's probably the auth module — consistent 401s match a token expiry edge case. Just need to reproduce in a test to confirm."
• "Almost certainly a race condition — only occurs under load in staging. I'm adding a mutex to test this morning."
• "I suspect the N+1 query issue — ORM is logging 50+ queries per page load. Need to check the eager-load config before I'm certain."

Why showing evidence matters:
• Evidence gives teammates confidence in your hypothesis
• The "just need to confirm" phrase prevents premature fixes
• Shows you have a plan — not stuck, just thorough

Appropriate hedging is NOT the same as uncertainty:
• Option B shows systematic thinking, evidence, and a clear next step
• Option A ("The bug is in the auth module") might seem more decisive, but without evidence it is overconfident and can misdirect the team
• Option D ("maybe X or maybe something else entirely") signals no hypothesis at all — unhelpful

Option C — states a current, reasoned hypothesis, gives the evidence, and names the immediate action in progress.

During live incidents, use the phrase "My current hypothesis is…":
• It signals you are reasoning systematically rather than guessing
• "Current" acknowledges it may change as more data comes in
• It invites disagreement — teammates can counter if they see something different

Incident communication hedging vocabulary:
• "My current hypothesis is…" — investigating, not confirmed
• "Based on the logs so far, it appears to be…" — evidence-grounded but not final
• "We're seeing [X], which is consistent with [Y]" — pattern matching, not confirmed
• "I need 5 more minutes to confirm before calling it" — sets expectation without stalling
• "Ruling in / ruling out" — actively narrowing the hypothesis space

Why the other options fail:
• A: "no idea" signals panic and disengages the team
• B: "definitely DDoS" before evidence can trigger a costly wrong response (e.g., blocking IPs when the real issue is internal)
• D: listing three causes without evidence creates confusion and spreads the team too thin

Option B — acknowledges the possibility, gives a specific reason to deprioritise it, and redirects to the more likely cause.

Phrases for expressing uncertainty with a directional lean:
• "I can't rule it out entirely, but…" — acknowledges possibility, signals it's not your top hypothesis
• "Unlikely, but not impossible — here's why I think it's X instead" — same structure
• "I'd put this low on the list because…" — probability language
• "Worth a quick check, but the evidence currently points to Y" — doesn't dismiss, but prioritises

The phrase "I can't rule it out" is important engineering communication — it prevents you from eliminating a hypothesis before you have evidence to do so, while still naming your current working theory.

Why absolute answers backfire during incidents:
• "Absolutely not" closes off a hypothesis prematurely — if you're wrong, the team has lost time
• "Definitely caused it" assigns blame and halts investigation of the true cause
• Evidence-based reasoning ("the timing doesn't match — errors started 40 mins before deployment") shows you checked, not just guessed

Option B — explicitly labelled as a hypothesis, with specific reasoning and a named next step.

Best practice for writing hypotheses in issue trackers:
1. Label it: "(Hypothesis — not yet tested)" or "(Unconfirmed)" at the start
2. Be specific: name the exact mechanism you suspect
3. Show your reasoning: "specifically, the component key is being re-generated on every render"
4. State the next step: "I'll add a test to verify before proposing a fix"

Why explicit labelling matters in issue trackers:
• Issue comments persist; future readers need to know if statements are hypotheses or confirmed facts
• Team members allocate work based on issue comments — "the bug is in X" causes someone to immediately start fixing X
• A hypothesis labelled as confirmed is a liability: if wrong, it wastes sprint capacity

Phrases for labelling uncertainty in writing:
• "(Hypothesis — untested):"
• "(Unconfirmed — needs investigation):"
• "(Speculation — based on pattern only):"
• "I believe this may be…" (less explicit, but softer than declarative)
• vs. "(Confirmed in test environment):" — when you have verified it

Option C — a specific confidence estimate, with the evidence driving the confidence and the source of remaining uncertainty named explicitly.

Calibrated confidence communication:
• Percentage estimates ("around 70%") are expressive shorthand — they communicate a range, not a precise probability
• The evidence clause explains WHERE the confidence comes from: "memory profiler shows pattern + matches known Node.js leak"
• The remaining uncertainty clause explains WHY it's not higher: "whether there's a second contributing factor"

Common calibrated confidence phrases:
• "Around 70–80% confident — here's what I'm basing that on"
• "High confidence — the profiler confirms it, and I reproduced it locally"
• "Medium confidence — the evidence is suggestive but not conclusive"
• "Low confidence — the symptom matches, but I've only seen it once"

Why "100% confident" is a red flag:
In engineering, 100% confidence should only be claimed when you have a deterministic system and complete test coverage. In debugging, it almost always indicates overconfidence and tends to close off investigation prematurely. Quantified hedging signals mature, systematic thinking — not weakness.

The goal is to match your language to your actual epistemic state: how much evidence do you have, how reproducible was it, and what could still surprise you?