Main idea

Checking the code an agent has produced against a business ontology after the fact works, but too late: the agent has already created classes, added methods and written tests around a wrong reading of the business, and all of that has to be revisited.

TDD solved the same problem for behaviour: you write the test before the code. Carried over to the domain model, it gives the agent a different order of work. Before writing a line, it identifies the ontology's concepts and rules that the request touches, flags the contradictions between the request and the model, gets them resolved, then develops, and finally checks that the code produced holds up against the expected model.

In an ERP where every order must originate from a quote, the request "allow an order without a quote" runs into a rule before a single file has been modified. The contradiction becomes visible at the point where it still only costs a decision.

Why it matters

The check stops being a correction and becomes a way of framing the work. The agent starts from an explicit understanding of the domain rather than from its own interpretation, and business decisions are taken before they are encoded.

The agent does not need to load the whole ontology for this: it selects the concepts, relationships and rules the request touches.

Nuances and limits

The analogy with TDD has a clear limit: an ontology is not a test suite, and an analysis by an LLM does not offer the guarantee of a deterministic assertion. What is borrowed is the order of operations, not the certainty of the verdict.

A contradiction flagged upstream is not necessarily a mistake in the request: it may announce an intended change in the business.

Open questions

• How many of the contradictions an agent flags upstream turn out, on inspection, to be false positives?