Main idea

The consistency between a piece of software's code and its domain model usually remains implicit. An ontology kept up against the code makes it observable through a few measures: ontology coverage, the share of business concepts spotted in the code that are represented in the ontology; traceability, the number of concepts linked to their implementation by verifiable references; the number of confirmed, unresolved inconsistencies, which gives an idea of the drift; and the proportion of invariants linked to executable tests, which measures how solid the safety net is.

None of these measures is an absolute quality indicator. All of them depend on the same ability: telling a real business concept from a class, a table or a package that is merely a technical detail.

Why it matters

These measures offer an alternative to counting lines of code at a time when agents produce plenty of them: tracking a piece of software's conceptual consistency as it changes, rather than its volume.

Nuances and limits

If the sorting between concept and technical noise is poor, every indicator measures noise with precision. The figures are only as good as that sorting, and it is partly done by an LLM.

Open questions

• Can an ontology coverage indicator resist the urge to optimise it for its own sake, by adding to the model concepts that are not really concepts?