The Product Was Never the Data

There’s a tile on a dashboard somewhere in your company called Revenue. Three people look at it this morning.

Finance knows it’s net of refunds. The sales lead knows the Q1 number has a dip that isn’t real, because that’s when the billing system moved. The analyst who built it knows the region field got renamed in March and the old values are still in there. Same tile. Three readings. All of them mostly right.

None of that knowledge is on the dashboard. It’s in the people.

That knowledge is the product. It always was. The tile is just where we put it down.

We gave it away

When Zhamak Dehghani wrote the data mesh post in 2019, “self-describing semantics and syntax” was one of the six qualities a data product had to have. Right there on the list, next to discoverable and addressable and secure.

Most of us shipped the other five. We built the catalog. We wired the access controls. We wrote the SLAs. Self-describing got a README and a Slack channel.

It worked, because the consumer was a person. A person carries context. Ask an analyst what “active customer” means and they’ll tell you the official definition, the two unofficial ones, and which team uses which. We never had to ship that. We hired it.

So “data as a product” quietly became “data plus whoever knows what it means.” The product had a hidden dependency, and the dependency was tribal knowledge, and nobody put it on the balance sheet because the customer was paying for it with their own time.

The customer that can’t bring its own

An agent shows up with nothing.

In July, a team from Alibaba and HKUST published a benchmark called EntSQL: 1,066 real enterprise questions, the kind people actually ask, with the documents and schemas that actually exist. Ninety-six percent of the questions needed knowledge that wasn’t in the question or the schema. Given only those two things, the best system got 6.8% right. Hand it the long-form documentation: 15.9%. Hand it expert-curated evidence, the stuff the analyst would have told you at her desk: 21.4%.

That gap is not a model problem. That gap is the free layer. The thing we never shipped because we didn’t have to.

The agent is the first customer that can’t be handed a README and told to ask around.

What context actually is

Not a vibe. Not “documentation.” Context is the specific set of things a consumer needs to turn a table into a true answer, and it’s shorter and more boring than the word suggests.

The shape of the data: what a row is, what the grain is, which table is the one you trust. The definitions: what Revenue means here, what it excludes, what changed and when. The joins that are safe and the ones that fan out. The caveats: the migration month, the renamed field, the region that reports late. A few worked examples, because a good question-and-answer pair teaches more than a paragraph. And the scope: what this data is not for, so the consumer stops instead of guessing.

That’s the product. Every item on it used to live in someone’s head.

Modeling is context

Here is where the argument usually goes wrong, so let’s be precise.

In February, MotherDuck ran three frontier models against 500 BIRD questions and landed on one sentence: “Good data modeling is the semantic layer.” When they added column comments on top of a clean model, accuracy moved 1.1 points on one set and 0.2 on the other. On schemas with obvious names, comments made things worse.

dbt Labs’ own benchmark in April says the same thing from the other direction. On an unmodeled schema, text-to-SQL scored 64.5% and their semantic layer scored 72.7%. Then they added three dbt models. Text-to-SQL jumped to the mid-80s and 90. The semantic layer went to 98 and 100. Eleven questions, twenty runs each, vendor-run, so hold it loosely. But read the shape of it. Modeling moved everything by twenty-plus points. The semantic layer added eight to sixteen on top.

That isn’t an argument against context. It’s the first line of the definition. The shape of the data is the cheapest, highest-leverage context there is, and it’s the one we already know how to build. A context layer bolted onto an unmodeled warehouse is decoration.

The order matters: shape, then definitions, then everything else. Most of what gets sold as “AI readiness” skips to step three.

Product, not layer

This June the vendors shipped it. Snowflake’s Horizon Context. Databricks’ Genie Ontology. dbt and Fivetran’s Agents Schema, an open standard that puts one schema in the warehouse as the shared context for agents. Gartner says that by 2030 universal semantic layers will be treated as critical infrastructure, alongside data platforms and cybersecurity.

Infrastructure is the wrong word.

A layer is something you buy. It’s a place to put definitions. It has no opinion about which definition of Revenue is right, or whether the Q1 dip should be explained or corrected, or what the agent should say when someone asks a question the data can’t answer. Those are product decisions. They have customers who disagree, a backlog that never empties, a metric that tells you whether you’re winning, and a failure mode you chose on purpose. Nobody at the vendors is writing about who owns that, because it isn’t a SKU.

We are. We always were. We just never had to ship it.

The tempting wrong answer

The instinct, once you see this, is to document everything. Load the whole schema. Write the long dictionary. Let the model sort it out.

dbt’s benchmark has a footnote: to make text-to-SQL work, they loaded the entire schema as context, “which isn’t practical for larger datasets.” Anthropic’s definition of context engineering is “curating and maintaining the optimal set of tokens.” Optimal. Not maximal. More context past the point of relevance makes answers worse and slower and more expensive, and it makes the humans who have to maintain it give up.

Which means context has an interface problem. What to show, when, and what to refuse. And it has two customers who want opposite things.

That’s the next piece.