You Already Have Semantic Layers. That's the Problem.
On the semantic decisions your organization has already made without knowing it
I once sat in a meeting where the only goal was to answer a simple question: how many cars did we sell? That should be child’s play.
It didn’t stay simple for long. Someone said a car was sold when the auctioneer’s hammer fell. Someone else said no, it’s sold when finance books the transaction. A third person argued it’s sold when the buyer pays. A fourth said the seller being paid is what makes it real. And then someone asked about returns: if a car came back for a mechanical issue the following week, was it still sold?
Every one of those answers was correct. Not approximately correct, or correct from a certain angle. Correct in a way that mattered to the person giving it, because each one reflected a different business process, a different accountability, a different moment when something real and consequential happened. The auctioneer’s answer served the auction floor. Finance’s answer served the ledger. The seller’s answer served the settlement process. None of them were wrong. None of them were the same.
That meeting is why a company president can pull three reports on the same question and get three different numbers. Not because the data is bad. Because the question “how many cars were sold” has multiple valid answers, each encoded in a different system by people who understood exactly what they were measuring. The reports disagree because the definitions disagree. And the definitions disagree because the businesses they serve are genuinely different.
That’s the moment the unified semantic layer conversation either gets stuck or gets honest.
Every dashboard is already a semantic layer
What usually gets missed in that conversation: the semantic layer already exists. It’s just not where anyone is looking for it.
Every analyst who built a dashboard made a semantic decision. The metric called “30-day active users” in your product analytics tool has a specific calculation behind it. Someone decided what counts as active, what the window is, and whether to deduplicate. That decision is encoded in the tool. It’s just not written down in any format a machine can find or an agent can consume.
The same is true for every calculated field in every reporting tool across the organization. Finance’s revenue definition is embedded in their model. The product team’s engagement metric is embedded in Amplitude or Mixpanel or whatever they shipped last year. Operations has a cost-per-unit definition living inside a spreadsheet someone built in 2021 and has maintained ever since.
None of these are absent of governance. They all reflect deliberate decisions made by people who understood the business problem. The problem is that those decisions are invisible to anything outside the tool that contains them. When an AI agent asks a question that touches multiple domains, it has no way to know which definition to use, whether two definitions that sound the same are actually compatible, or whether the number it just calculated is the same number the analyst calculated last Tuesday.
The recalculation trap
When an agent is asked a question, the easiest path is often to reach back to the raw data and compute an answer. Pull the records, apply some logic, return a number. The problem is that the number it returns isn’t the same number the business uses, because the definition embedded in the raw calculation isn’t the same definition someone carefully encoded in the reporting layer.
Two answers. Both confident. Neither flagged as conflicting. The agent didn’t make an error by any technical measure. It made a governance error that’s invisible until someone compares the outputs and wonders why they don’t match.
The cost problem compounds this. As LLM tools shift from flat-rate to consumption pricing, every query has a real and visible price. Your organization already paid to generate the trusted answer once, when an analyst built the dashboard, chose the definition, and validated the output. That cost is sunk. Every time an agent recomputes the same answer from raw data, you pay again in query compute and LLM tokens. And you get a different number. You are paying more to be less trustworthy.
What actually erodes confidence over time is the version problem. If your organization has a trusted dashboard that answers a specific question, and an agent answers the same question differently, you now have two sources of truth competing silently. Not with a dramatic failure. With a slow accumulation of “the numbers don’t quite add up” moments that nobody can explain, each one costing money to generate.
The answer isn’t better agents. The answer is telling the agent which definition to use and where that definition already lives. You already paid for that answer. Use it.
Why federation is the only realistic path
Once you accept that semantic decisions are already distributed across the organization, the architectural question changes. It’s no longer “where do we build the one semantic layer?” It’s “how do we make the semantic layers we already have discoverable, registered, and usable by machines?”
Before accepting that, most organizations try the alternative: force new names for contested terms and build a single clean layer around the new vocabulary. If “cars sold” means five different things, stop using “cars sold.” Call them “booked transactions” and “auction settlements” and “funded deals” and define each one precisely. One layer. No ambiguity. Problem solved.
This works. Under the right conditions. We did it with cars sold in a narrow context, with a small team, with enough authority to hold the line on the new terminology. The definitions were precise and the layer stayed clean. The conditions that made it work were real.
The problem is that those conditions don’t scale. As scope expands across more business units and more teams, two things happen. The definitions become increasingly academic, engineered for logical consistency rather than for how people actually think about their work. And the change management cost compounds. Moving people off of words they use every day, words that accurately describe something real in their business context, requires sustained organizational will that is almost never justified relative to the governance benefit. Teams agree in the meeting and revert in practice. The new term lives in the data dictionary. The old term lives in every conversation, every report request, every Slack message where someone asks why the numbers don’t match.
Forced renaming solves a vocabulary problem by creating a translation problem. The underlying semantic difference doesn’t go away. It just gets a layer of terminology on top of it that everyone has to manage in addition to the disagreement itself.
Federation isn’t a compromise position. It’s the accurate description of how knowledge actually works at enterprise scale. Different business units operate with legitimately different definitions because they run legitimately different businesses. A metric used for executive reporting has different requirements than one used for operational alerting. Trying to collapse all of that into a single layer doesn’t unify the organization. It either produces a layer so generic it can’t answer real questions, or it produces a political conflict between teams that each believe their definition is the correct one, with no mechanism to resolve it.
What federation requires is not three parallel things. It’s three things that build on each other.
It starts with local ownership. Whatever tool a team is working in, the semantic decisions they’ve already made get documented and registered in a shared format. Not moved. Not consolidated. Just made visible and machine-readable. This is where the work begins because this is where the definitions actually live.
Local ownership is why a registry becomes necessary. Once definitions exist in multiple places with multiple owners, something has to answer the routing question: for this type of query, from this type of consumer, in this business context, use this layer. That routing logic is where the organizational governance actually lives. Not in the definitions themselves, which belong to the domain owners, but in the rules about which definition applies when. Without the registry, local ownership just produces a more organized version of the same invisible landscape.
And the registry is why identity becomes the constraint. Routing rules that depend on business context need to know which context the consumer belongs to. An agent acting on behalf of a product analyst should get that team’s definitions. An agent acting on behalf of finance should get theirs. Identity is what connects the consumer to the right layer. Most organizations haven’t wired it that way, which is why the identity section below matters. But the dependency only becomes visible once the registry exists to expose it.
The two types of semantic layers, and why they both need to exist
Once you accept that federation is the right model, a second distinction surfaces that most organizations try to avoid making explicit. Not all semantic layers are doing the same job, and confusing the two is where a lot of federation efforts stall.
The business domain problem is about meaning. Two teams use the same word to describe genuinely different business realities. Cars sold means something different to the auction floor than it does to finance. Both definitions are correct. Neither is interchangeable with the other. The federation argument addresses this directly: local teams own their definitions, the registry routes consumers to the right one.
The canonical layer problem is different. It’s not about meaning. It’s about identity and structure. Two teams that have perfectly clear definitions within their own domains try to connect their data across a boundary, and the connection fails because the underlying entity isn’t the same object in both systems.
Consider the word “dealership.” One business might define a dealership as the physical location where customers are sent. Another defines it as the legal business entity that signs contracts. A third defines it as the website domain that hosts the inventory. None of these is wrong. Each accurately reflects how that business actually thinks about and interacts with dealers. But when you try to join customer data from the first system to transaction data from the second, nothing resolves cleanly. You’re joining on a physical address against a legal entity. The grain is different. The meaning is different at the structural level, not just the semantic one.
This is what the canonical layer exists to solve. Not to adjudicate which definition of dealership is correct, but to establish a shared object definition stable enough that data from different systems can connect through it. Without it, every cross-domain join requires custom translation logic, and every new integration starts from scratch.
These are not competing approaches. They serve different consumers with different needs and fail in different ways when they’re missing. A missing business layer produces the cars sold problem: agents and analysts getting different numbers depending on which system they query. A missing canonical layer produces the dealership problem: cross-domain joins that silently return wrong results or fail to resolve at all.
If you force business teams to inherit from the canonical layer, you get definitions too generic to answer real questions. If you force canonical definitions to accommodate every business team’s precision needs, you get definitions so qualified they stop serving interoperability. The governance work is not choosing between them. It’s defining the contract between them. Canonical layers publish shared structural models. Business layers publish their local definitions plus an explicit mapping to the canonical terms when they expose data outside their context. The registry holds both, with routing rules that tell a consumer or agent which layer applies given their question and context.
Expect overlaps, and don’t try to eliminate them
Most rationalization efforts go wrong here. When you inventory the semantic decisions that already exist in your tools, you will find what looks like duplication. Two teams using the same term with different calculations. Two business domains each defining the same entity. The instinct is to ask which one is right and eliminate the other.
Usually both are right, and eliminating either destroys something.
Two business teams using the same term with different logic are almost certainly answering different questions for different consumers. A product analytics team measuring engagement and a finance team measuring billable activity built their respective definitions because they needed precision for different purposes. Forcing a single definition doesn’t resolve the difference. It produces a definition neither team can actually use, and both will quietly work around it.
The same thing happens at the canonical layer. A definition of a customer entity that serves CRM workflows and one that serves transaction settlement can overlap the same underlying record while encoding different consistency requirements. That overlap is expected. The two definitions are not duplicates. They represent different contracts for different downstream uses.
The registry’s job is not to enforce uniqueness. It is to make the landscape legible. A well-designed registry doesn’t tell you there should be one definition of “active customer.” It tells you there are three, who owns each one, what question each one answers, and which one an agent or analyst should reach for given their context. Reducing the number of definitions is the wrong goal. Reducing the number of undocumented definitions is the right one.
The practical starting point
Most organizations don’t need to build anything new to start. They need to do an audit of what semantic decisions already exist in their tools.
What metrics are defined in your analytics platforms? What calculated fields have formal definitions versus informal ones? Where do two teams use the same term with different underlying logic? Where does an agent recalculating from raw data produce a different answer than your trusted reports?
As you build that inventory, classify what you find by type. Is this a canonical definition meant to serve interoperability, or a business definition meant to serve a specific team’s questions? That classification determines where it belongs in the registry and what contract it needs to publish. Without it, you’ll spend time trying to reconcile things that were never meant to be reconciled.
That inventory is the input to the registry. It tells you what needs to be registered before you design any new infrastructure. It also usually surfaces the conflicts that matter most, the ones where two teams believe they have the authoritative definition and neither knows the other exists.
A registry entry doesn’t need to be complicated. For “cars sold,” it might list five versions: auction settlement, booked transaction, buyer payment, seller payment, and net of returns. Each entry names the owner, the business context it applies to, the tool where the definition lives, and a routing rule stating which version an agent should use given the consumer’s context. That’s the whole thing. Not a schema. Not a data dictionary. A legible record of which answer is authoritative for which question, maintained by the people who own the answer.
The governance work here is less about building and more about surfacing. Most of what you need is already written down. It’s just written down in a format only the tool can read.
The dependency you’ll find next
Once the registry exists and the routing rules are in place, the next problem surfaces quickly. The routing rules depend on knowing who is asking. An agent acting on behalf of a product analyst should get that team’s business definitions. An agent acting on behalf of a finance team should get theirs. An agent operating across business units needs to resolve which context applies before it can route to the right layer.
Most organizations will discover, at that moment, that they don’t have a consistent answer to the identity question across their business units. Not because nobody thought about it, but because identity systems were built per-division, per-product, per-tool, and were never designed to interoperate at the semantic layer. Each business unit knows who its users are. The governance layer trying to route a query often doesn’t.
This is not a reason to delay the registry work. The audit, the classification, the registry design are all correct steps and none of them depend on solving identity first. But name the dependency early. The organizations that will stumble are the ones that build the routing logic, go to wire it to identity, and discover the gap then. The ones that name it upfront can sequence the work deliberately rather than hitting it as a surprise.
The routing rules work once you know who is asking. Building the registry is how you find out exactly how much that question matters.
None of this resolves the underlying complexity. The cars sold question still has five valid answers. What changes is that the five answers are documented, owned, and routable rather than silently competing inside systems that don’t know the others exist.
The previous two posts covered the same underlying problem in adjacent territory. The first argued that AI readiness for unstructured data isn’t a curation problem, it’s an epistemic governance problem. The second argued that data governance programs fail when they start with policies instead of business problems. This post is the third part of the same argument. In every case, the problem isn’t that organizations lack information. It’s that the information they have isn’t visible to the systems consuming it.
A semantic layer you can’t find is not a semantic layer. It’s a decision waiting to create a conflict.
The work is to surface it, register it, and route to it. Not to replace it with something central that pretends the organizational complexity underneath it doesn’t exist.
Further reading
The conceptual foundation for why terms can’t be forced into a single definition across different business contexts is Eric Evans’ notion of bounded contexts, introduced in Domain-Driven Design (2003). Martin Fowler’s summary is a good starting point: martinfowler.com/bliki/BoundedContext.html
Zhamak Dehghani’s original data mesh piece is worth reading in full if the source-aligned versus consumer-aligned distinction resonates: martinfowler.com/articles/data-mesh-principles.html
The closest working implementation of the federated pattern in practice is dbt’s combination of Mesh (domain-owned data products in separate projects) and the Semantic Layer (centralized metric definitions that cross-reference those projects). Their documentation on how these work together is worth reading if you’re thinking about tooling: docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl