Main idea

Keeping a business ontology up to date with the code takes two operations of a different nature, and they have to be kept apart.

The first is mechanical: determine precisely what has changed. A script reads the Git history and lists the functions, classes, interfaces, modules, API signatures and MCP-exposed contracts that were added, modified or deleted. A tool like Tree-sitter can analyse the syntactic structure to identify the elements affected.

The second is semantic: understand whether those changes introduce, modify or contradict a business concept. A class is not necessarily a concept; a new package may be nothing more than a reorganisation; a function can implement a rule without being a concept. This is where an LLM comes in: it holds the inventory up against the ontology and against the request that triggered the development, and sorts each change into one of five kinds: a new concept, a concept that changes meaning, concepts that have become inconsistent, diverging vocabulary, or a purely technical change.

Why it matters

The separation makes the check sustainable. You do not ask an LLM to reread the whole application on every change: you focus its analysis on what the script has pointed to. And the part that can be exact is exact, instead of being handed to a model that might only approximate it.

It also protects the ontology from the architecture: the script describes the technical structure, the LLM decides what belongs to the domain, and a hexagonal architecture or messy code does not impose its divisions on the domain model.

Nuances and limits

A real business change may leave no trace in the names: a condition modified inside an unchanged function escapes an inventory based on symbols. And the semantic judgement produces false positives in volumes that are not yet known.

Open questions

• How do you detect a business change that alters no class, function or signature name?