The Shared Language Problem

Ask your sales team what an “active customer” is and you will hear about accounts with open opportunities. Ask finance and you will hear about accounts that generated revenue this quarter. Ask support and you will hear about accounts with a login in the last thirty days. All three definitions are correct inside the department that uses them, all three are wired into that department’s reports and systems, and nobody has ever needed to reconcile them, because until now the only things reading across all three were people, and people reconcile quietly without noticing they are doing it.

An AI system does not reconcile quietly. Connect one to your enterprise data and it inherits every department’s private definitions and the contradictions between them, with no way to know that “customer” in the CRM and “customer” in the billing system are different populations wearing the same word. The confident, wrong answers that follow get filed as hallucinations, and the model takes the blame for a disagreement your organization never resolved.

The problem has a name

The discipline that addresses this is called ontology, and the word is less exotic than it sounds. An ontology is an agreed map of the nouns and verbs of your business: the things that exist (customers, orders, products, facilities), the relationships between them (a customer places an order, an order contains products), and the precise definitions that make those terms mean one thing everywhere.

A useful way to picture the difference it makes: without shared definitions, your departments are like national branches of a company where each office keeps its books in a local dialect. Every office functions internally, and every attempt to consolidate requires a translator who was only ever taught one side of the vocabulary. The ontology is the agreement to keep one set of books in one language, without forcing every office to stop speaking its dialect in the hallway.

This is a working discipline with an established practitioner community. The Knowledge Graph Insights podcast has spent more than fifty episodes interviewing the people who do it inside large organizations, and two themes recur across nearly every conversation. Andreas Blumauer describes the enterprise semantic layer as two connected parts, a human-crafted domain knowledge model that captures the tacit knowledge in the business, and the knowledge graph generated from it. Lulit Tesfaye makes the connection to the current moment directly: the flurry of generative AI experimentation has produced a parade of failed pilots precisely because enterprises lack the semantic context that would put their knowledge assets in a form machines can work with.

Why this is a precondition, not a refinement

Well-defined business semantics are what allow an AI system to distinguish surface-level data points from actual business logic. Without them, the system can retrieve a number but cannot know what the number commits you to, and the errors that result are not random. They cluster exactly where the departmental definitions diverge, which is to say exactly where the business questions are most interesting.

This is why the semantic work sits at the front of the implementation sequence rather than somewhere in the middle. It is also why the work cannot be delegated to the data team alone. Deciding what “order complete” means when fulfillment, revenue recognition, and the customer’s own experience disagree is a business decision with policy consequences, and only people with cross-departmental authority can make it stick. McKinsey’s finding that engaged executive leadership correlates with a 3.8x performance improvement in AI initiatives is often quoted as a sponsorship statistic, but the mechanism runs through exactly this kind of decision.

What the alignment work looks like

The format is unglamorous and effective. Leadership, engineering, and product stakeholders convene, and the early sessions work through the terms that matter most: the ten or twenty nouns that appear in every board deck, and the verbs that connect them. For each term, the group surfaces the existing definitions, decides which one governs, and documents what the losing definitions were, because the systems built on them will need translation rather than deletion.

Three outputs make the meeting real. The first is the shared vocabulary itself, written down with the precision of a contract. The second is a set of named owners, the people accountable for each domain’s definitions going forward, since business units should own their domain data and their subject matter experts recognize the key data points fastest. The third is a change management policy, because the business will evolve and the ontology must evolve with it under governance rather than by drift. A definition that changes silently is worse than one that was never agreed.

None of this requires software to start, which is worth stating plainly in a field that prefers to begin with procurement. The vocabulary eventually becomes machine-readable and feeds the knowledge graph that agents query, a subject I cover in Knowledge Graphs Explained, and the full architecture that consumes it is described in Intelligent Business: A Modular Approach to AI Integration. But the artifact that everything downstream depends on is an agreement between people.

Start with one term. Take the noun your executives use most often in disagreement, put every department’s definition of it on one page, and watch the room discover that the disagreement was never about strategy. It was about language, and language is fixable.