Main idea

A business ontology kept up to date automatically from the code has a flaw that mirrors that of documentation going stale: if it systematically changes to follow the code, it no longer checks anything. When one agent introduces a mistake, a second agent that updates the ontology to make it acceptable turns the drift into a rule. The model becomes continuously regenerated documentation.

The opposite excess is no better: a model that forbids any change contrary to its current rules stops the product from changing.

The path between the two is to handle every change to the model explicitly. When the change is intentional and clear, a versioned modification of the ontology is prepared, possibly applied in a working branch before sign-off. When the code change looks contrary to the intent, you fix the code rather than the model. When the intent is ambiguous, you ask for a decision instead of inventing a rule.

Why it matters

The model becomes an evolving contract between intent and implementation, not a reflection of the latest state of the code. That is the condition for it to serve as a safety net: the code must not automatically be right.

This requires a history. A renamed concept must not turn into two independent concepts, and a deleted rule must stay linked to the decision that justified removing it — for example in a small decision log inspired by ADRs.

Nuances and limits

Every change handled explicitly costs human attention. If every change goes through a decision, the setup slows down the development it was meant to make safer.

Open questions

• At what volume of changes awaiting sign-off do teams stop reading proposed changes to the model and approve them by default?