The semantic layer nobody owns

Ask three people on your data team what an "active user" is and you will get three answers. Ask three tools, the dashboard, the growth model, the AI assistant someone stood up last month, and you will get three different numbers, all confidently labeled "active users." That gap is not a definition problem. It is a layer problem.

Between the transformation layer that produces your tables and the reporting layer that displays them, there is supposed to be a place where the definitions live. One place. Active user gets defined once, every downstream tool inherits it, and nobody argues about which number is right because there is only one number to have. In most stacks that place does not exist, and no one has been given the job of making it exist.

What the semantic layer actually is

The semantic layer sits between dbt and everything that reads from it. Its job is to hold the metric definitions and the dimensions they can be sliced by, and to hand out a canonical query when anything downstream, a dashboard, a notebook, an AI assistant, asks for a number.

Concretely: revenue is defined once as sum of order_total where status is confirmed and refunded_at is null. Active user is defined once. So is churn, MRR, gross margin, whatever your business runs on. The definition includes which dimensions are valid to group by and which joins are allowed. Downstream tools do not write their own SQL against the raw tables. They query the definition.

LookML was an early version of this idea inside Looker. dbt has semantic models and metrics now. Cube, MetricFlow, and a few others sell it as a product. What they have in common is that the metric is expressed once, in code, in a place a person can read and edit, and every consumer of that metric goes through the same door.

That is what the layer is. What it is not: a data catalog, another dashboard, or a documentation site. Those describe metrics. A semantic layer computes them.

Why nobody owns it

The layer falls into a gap between three teams and rarely lands on any of them.

Data engineering owns ingestion and raw storage. Their answer is that shaping business logic is not their job. Analytics engineering owns the transformation layer. Their answer is that the metric lives in the BI tool, downstream of the models they build. The BI or reporting team owns the dashboards. Their answer is that the metric is upstream, in the SQL that populates the visualization.

Between the three, the metric definition ends up copy-pasted into individual dashboard queries. Same field, five slightly different implementations, no one point of truth. When someone asks who owns the definition of revenue, everyone points at someone else.

This is not a hiring problem. Adding a headcount to any of the three teams does not fix it, because the layer is not naturally in any of their scopes. Someone has to be given the job explicitly, with authority to say no to a dashboard that computes its own version of a shared metric. That role does not exist at most companies.

What "no semantic layer" looks like in practice

On the agency side I ran into this weekly. Three account leads on the same brand, three versions of "media spend" for the same month. One included agency fees, one did not. One was in reported currency, one was normalized to USD. All three were labeled "media spend" in their respective dashboards, and all three were correct against whatever query produced them. What was missing was a definition of media spend that any of them could point to and say, that is the number.

The fire drill fix is to reconcile the three dashboards, pick a winner, and align the others to it. That works for one meeting. It does not survive the next metric someone adds, because the process that produced the drift is still the process the team uses. New dashboard, new SQL, new definition of whatever field it needs, slightly different from the last one.

The real fix is the layer. Move the definition of media spend into a semantic model, point all three dashboards at it, and the next dashboard that gets built inherits the same definition. The drift stops at the point of creation instead of getting rediscovered in a meeting six months later.

Why AI makes this worse

A dashboard shows one number at a time. When two dashboards disagree, a person notices, chases the discrepancy, escalates. The disagreement is visible and slow, and the human loop eventually catches it.

An AI answering questions across the warehouse does not work like that. It picks a table, runs a query, returns an answer in a paragraph. If two tables have revenue defined differently, the model does not flag the ambiguity. It picks the one it found first, and the answer arrives as one clean sentence that reads like it was pulled from a single trusted source.

I covered a version of this in the hygiene post: AI systems absorb inconsistency instead of surfacing it. The semantic layer version is the same failure at a different altitude. The dashboard problem was three visible numbers in three tabs. The AI problem is one confident paragraph with no way for the reader to know that three definitions were in play.

The teams that put an AI in front of a warehouse without a semantic layer typically get a good demo, a rough first month, and a slow decline in trust as reconciliation problems accumulate. Not a crash. A drift.

What to do this week

You do not have to buy a product to start. The first version can be a documented mart and a rule about who is allowed to change it.

List the top ten metrics your business actually asks about. Revenue, active users, churn, whatever it is. If you cannot get to ten, list five. This is the surface area that matters.

For each one, name the owner. Not the team. The person. If the answer is "the dashboard" or "whoever built it," that is your first gap.

Pick one metric and grep for every place it is computed. Every dashboard query, every notebook, every dbt model that produces a version of it. Read them side by side. The differences are where the disagreement lives.

Write the canonical version once. In a dbt semantic model, a metrics YAML, or a plain documented mart with a fixed definition. Include which dimensions are valid to slice by. This is the definition of record from now on.

Point one downstream tool at it. Not all of them at once. One dashboard, migrated to the canonical version, with the old query deleted. Prove the pattern works before you scale it.

Publish the rule. When someone spins up a new dashboard, the answer to "where does revenue come from" is a link to the semantic model, not "ask the person who built the last one." Without the rule, the layer erodes as fast as you build it.

You do not need to buy a semantic layer product. You need someone whose job is to own the definitions. The product is the easy part.