In technical communication, accuracy is essential — and accuracy includes being honest about what you don’t know. Communicating uncertainty clearly is a professional skill, not a weakness. In English, we use a set of vocabulary called hedging language to signal degrees of certainty, probability, and approximation. This guide will help you use it naturally in engineering contexts.

Why Hedging Matters in Technical English

Making overconfident statements can damage your credibility when reality doesn’t match your claim. Making underconfident statements can make you seem indecisive. The goal is calibrated language — language that accurately reflects how certain you actually are.

Compare:

Overconfident: “This change will fix the performance issue.”
Underconfident: “I have no idea, it might work maybe.”
Calibrated: “This change should reduce latency significantly — we’ll confirm with load testing before the release.”

Hedging Phrases by Degree of Certainty

High Certainty (but not absolute)

Use these when you are confident but want to leave room for exceptions or additional data:

“This is almost certainly caused by…”
“The evidence strongly suggests that…”
“In all likelihood, the root cause is…”
“There is a high probability that…”

Moderate Certainty

Use these for your best current judgement when data is incomplete:

“It appears that…”
“This may indicate…”
“It seems likely that…”
“The data suggests, though does not conclusively show, that…”
“Our current hypothesis is…”

Low Certainty or Possibility

Use these when you are speculating or flagging a risk:

“There is a risk that…”
“It is possible that…”
“We cannot rule out the possibility that…”
“One potential explanation is…”

Qualification Language

Qualification means adding conditions that limit the scope of your statement. It prevents your claim from being misunderstood as universal.

Without qualification	With qualification
”The system handles 10,000 requests per second."	"Under current load conditions, the system handles approximately 10,000 requests per second."
"The migration takes two hours."	"Based on our staging environment tests, the migration takes approximately two hours — though this may vary depending on database size."
"This approach doesn’t scale."	"This approach may not scale beyond our current traffic levels without modification.”

Useful qualification phrases:

“under typical conditions”
“in most cases”
“assuming X”
“subject to further testing”
“based on the data available”
“at our current scale”

Approximation Vocabulary

When you can’t give precise numbers, use approximation vocabulary rather than vague language.

Avoid	Use instead
”A lot of users"	"Approximately 15,000 users” / “Roughly 12% of active users"
"It’s slow"	"Response time degrades to around 800 ms under peak load"
"It happens sometimes"	"It affects roughly 3–5% of requests"
"It’ll take a while"	"We estimate two to three weeks, pending the infrastructure changes”

Approximation words and phrases:

approximately, roughly, around, in the region of, on the order of
between X and Y, in the range of X to Y
as many as, up to, at least
on average, typically, in most cases

Hedging in Written Engineering Communication

Hedging is especially important in written reports, proposals, and post-mortems where statements can be quoted out of context.

In an incident report:

“The root cause appears to be a race condition in the session management code, though further investigation is required to confirm this.”

In a design proposal:

“This approach is expected to reduce database query time by approximately 40%, based on benchmarks run against a representative data sample.”

In a performance review:

“This engineer has shown strong progress in system design, and appears to be approaching readiness for the senior engineer role, subject to a few remaining growth areas.”

Example Sentences

“It appears that the memory leak is related to the websocket connection pool — we’re investigating, but this is not yet confirmed.”
“There is a risk that removing this cache layer will increase database load significantly during peak traffic; we should run a load test before proceeding.”
“Our estimate for the migration is in the region of three to four weeks, assuming the data team can deliver the schema changes by the end of the month.”
“The performance improvement is likely due to the new indexing strategy, though we cannot rule out the influence of the traffic drop over the weekend.”
“Based on current data, this approach should scale to approximately five times our current load — beyond that, we would need to revisit the architecture.”