"If Required" Is an Unassigned Decision

Three sentences in one technical design, all describing the same matching rule.

"Full postcode or prefix."

"Prefix matching if required."

"Exact or prefix depending on the agreed business rule."

Read them as prose and they are consistent — the author is being careful, flagging that a decision sits with the business. Read them as a specification and there is no rule in the document at all. Three descriptions, zero decisions.

Somebody Decides Anyway

That is the part that makes hedged wording a defect rather than a drafting style.

The behaviour cannot stay undecided. The system will either match on the full code or match on a prefix; there is no third state where it hedges. So between the document and the release, the decision gets made — and if the document did not make it, whoever wrote the code did.

Not deliberately. A developer with a deadline reads the prose, finds three answers, and then does what any reasonable person does: looks at the worked examples to see what was meant.

Every worked example in that document used a prefix.

So the decision was made. It was made by the examples, by a developer who never experienced themselves as deciding anything, and it entered the build with no record, no owner and no review — because from the inside it felt like implementing the spec.

Prose Hedges. Examples Never Do.

This is the mechanism worth carrying away, and it applies to every specification you will ever read.

A spec has two channels. The prose is where authors express uncertainty, because prose has room for "if," "depending on," and "to be confirmed." The examples are where they express what they actually picture, because an example cannot hedge. You cannot write half a postcode match. The moment the author types a concrete case, they have committed to an interpretation, whether or not they noticed.

Where the two channels disagree, the examples win. Every time. They are the only part of the document that is executable by a human being.

Which gives you a review technique, not just an observation: where prose is ambiguous, read the examples to find out what will be built. Not what should be — what will be. Then check whether the examples agree with each other, because the author was not treating them as normative and so nobody proofread them as a set.

What the Examples Said, and What They Also Said

In this design they did not agree with each other.

Take prefix matching seriously — a "starts with" comparison — and a row configured for PE1 captures PE10 through PE19 as well. Nineteen other postcode districts, silently included, because a string comparison has no concept of a postcode district boundary.

And the same document's examples routed some of those longer codes to a different catalogue.

So the specification, read end to end and implemented exactly as written, produces a customer looking at the wrong price list. That is derivable at document stage. No environment, no data, no build, no access to anything. It follows from one hedge that was never assigned and one worked example that was never checked against another.

The Prefix Question

Generalise the specific one, because it recurs across every identifier scheme in enterprise software.

Whenever a spec permits prefix matching on any code, ask: which longer codes begin with the same characters, and where do they route?

It applies far past postcodes. Product codes where a family prefix is also a valid SKU. Account numbers where the branch prefix is itself a valid lookup. Country dialling codes. Any scheme where the codes are variable-length and one valid value is a proper prefix of another valid value — which is most schemes that grew by extension rather than by design.

The failure mode is always the same shape. The short row silently swallows a set of longer codes, the swallow is invisible in every example the author wrote, and it surfaces as a customer receiving something correct-looking that belongs to somebody else.

Turning Hedges Into Items

The practical move is to stop reading hedges as sentences and start treating them as an inventory. That takes one pass and produces an artefact, which is the point — a conversation about a hedge evaporates, a list of them does not.

• Mark every hedge as you read, without judging it. "If required." "Depending on the agreed rule." "To be confirmed." "Where appropriate." "As applicable." Highlight, do not argue. Judging as you go slows you down and you will miss the quiet ones, and the quiet ones are the ones that survive review.
• Give each one an owner and a date, and record the current default. The owner is a named person, not a team. The default is what the build will do if the decision never arrives — usually whatever the examples imply — and writing that down converts an open question into a stated behaviour someone can object to.

That second half is what makes the list work. "Matching rule to be agreed" invites nodding. "Matching rule undecided; the examples imply prefix; under prefix, PE1 also captures PE10 to PE19 and the design routes those elsewhere" invites a decision, usually the same day.

Why This One Escapes

Because hedged wording passes review by looking like the opposite of a defect.

It reads as diligence. The author flagged an open point rather than inventing an answer, which is the professionally correct thing to have done, and a reviewer who challenges it sounds like they are demanding certainty nobody has yet. So it survives refinement, survives sign-off, and reaches the build intact.

And it produces no failing test afterwards. There is nothing to test against — whatever the system does matches at least one sentence in the document, so any bug raised can be closed by quoting a different paragraph.

The only cheap moment to catch it is while reading. After that, the decision has already been made by someone who did not know they were making it.

In the last spec you reviewed, how many hedges were there — and can you name who owns each one?