Main idea

The most central object in a business application commonly carries four names: sales_order in the code, "order" on the screen, a third term in the suite's second application, "deal" or "case" among customers. The engineer's reflex is to see an inconsistency to reduce, by imposing a single word everywhere.

That is the wrong problem. These three vocabularies — the code's, the interface's, the field's — do not have the same lifespan or the same constraints, and they evolve separately whatever you do. What is lost when you force them into line is the translation table: the ability to recognize, in the sentence of a user talking about a "deal", which product object they mean — and to answer them in their own words.

An object card therefore keeps all three layers, plus a fourth nobody thinks to keep: the terms dropped along the way. A word removed from the interface three years ago goes on circulating in tickets, training material and contracts.

Why it matters

This is what makes a product reference model usable by support, pre-sales and training, and not only by those who read the code. Without the "field" layer, every customer question goes back through someone able to do the translation from memory.

And this gap is material for analysis: a word used constantly by customers and absent from the product under any name does not signal a vocabulary problem, it signals a design gap.

Nuances and limits

Keeping the gaps does not mean deliberately maintaining them: a new name introduced without reason in a third application remains debt, and the reference model then serves to make it visible.

The "field" layer ages fast and is only worth keeping if it carries frequencies measured on a real corpus — interview notes, tickets — rather than recollections from a workshop.

Open questions

• After how long does an abandoned term stop being worth keeping, and on what signal should it be archived?