Main idea

A business ontology can be supplemented with a map: the invoice concept associated with the classes, functions, events and API operations that take part in its implementation. These associations do not define the concept; they say where it is implemented.

That distinction makes possible questions that neither layer can answer on its own. If you modify the invoice concept, which parts of the code are likely to be affected? If a business function disappears, which rule might no longer be implemented? Does a new API operation expose an existing concept or reveal a new notion? Is a renamed class a refactoring or a real change to the domain?

The map can be maintained as the code changes, but each association must keep its evidence: the files, symbols and observed changes it rests on.

Why it matters

Impact analysis stops depending on the memory of whoever knows the code. And by requiring evidence, you separate two things an LLM easily conflates: a demonstrated correspondence and a merely inferred relationship.

Nuances and limits

A correspondence inferred by an LLM looks exactly like a demonstrated one. Without the evidence attached, the map accumulates plausible links that nobody can tell apart from the real ones any more.

The map also ages: the correspondences have to be re-examined, at a frequency nothing yet determines.

Open questions

• How often should the correspondences between concepts and code be re-examined for them to stay reliable?