Main idea

"An invoiced order accepts no further lines" is a verifiable statement. It does not need translating to become a test case: it names a state, an action and a verdict. A few hundred rules written that way are as many candidate tests nobody had to derive from a source file.

The same sentence renders a second service, at another desk. Faced with a customer report, the question stops being a matter of experience and becomes mechanical: does the observed behavior contradict a written rule — then it is a defect; or did no rule cover the case — then it is a product decision that was never taken. Without a corpus of rules, that verdict is delivered by seniority, by whoever remembers.

Why it matters

It moves the value of a rule reference model outside documentation: it feeds test coverage and the qualification of reported issues, two activities that usually have no common source.

And it gives an immediate return on the writing effort, which matters for work whose exploitation has not yet started: a written rule is useful the moment it is written.

Nuances and limits

A rule that works as a test has to be true with no tacit condition. "Certain operations require validation" is not a test: it is a rule written in general terms where the case expected the detail, and that is the most frequent and the hardest flaw to see in this kind of corpus.

An object described with no rules at all never signals a business with no rules: it signals a superficial description.

Open questions

• What share of the rules written this way survives the move to automated testing without having to be rewritten in technical vocabulary?