The Semantic Layer Was Correct Once

Intelligence got cheap. A capable model is a line item and an API key, and it will reason about almost anything you put in front of it. What it cannot do is know that Finance excludes refunds from Net Revenue while the Sales dashboard includes them, unless something tells it. So the scarce thing is no longer intelligence. It is business context: the definitions, the relationships between them, and the meaning behind both, in a form a machine can use.

That is what a semantic layer is for, and it is why every serious team building on their own data is racing to construct one. Surveying the first wave of enterprise data agents, a16z concluded they were essentially useless without the right context: the meaning that answers a real question tends to be tribal knowledge, or a definition last touched by someone who left a year ago.

So teams write the context down. Here is what they learn second. It starts rotting the day they finish.

The semantic layer is the fix everyone reaches for

Document the definitions. Fill in the catalog. Ship a semantic layer, bless it once, and declare it solved. It is correct on the day it ships. Then the business moves.

Here is what most people get backwards: it is not the schema that rots. Schema drift is the easy part. A column gets renamed, a table moves, and you can re-crawl the warehouse to catch it. What rots is the meaning. When we say revenue we mean this now, not that. This segment folds into that one. This table is canonical for that question, not the one beside it that looks the same. That layer of convention on top of the schema is where the real work lives, and it is the hardest thing to keep fresh. We have watched it happen in our own system and in warehouses we have mapped.

The failure is quiet, which is what makes it dangerous. DataHub documents the scale at Pinterest: 400,000 ungoverned tables, 500 more every day, and the knowledge to use them stuck in people's heads. Picture what that does to an agent. A business user asks for last quarter's net revenue. It answers off the gross revenue table, on a deprecated definition, three weeks stale, and nothing flags it, because the context feeding it does not know either. The number comes back looking exactly as trustworthy as a right one. That is how a wrong number ships without a sound.

And it decays on a schedule. Anthropic's own data team watched their agent's accuracy drift from about 95 percent at launch to about 65 percent over a single month, because the docs described a data model that changed daily and nobody was maintaining them. Preset called the same thing a menu describing dishes the kitchen no longer made. The warehouse evolves, the layer does not, and the gap between them stays invisible until someone orders.

The reason nobody keeps it fresh is not carelessness. It is that keeping it true is a full-time job assigned to no one. In a Reddit thread on running data agents in production, a commenter who had shipped three of these systems named the failure exactly: "whoever owns the semantic layer becomes the bottleneck and they usually have three other jobs." The catalog and governance vendors are moving to own this, and that work is real and necessary. But a catalog describes your tables, and the meaning that rots is not in your tables. It is made in meetings.

The real problem is a missing loop

Ask why the meaning drifts and you reach the thing no catalog fixes. The feedback loop is missing.

Think about where a decision actually happens. A number looks off. A few people meet. They argue, they decide something, and the decision changes what a metric means. We count trials differently now. We are retiring this definition. Then everyone goes back to work. The decision, and the change it just made to the meaning of the data, lives in a meeting, a Slack thread, someone's memory. It never returns to the system that holds the data.

Your data stack is very good at recording what happened. It records almost nothing about why anyone decided anything, or what that decision changed about what the numbers mean. The context that would keep the semantic layer true is generated constantly, in every decision the company makes, and then it evaporates. This is the data-driven lie one layer down: not just disagreeing about the numbers, but having no system that learns when the meaning behind them moves.

What the internet gets right, and where it stops

One system already solved a version of this, and it is worth studying for where it wins and where it fails.

The web stays roughly current about a world that never stops changing, and nobody is assigned to keep it that way. It is upstream of the work: you go through it to know anything. It is updated by the work itself, so a company's page gets edited within hours of the news with nobody handed the task. Ownership is distributed, whoever knows a thing tends their own corner, and it is crawled continuously, so staleness gets found on its own, the same way a map of your warehouse would re-crawl to catch a renamed table.

A company wiki has none of this, which is why it rots. It sits downstream of the work, a place you copy things into afterward, when you remember. A static semantic layer is a wiki with better syntax, and it rots for the same reason: it is a record you maintain on the side, not the record the work runs through.

But the web teaches the opposite lesson in the same breath, and this is the part every "point AI at your data" pitch skips. The web is alive and unreliable. Approximately right is a triumph when you are finding a restaurant and a catastrophe when you are in a board meeting. Point a model straight at your warehouse and you get exactly that: the liveness, and none of the guarantees. The number might be right, and you have no way to know, on the one answer about to go in the deck.

The system of record has to be the system of work

So the two obvious options fail in mirror images. The written-down semantic layer is correct and dead. The warehouse-pointed model is alive and untrustworthy. Choosing between them is the wrong move.

The way out is a single principle, and software already learned it once. The record that stays true is the one you cannot route around. Git did not win because teams got disciplined about writing changelogs. It won because the history is a byproduct of committing, which you do to save your work. The system of record was the system of work, so it was current for free. Business context needs the same shape. Not a document that someone maintains, but a map the work runs through, so keeping it true stops being a separate job.

That splits cleanly along the line we already drew.

Structure is safe to automate. Cartographer, the scanner that maps the warehouse, re-crawls it and keeps up with the schema on its own. Meaning is not safe to automate, because a machine that rewrites a definition on its own is just confidently wrong at scale. So meaning is governed. A human blesses a definition before it goes live, and when the system cannot anchor a number to a blessed definition, it refuses out loud instead of returning a guess dressed as the answer. Alive where liveness is safe. Governed where it is dangerous.

And it is owned the way the web is owned, not the way the wiki is. Every domain holds its own branch. Marketing owns the marketing branch. A new product line opens a new branch with its own owner. The people who know a definition are the people who keep it, so no single owner is the bottleneck the whole company waits on.

The hard case is the definition that crosses domains. Churn means one thing to Product, the account that went quiet and stopped logging in, another to Finance, the contract that formally lapsed, another to GTM, the renewal that was lost. Three teams, three definitions, and every board number that says "churn" is quietly averaging them. That one cannot be federated, because a company cannot run on three churns. It gets a single canonical meaning, governed at the trunk. The branches cover everything, the shared definitions stay singular, and that is what MECE means when it is load-bearing instead of a slide.

We call ours the Living Map, and the structure underneath it is a Decision Context Graph.

Be precise about what closes the loop today, because the honest version is the whole point. What ships right now is a workflow, not an autonomous memory. A human blesses a definition before it goes live. People pin the metrics that matter and correct the ones that are wrong, and those corrections persist and stay visible, so the next person inherits them instead of relearning them. That is the loop working at the speed of a team paying attention. A system that watches every meeting and rewrites its own meaning is where this is going, not what we claim today. We would rather ship the workflow that is real than promise the memory that is not, because the whole value of the thing is that you can trust it.

Context management becomes a discipline

Git did not just keep the record current. It turned managing that record into a discipline. The question stopped being "is the code done" and became "is the history intact, can we see who changed what and why, can we roll back." The code was never the whole asset. The trail of decisions around it was.

Business context is about to cross the same line. Not "is the semantic layer written" but "is it still true, who changed this definition and why, can we see when it moved." The alternative is what we have today: definitions that drift, decisions that evaporate, and dashboards that lie in a clean font.

So the question was never whether your context is complete. It never will be, and completeness was always the wrong test. What matters is direction: is your context getting truer next month, or staler? A document gets staler by default. A map the work runs through, owned by the people who hold the meaning, gets truer. So there is really only one thing to ask about your own stack: when the business changes, does the meaning get back into the system?