A Duration Is Two Facts: a Length and a Starting Gun

"6 months free."

Everyone agreed on the six. The six was never in doubt for a moment.

Four Statements of the Length, Three of the Start

The duration appears four times across the artefacts. Six months, consistently, every time. If you were checking for contradictions between documents, this requirement passes.

The starting point appears three times, and it is a different starting point on each occasion.

The design says from purchase. The payload to the billing system expresses it in billing periods. The sibling story says from go-live.

Three anchors. Nobody flagged it, because nobody was looking at that half of the sentence.

The Gap That Turns This Into Money

On this journey, order submission and service activation can be weeks apart.

That gap is what converts a documentation inconsistency into a customer outcome.

Anchor the six months to purchase and a customer waiting five weeks for an engineer burns five weeks of a free period against a service they cannot use. They were advertised six free months. They receive somewhat less than five.

Anchor it to activation and they get the full six, starting when the service does — a different cost to the business than the one the finance model assumed, on every order with a long lead time.

Anchor it to go-live and the promotion is a fixed window on the calendar, identical for everybody, which means the offer quietly shrinks for every customer who buys later in it.

Same six. Three materially different products. Nothing in the requirement chooses between them.

The Omission in the Payload

There is one more detail, and it is the one I would put on a slide.

The payload omits the start date. The neighbouring rate plans in that same payload all carry one.

An absent field is not visible on its own. It becomes visible against its siblings — the shape of the thing next to it is what tells you something is missing. Read that payload in isolation and it looks complete, because there is nothing there to look at.

And an omitted field does not mean no decision was taken. It means the default fired. Whatever the billing system does with a missing start date on a rate plan is now the anchor for this promotion, chosen by nobody, agreed with nobody, and documented nowhere.

The most consequential decision in this requirement was made by a default value.

Why Refinement Never Catches It

A duration feels fully specified the moment the number is agreed.

That is the mechanism, and it is a property of how the fact is shaped rather than of anyone's diligence. "6 months free" is a complete-sounding phrase. It has a number, a unit and a benefit. It fits on a marketing page. It reads like a fact you can test against.

So refinement argues about three versus six months — that is a real commercial question with two named sides and a cost attached, and it can absorb the whole conversation. Nobody asks which event starts the clock, because the number arriving felt like the answer arriving.

The length is the part everyone can see is missing when it is missing. The anchor is the part nobody notices is missing, because a duration without an anchor still looks like a duration.

The Rule

Treat every duration in a requirement as two facts: a length and a starting gun. Refuse to write the expected result until the second one is named.

Refusing is the operative word. Not asking politely and proceeding. You cannot write an expected result for a six-month promotion without an anchor — you can only write one that assumes an anchor, and an assumed anchor inside an expected result is indistinguishable from a specified one to everyone who reads your test afterwards.

If you must proceed, write the anchor you assumed into the test as an explicit line. That way the assumption fails visibly rather than passing silently.

Three Checks That Take Ten Minutes

• Write every duration as an interval with two ends. "6 months, from X to Y." If you cannot fill in X from the requirement, the requirement is incomplete, and that is the finding — before any discussion of behaviour.
• Name the event, not the date. "From purchase" is not one event on a journey where submission, activation and first invoice are separate things weeks apart. Push until the answer is an event the system actually raises, because that is the only form of the answer a developer can implement and a tester can assert.
• Diff the payload against its neighbours. A field that every sibling carries and this one omits is a decision delegated to a default. Compare like against like inside the same payload; omissions are only visible in contrast.

Why the System Will Look Correct Regardless

This is the reason the wrong anchor survives into production.

Whichever anchor was built, the observable behaviour matches the headline. Six invoices at zero, then a charge. Count them and it is six. Screenshot it and it looks exactly like the promotion that was advertised.

The anchor is not visible in the outcome. It is only visible in the alignment between the outcome and an event that happened weeks earlier, and checking that alignment means going back to the order, finding the submission date, finding the activation date and asking which of them the first free period actually attached to.

That is not a step anybody performs by accident. It only happens if you decided, at requirement stage, that the anchor was a fact you were going to test.

Pick the next duration in your backlog. Can you name the event that starts it, without opening a document?