Data Does Not Speak the Same Language: The Problem of Enterprise Semantics

Integrating five systems that store the same facts under four different names is not an ETL problem. It is a comprehension problem. And AI agents inherit it as is.

Introduction

Yesterday we defined the jump from data to knowledge. Today we attack the first wall that blocks it: a company’s systems do not understand each other. Not because they come from different vendors or speak incompatible formats —that is the easy half— but because they do not share an agreed meaning for the things they name.

That wall has a name, and it is one of the oldest in data engineering: semantics.

The problem

The classic example, and the one we will find in almost any company that tries to deploy an agent over its systems, has this shape:

Four systems, four vocabularies, and a trap: the names do not only differ, they overlap. “Customer” in the CRM and “account” in the ERP are sometimes the same thing, sometimes different things (in the ERP, “account” can be a financial account; in the CRM, an organization). And “party” in the legacy system can be a customer, a supplier, an employee, or a tax contributor, depending on the table.

Now imagine an AI agent that receives this question: “How much does our largest customer owe us?”. The agent has access to the four systems. It can count customers in the CRM, accounts in the ERP, clients in billing, and parties in the legacy. Which one is the “largest customer”? Measured by billing (ERP), by open opportunities (CRM), or by outstanding balance (billing)? And “customer”: does it include those that are also suppliers? And the master accounts with sub-accounts?

The agent is not going to solve this. Not because it is dumb, but because the ambiguity is not in the question: it is in the company. And the company has not resolved it yet, because until now each system operated in its silo and no one needed a common meaning.

The point worth fixing: the problem is not one of technical integration. Connecting the four systems, moving the data, and normalizing the formats is engineering work, and it gets done. What cannot be done with engineering is deciding what each thing means, and that decision is semantic, it is a business one, and it is the one the agents need before they can do anything.

The concept

Semantics is the discipline of meaning. In the enterprise context, it deals with:

• Meaning. What each term represents in each context.
• Vocabularies and terminology. The names the organization uses and their equivalences.
• Concepts. The things the organization distinguishes (a “customer” is not the same thing as a “supplier,” even though both are “parties”).
• Taxonomies. Hierarchies of concepts: a “product” can be a “component,” which can be a “spare part.” A taxonomy organizes concepts into trees.
• Common semantics. The set of agreements about what the concepts mean and how they relate, shared by all the systems and, increasingly, by the agents.
• Semantic integration. The process of getting several systems to express the same facts with compatible meanings.

Semantic integration is not field mapping. Field mapping (customer.id → account.id) is a treated symptom: it resolves the name match in a concrete case. Semantic integration is deciding which concepts exist in the company, what each one means, and how they correspond across systems, so that any new system —including any agent— can join in without reinventing the interpretation.

A useful analogy: a data lake without common semantics is like a hospital where each department writes the medical records with its own nomenclature. You can pile all the folders into a cabinet (technical integration), but if “HTN” means one thing in cardiology and another in surgery, no one —human or machine— can read the whole.

Architecture

In the series diagram, semantics is the first layer above the data:

                KNOWLEDGE
                     ↑
                 SEMANTICS      ← today: meaning, vocabularies, taxonomies
                     ↑
                   DATA
                     ↑
           ENTERPRISE SYSTEMS

Semantics is the border between “data that exist” and “data that mean something.” Without it, the knowledge layer cannot be built, because knowledge is made of concepts and relations, and concepts need meaning.

There is a practical gradation that is worth recognizing, because companies do not arrive at perfect semantics all at once:

1. Glossary. A document with the key terms and their definitions. Useful, but not executable: an LLM can read it, but it cannot reason about it reliably.
2. Controlled vocabulary / taxonomy. List of accepted terms with hierarchies. Better: it allows consistent mappings.
3. Semantic model (lightweight ontology). Concepts, relations, and constraints expressed in a way a system can verify. This is where semantics stops being documentation and becomes infrastructure.

Level 3 is what we will reach in two days (ontologies). For now, the idea is that semantics is a spectrum: it is not all-or-nothing, and companies move along it by degrees, starting with the concepts their agents need first.

Use case

A retailer with four systems (the ones in the table). We break it down:

1. Problem. The sales director asks his AI assistant “What is the situation of our largest customer?” and receives three different answers in three days, depending on which system the agent consulted first. No one trusts the assistant anymore.
2. Decision. The director needs a single figure for “largest customer” to prepare the board meeting.
3. Necessary knowledge. What is considered a “customer” (does it include distributors? online customers?); how “largest” is measured (revenue, margin, average ticket); how master accounts and sub-accounts are consolidated.
4. Data. customer, account, client, party in four systems, with different IDs, duplicates, and master accounts.
5. Relations. Master account → sub-accounts; customer → orders; order → lines; customer → also supplier (in some cases).
6. Context. The question is for the board (it needs a consolidated figure), not for day-to-day operations (where the ERP datum would suffice).
7. Memory. The last time this consolidation was done was by hand, by an analyst, and it took two weeks. The method is in an Excel.
8. Reasoning. Apply the definition of “customer” and of “largest,” consolidate sub-accounts, exclude or include distributors according to the rule.
9. Action. Return the figure with the applied definition, so the director can defend it.
10. Infrastructure. For the agent to give always the same correct answer, it needs common semantics: what a customer is, how accounts are consolidated, and an explicit rule for “largest.” Without that, every query is a roulette of systems.

What the retailer is solving is not a problem of more data: it has more than enough. It is a problem of meaning: the word “customer” has to mean the same thing to the director, to the analyst, and to the agent.

Trade-offs

• Cost. Defining common semantics requires involving the business owners of each system, not just the data team. It is expensive in the time of people who are not available.
• Complexity. Edge cases (is a distributor a customer?) are not solved with a definition: they require explicit decisions that the organization postpones because nothing forces it to make them.
• Maintenance. Semantics drifts. The CRM is renamed, the ERP migrates, a new concept appears (a “partner”?). The common vocabulary has to be updated or it breaks down.
• Adoption. If the sales team keeps using “customer” and the finance team “account,” the common semantics is a map no one uses. It needs the agents and the dashboards to actually consume it.
• Honest limitation: common semantics does not eliminate the ambiguity of the real world; it explains it. Sometimes “largest customer” really depends on the context, and what the infrastructure does is leave the user free to choose the definition, not invent a single answer.

Implication for the business

For the CDO, semantics is the first asset of the cognitive infrastructure and the most underestimated: it is not a data project, it is a project of agreements. And agreements require an owner.

For the AI team, the lesson is operational: before training or fine-tuning an agent over these systems, you have to sit down with the business owners and agree on the list of concepts the agent will handle and their agreed meaning. That meeting, uncomfortable and boring, is the one that separates an agent that gives consistent answers from one that gives three different ones.

For the executive team, the message is the same as yesterday’s, refined: the gap between “we have the data” and “our agents understand the company” starts at the meaning, and meaning is a business decision, not a technical configuration.

Conclusion

Semantics is the first layer of the cognitive infrastructure: it turns data into things that mean something. A glossary is the minimum viable; a formal semantic model is the destination. And in between, the question we will answer tomorrow: how do we go from a document with definitions to a representation a machine can verify?

Next article

Tomorrow: What does an ontology bring to enterprise artificial intelligence. We will see why a taxonomy is not enough, what an ontology really is, and how an ontology is the difference between a glossary a human reads and a representation an agent reasons about.

Sources

• Working definition of the ECI: see the series, Day 1.
• The distinction between technical and semantic integration is standard in the literature of data integration and the semantic web (W3C); it is presented here in operational terms.