Modal Verbs for Certainty and Uncertainty

"must" expresses near-certainty based on logical deduction. When you have strong evidence and are drawing a firm conclusion, use must: "This must be a race condition", "The memory leak must be in the event listener." The certainty scale for modals of deduction: must (90–99% certain — strong evidence, logical conclusion) → should (70–80% — expected based on design) → might / may / could (30–50% — possible but not confirmed). In code review and debugging, using the right modal signals your confidence level to colleagues. "It must be a race condition" means you have evidence; "it might be a race condition" means you're speculating. Option B ("could") and A ("might") express possibility, not certainty. Option D ("should") implies expected behaviour, not a diagnosis.

"may" expresses possibility — the cause is plausible but not confirmed. Runbooks and troubleshooting guides often list possible causes using may or might: "The pod may be failing due to resource limits", "The timeout may indicate a DNS resolution issue." must would imply certainty — incorrect if you're listing possibilities. will expresses future certainty or habitual behaviour. shall is formal and mostly used in legal/contractual contexts (rare in technical docs). In troubleshooting documentation, the progression is: "The pod may fail if X" (possible) → "The pod will fail if X" (certain, documented behaviour) → "The pod must be restarted" (required action).

"should" expresses a confident expectation or prediction based on design intent or best practices: "With caching, latency should drop", "With horizontal scaling, throughput should increase." It implies "if things work as designed, this is the expected outcome." must is too strong for a prediction — it expresses obligation or near-certainty about a fact. might and could introduce doubt ("there's a chance it might drop") — appropriate for speculation, not confident predictions. In ADRs and technical proposals, should is the right signal: "This approach should improve performance by 40%." It commits to an expected outcome without making an absolute guarantee.

"should" is perfect for cautious optimism: it signals that the outcome is expected and probable, but acknowledges that conditions must hold. "The feature should be ready by Friday" communicates confidence with a slight hedge — preferable to "will" if there's ongoing work. will expresses certainty ("The feature will be ready by Friday" — you're committing fully, no room for slippage). Using will when things are uncertain sets unrealistic expectations. must expresses obligation or logical deduction, not prediction. shall is archaic in tech contexts. Sprint communication tip: Use should for predictions with mild uncertainty, will only when you're fully confident, and might when the delivery is in doubt.

"might / could" both express possibility with uncertainty — exactly the right signals when you're speculating without confirmation. "The test failure might be related to the flaky network mock" or "It could be the mock" both signal: "I have a hypothesis, not a conclusion." The difference between the two: might is slightly more tentative than could, but in practice they're interchangeable for possibility. In tickets, Slack threads, and PR comments, calibrating your modals matters: "it must be the mock" implies certainty and can mislead colleagues; "it might be the mock" keeps the investigation open. Best practice: "It could be X — I'll confirm after running the isolated test." This keeps communication honest and prevents premature root-cause assumptions.