Hedge Language: How 'Should,' 'Might,' and 'Generally' Weaken Your Policies

The word "should" has ended careers and cost organisations millions. Not because it is wrong — it is often exactly the right word — but because it is used in places where "must" or "will" was intended, and the difference is legally and operationally significant.

What is hedge language?

Hedge language consists of words and phrases that reduce the strength of a claim or obligation. In everyday writing, hedging is appropriate and honest: it acknowledges uncertainty. In policy documents, contracts, and regulatory filings, it can transform an obligation into a suggestion.

Common hedge words include:

**Modal verbs:** should, may, might, could, would, can **Frequency qualifiers:** generally, typically, usually, often, normally, regularly, sometimes **Scope qualifiers:** approximately, roughly, in most cases, where possible, where practicable **Softeners:** endeavour, aim, seek to, try to, consider, take into account

Each of these has legitimate uses. The problem arises when they appear in contexts where a reader — or a court — would expect a hard obligation.

The legal consequence

In contract law, "shall" and "must" create enforceable obligations. "Should" and "may" do not. This distinction is codified in drafting guides and enforced by courts.

A data protection policy that says employees "should" encrypt sensitive files is not equivalent to one that says they "must." If a breach occurs, the organisation cannot demonstrate that encryption was required — only recommended. Regulators treat this distinction seriously.

The same applies to financial covenants, service-level agreements, and compliance obligations. A maintenance schedule that says work "should" be completed quarterly does not give the same contractual protection as one that says it "will" be.

Operational consequences

Weaker language in internal policies produces the same problem operationally. If a procedure says staff "should" complete a form before proceeding, some will and some will not — and both groups can point to the policy to justify their behaviour.

"Generally" is especially corrosive. "Generally, invoices should be processed within 30 days" gives finance teams room to interpret the rule however is convenient. It creates variance where uniformity was intended.

When hedging is correct

Not all hedging is a defect. Some obligations genuinely depend on context: "Where technically feasible, data should be pseudonymised." Some represent aspirational standards rather than enforceable requirements. And some are appropriate given genuine uncertainty.

The test is whether the hedge is intentional and appropriate for the document's purpose, or whether it crept in from cautious drafting habits.

How to audit for hedge language

A systematic approach checks every instance of the key hedge words in context. For each one, ask: is this a requirement that should be expressed as an obligation? If yes, replace "should" with "must" or "will." If the hedged form is correct, note why — so the reasoning is clear to future reviewers.

Automated detection flags all instances with their surrounding context, making the review efficient. The goal is not to eliminate hedging — it is to ensure that every hedge is deliberate.

A practical rewrite guide

• "Employees should follow the security policy" → "Employees must follow the security policy"
• "Invoices will generally be processed within 30 days" → "Invoices will be processed within 30 business days"
• "The vendor should endeavour to meet response times" → "The vendor will meet the response times in Schedule A"
• "Reports may be submitted quarterly" → "Reports must be submitted quarterly" (or: "Reports may be submitted quarterly at the customer's option")

The rewritten versions are unambiguous. The obligation, the timeframe, and the consequences of non-compliance are all clear. That clarity is the entire purpose of a policy or contract.