6 exercises — practise choosing the right hedging phrase in IT incident reports, postmortems, bug reports, stakeholder updates, and architecture reviews.
"Based on the logs…" — anchors the claim to a specific evidence source
"This may be caused by…" — working hypothesis, not confirmed root cause
"We believe the issue is…" — team-level confidence, evidence-based but unconfirmed
"Preliminary investigation suggests…" — formal, for client-facing and executive updates
Rule: match claim strength to evidence strength — hedge early, remove hedges as you confirm
0 / 6 completed
1 / 6
Your team is investigating a production outage. The logs show elevated database query times but the root cause is not confirmed yet. Which sentence is best for a stakeholder update?
"It appears that…" is one of the most useful hedging phrases in IT incident communication. It signals that you have evidence (something specific appears to be the case) but stops short of claiming confirmed root cause. How to use it: Structure: "It appears that [observation], though [qualifier showing investigation is ongoing]." The qualifier ("though root cause analysis is ongoing") is important — it sets expectations and prevents stakeholders from treating your observation as a conclusion. When to use "It appears that": when you have visible symptoms or log evidence pointing in a direction, but have not yet confirmed the cause through testing or a definitive fix. Compare the options: Option A over-claims: "is causing" asserts confirmed causation where you only have correlation. In a post-outage review, this could damage credibility if wrong. Option C is unprofessional and too informal for a stakeholder update. Option D over-hedges into uselessness — "may or may not" communicates nothing. The hedging principle: in incident communication, your words have stakes. Over-claiming and then retracting ("actually it wasn't the database") damages trust more than appropriately hedged claims from the start. "It appears that," "Based on the logs," and "Our preliminary analysis suggests" all signal rigour without over-committing.
2 / 6
You are writing a Slack message to your team about a bug. The logs show a specific error pattern but you haven't reproduced it in staging yet. Choose the most appropriate message.
"Based on the logs…" is an evidence-anchoring hedge. It tells the reader the source of your claim (logs) and implicitly signals that the claim is evidence-based but not yet fully confirmed. How to use it: Structure: "Based on [evidence source], [observation or preliminary conclusion] — [next action or qualifier]." The closing clause ("I'm reproducing it in staging now") shows you are active, not paralysed. When to use "Based on the logs": whenever your claim is derived from log analysis but hasn't been confirmed with a fix, reproduction, or independent verification. Option B: over-claims ("the login is broken because of") — asserts confirmed causation. If your staging test reveals a different root cause, you now have to walk back a confident statement. Option C: too vague — "or something" is unprofessional in a technical context and signals low confidence in your own analysis. Option D: "logs indicate that all login attempts are failing" — this may not match the actual log evidence (all vs. some matters significantly in bug investigation). "All" is a strong claim. If only some users are affected, this is incorrect. Practical writing rule: match the strength of your claim to the strength of your evidence. Logs showing some failed logins → "appears to affect some login attempts." Confirmed reproduction → "reproduces consistently when [condition]." Fix deployed and confirmed → "resolved."
3 / 6
In a bug report you're writing for the engineering team, you want to describe the likely cause without asserting it as confirmed. Which option uses the best phrasing?
"This may be caused by…" is a precise unconfirmed-hypothesis hedge. It signals that you have a working theory supported by evidence, while leaving room for the diagnosis to be updated. How to use it: Structure: "This may be caused by [mechanism] — [supporting evidence or reproduction steps]." The supporting evidence clause transforms a vague hedge into a useful engineering communication: you give reviewers enough to verify or challenge your hypothesis. Hedging strength levels for bug reports: (Weakest → Strongest confidence) "Might be related to" → "May be caused by" → "Appears to be caused by" → "Is caused by [confirmed]." Use the right level for your confidence. Option A, "The root cause is…": use this only when you have confirmed the cause, ideally by fixing it and verifying the fix. Asserting a root cause that turns out to be wrong wastes the team's investigation time. Option C: "We don't know" — acceptable as a starting state, but for a bug report that includes "reproduces consistently when two concurrent requests share the same session ID," you clearly have a hypothesis. Option D: "possible race condition type issue" is too vague — "type issue" and "or something similar" reduce the precision of a technically specific hypothesis.
4 / 6
You are writing a section of a postmortem report, describing the team's understanding 30 minutes into an incident, before the root cause was confirmed. Which sentence is most appropriate?
"We believed [X] was likely responsible, based on [evidence]" is the standard postmortem hedging pattern for describing the team's state of knowledge at a specific time during an incident. Postmortem reports often have an incident timeline section that needs to distinguish between: What we observed (facts: "worker memory was growing linearly"), What we believed at the time (hypotheses: "we believed a memory leak was likely"), What we confirmed (root cause: "the root cause was confirmed as a missing connection pool close in the batch job handler"). Option B uses the past tense hedge correctly: "believed...was likely responsible, based on..." — it accurately represents that the team had evidence-based confidence without asserting confirmed knowledge. Option A: "had identified the root cause as" — states this as a fact at T+30, but if the actual confirmed root cause was different from what was suspected at T+30, this statement is inaccurate. Good postmortems are precise about what was known when. Option C: "thought it might be memory or something" — too informal and vague for a formal postmortem document. Option D: "no progress had been made" — factually incorrect in this scenario; having a hypothesis based on metrics is progress. Postmortem language principle: write the timeline in the past tense, clearly distinguishing hypothesis ("we believed," "our working assumption was") from confirmed findings ("root cause confirmed as," "fix verified at T+95 minutes").
5 / 6
Your team is sending a preliminary incident report to clients 2 hours into an outage. The investigation is ongoing. Which communication is most professional?
"Preliminary investigation suggests…" is a formal hedging phrase that conveys seriousness and ongoing effort without over-claiming. It is appropriate for client-facing status updates, incident reports, and executive communications during an active investigation. Structure of Option B: "Preliminary investigation suggests [specific, observable symptom]" + "Our engineering team is actively investigating" (signals active work) + "we will provide an update in [specific time]" (sets an expectation and a commitment). Each element serves a purpose. How to use "Preliminary investigation suggests": use "preliminary" to signal that your understanding will evolve. Use "suggests" (not "shows" or "proves") to indicate inference, not confirmed fact. Always specify the observable symptom, not the hypothesised root cause: "elevated latency in our primary data store" (observable, measurable) vs. "a database bug" (speculative root cause). Option A: two problems — "is down because of a database problem" over-claims the root cause, and "will be fixed in 1 hour" is a commitment without sufficient confidence. Breaking promises in incident communication is worse than giving no time estimate. "We will provide an update in 30 minutes" is safer than a fix promise. Option C: too informal and vague for client communication. "Hopefully" signals lack of control. Option D: excessive hedging ("might possibly be something... potentially... or possibly something else") contains no useful information. Client communication principle: tell clients what you know, what you are doing, and when they will hear from you next. Keep all three elements; never promise a fix time you cannot guarantee.
6 / 6
A colleague asks for your assessment of a proposed architectural change. You have concerns but no definitive evidence yet. Which response uses the best hedging?
Option D combines three hedging techniques effectively: "Based on my initial review" — evidence-anchoring hedge, signals the claim comes from review (not guesswork) while marking it as preliminary. "may introduce" — modal hedge (not "will introduce"), signals a possibility requiring investigation, not a confirmed outcome. Specific scope — "under high fan-out scenarios" — this single qualifier transforms a vague concern into an actionable technical issue. By specifying the condition, you make the concern testable. The closing suggestion ("I'd suggest we benchmark it against Option B before committing") turns the hedge into a concrete next step — a mark of constructive engineering collaboration rather than unconstructive objection. Option A: over-claim. "Is wrong" and "will cause problems" assert certainty not yet backed by evidence. Even if your instinct is right, stating it this way invites defensiveness rather than collaborative investigation. Option B: under-claim. "Fine, no issues" when you have unverified concerns is dishonest and potentially harmful. Suppressing well-reasoned doubts for social comfort is a risk in engineering reviews. Option C: too vague to be useful — it expresses uncertainty without any specific observation or suggested path. Code and architecture review principle: the goal of a review comment is to create a shared path to the best decision. Hedged, specific observations ("may introduce X under condition Y — suggest testing Z") do this. Blanket verdicts ("this is wrong") or suppressed concerns ("looks fine") do not.