The Meaning Gap

You bought the catalog. You documented the columns. You mapped the lineage. And you still can’t get two teams to agree on what “active” means — because none of those tools were ever designed to capture meaning.

Say you did everything right.

You bought the data catalog. Someone spent a quarter populating it. Every column has a description. Lineage is mapped end to end — you can trace revenue from the source system through four transformations to the executive dashboard. Your data quality tests are green. Your pipeline hasn't broken in months.

And this morning, three teams gave three different answers to “how many active customers do we have?”

Nothing failed. That’s the uncomfortable part. Every tool did exactly what it was built to do. The gap they left open is one none of them were ever designed to close.

What a catalog actually knows

Your catalog knows a great deal about customer_status. It knows it's a string. It knows it's nullable, that it has four distinct values, that it's populated 99.2% of the time, that it's produced by a dbt model owned by the platform team, and consumed by fourteen downstream dashboards.

That is a genuinely impressive amount of knowledge. It is also, in the way that matters, nothing.

Because it does not tell you what the business means by an active customer. It doesn’t tell you that “active” means a login in the last thirty days — except trial accounts, except internal test users, except the handful of enterprise contracts that bill annually and would otherwise look dead for eleven months of the year.

A catalog describes the container. It doesn’t capture the decision.

That distance — between what your data records and what your business intends — is what I’ve started calling the Meaning Gap. And no volume of metadata closes it, because metadata was never built to.

Meaning is a decision, not a description

Here’s the thing I think most of the industry has quietly got backwards.

We treat meaning as though it were a property of the data — something latent in the columns, waiting to be discovered by a sufficiently good profiling tool. Point enough statistics at a table, the thinking goes, and its meaning will emerge.

It won’t. Because “active” is not a property of the data. It’s a choice.

Thirty days rather than sixty: a choice. Excluding trials: a choice, made because someone in a meeting argued that counting them flattered the number. Including the annual-billing enterprise accounts: a choice, made after a bad quarter where excluding them made retention look like a crisis that wasn’t happening.

Every one of those exceptions encodes a judgment a human made, for a reason, at a moment in time. You can compute a column’s cardinality. You cannot compute why finance decided to exclude trials. That reasoning was never in the data. It was in the room.

Meaning is negotiated, not observed. And we have built an enormous amount of infrastructure for observing, and almost none for capturing the negotiation.

Semantic Debt

We all understand technical debt. You ship the shortcut because the deadline is real, and you pay for it later, with interest. It’s in the backlog. It has a name. Engineers can point at it and argue for time to fix it.

There’s a quieter version that nobody budgets for.

Every time someone works out what a metric means — in their head, in a query, in a spreadsheet, in a Slack thread — and doesn’t capture it anywhere reusable, the organization takes on Semantic Debt.

You don’t repay semantic debt in refactoring. You repay it in meetings where two people are both technically right and neither can prove it. In dashboards that disagree and a week spent working out which one is wrong. In the board number that someone is quietly reconciling at eleven o’clock the night before.

Technical debt slows your engineers down. Semantic debt slows your decisions down. Only one of them ever makes it into a sprint.

And it compounds, in the specific way debt does. Every team that can’t find an existing definition writes a new one. That new definition becomes another thing the next person can’t reconcile with, so they write a third. The interest payment isn’t a cost you notice once — it’s the slow, permanent tax of a company that can no longer agree with itself.

Why this is getting worse, not better

You could survive a large Meaning Gap for a long time. Humans in the loop patched it. The senior analyst knew which number was the real one. It was expensive and fragile, and it worked.

Two things are ending that.

The first is surface area. Every new tool you add is another place meaning can be silently re-derived — another notebook, another dashboard, another pipeline, another semantic model, another agent. Each one is perfectly capable of inventing its own private version of “revenue” and being internally consistent about it. The stack has gotten very good at producing confident, mutually contradictory answers.

The second is AI. Point a language model at your warehouse and ask it a business question, and it will answer. It will produce a definition of “active customer” that no human in your company ever approved — not because it’s lying, but because you never told it. It inferred meaning from structure, which is exactly the thing that cannot be done. The model isn’t hallucinating your data. It’s hallucinating the meaning you never wrote down.

Uncaptured meaning used to be a slow leak. Automation turns it into a pump.

So what would actually close it

Not more metadata. We have plenty of metadata.

A metrics layer helps — it at least gives a metric a name and one place to live, and that’s real progress. But naming a metric is not the same as capturing the reasoning behind it. A definition without its exceptions and its why is just a shorter argument waiting to happen.

What has to change is the status of meaning itself. Right now, business meaning is a byproduct — something that happens in people’s heads on the way to building something else, and evaporates afterward. It has to become an artifact: written down once, with its exceptions and its reasoning intact, versioned, owned, and reusable by everything downstream — every dashboard, every query, every model, every agent.

We did this for code. We did it for data. We have somehow never done it for the thing that makes either of them mean anything.

Your catalog documents everything about your data. It explains nothing about your business. Until that changes, every tool you add just gives the disagreement somewhere new to hide.

Questions I’m still thinking about:

• Can the reasoning behind a definition — the exceptions, the “why we excluded trials” — actually be captured in a structured form, or does it inevitably decay into prose nobody reads?
• If semantic debt compounds like technical debt, what’s the equivalent of a refactor? Is there a way to pay it down, or only to stop accruing it?
• What would it take for a business definition to be testable — for a company to know its meaning is wrong before the board deck does?

I’d love to hear how others are approaching these problems.