Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
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 this way are as many candidate tests that nobody had to derive from a source file.
The same sentence does a second job, at a different desk. Faced with a customer report, the question stops being a matter of experience and becomes mechanical: does the observed behaviour 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 body of rules, that verdict is handed down by seniority, by whoever remembers.
Layer added by "Ontology-Driven Design: what if the ontology became the safety net for AI-generated code?" (2026-10-29). The invariants of a business ontology — a confirmed invoice can no longer be modified, a credit note references the invoice it corrects, a cancelled order cannot be shipped — can also be used to check that existing tests cover them, and to spot rules that are not yet checked by anything. Checking code produced by an agent then plays out on two levels: a semantic level, where an LLM examines the consistency between the intent, the concepts and the code; and a deterministic level, where the rules that have become tests verify what can be formalised.
Why it matters
It moves the value of a body of rules outside documentation: it feeds test coverage and the triage of reported issues, two activities that usually share no common source.
And it gives an immediate return on the writing effort, which matters for work that is not yet in use: 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 unstated condition. "Certain operations require approval" is not a test: it is a rule written in general terms where the case called for detail, and that is the most frequent and hardest flaw to spot in this kind of corpus.
An object described with no rules at all never signals a business with no rules: it signals a shallow description.
Open questions
- What share of the rules written this way survives being turned into automated tests without having to be rewritten in technical vocabulary?