The Human API Problem

It is 4:47 on a Thursday. A VP messages your senior analyst: "Quick one, what was net revenue retention in EMEA last quarter? Need it for the board deck tomorrow."

It is not a quick one. The analyst stops what she was building. She remembers that EMEA excludes the UK reseller deals after the 2025 reorg. She remembers that net revenue retention uses the contracted figure, not the billed one, because billing lags renewals by a month. She writes the query, checks it against last quarter's board number so the two agree, and sends back "61.2%." Twenty minutes gone. The thing she was building waits until tomorrow. Tomorrow there will be another quick one.

This is the Human API problem. Your data team is an interface. Requests go in through Slack. Numbers come out. The latency is measured in hours on a good day and days on a bad one. And like any API, when it goes down, which is to say when the person who knows is on vacation, the whole thing returns errors.

Why your best people became a lookup service

The reason this happens is not laziness and it is not bad tooling. It is that the most important knowledge in your company, how each metric is actually defined, lives in people's heads instead of in a system.

The warehouse has the data. It does not have the judgment. It does not know that EMEA excludes the reseller deals, or that retention uses contracted dollars, or that "active user" means one thing to Finance and another to Growth. That judgment lives in three or four senior people. So every question that needs it routes through one of them. In the teams we work with, the figure that comes up again and again is eighty percent: eight of every ten hours spent directing traffic, not building. They are not answering because they want to. They are answering because they are the only place the definition exists.

What it costs

Three things break, quietly.

The first is that your most expensive people stop building. An analyst you hired to model churn drivers spends most of her week being a search engine with a pulse. The roadmap slips and nobody can point to why, because no single quick-one was the problem.

The second is latency. Every decision that is supposed to be data-driven waits in a human queue. The board deck waits. The pricing call waits. By the time the answer arrives, the meeting has moved on, or someone made the call without it.

The third is the bus factor. When the one person who knows how revenue is really calculated is out, the answer is either wrong or missing. We have watched a company miss a board number by eight percent because the analyst who knew the adjustment was on a flight.

The fixes that do not work

You build more dashboards. But a dashboard only answers the questions you predicted, with the cuts you pre-built. The first question that does not fit, "okay but EMEA excluding resellers, monthly," goes straight back to the analyst. Worse, self-service without governance multiplies the problem: you hand out Looker, and six months later there are forty-seven definitions of revenue and a new ticket in your queue asking which number is the right one. The longer version of why dashboards do not dissolve this is in the data-driven lie.

You document the warehouse. You spend a quarter writing it all down. It is stale before you finish, because the schema kept moving while you typed. Nobody trusts a wiki that was wrong last week, so they go back to Slacking you. Documentation rots at the speed your warehouse changes, which is faster than a human can maintain.

You point an LLM at the warehouse. This moves the bottleneck, it does not remove it. The model does not know your definitions either, so it guesses, and it guesses plausibly: wrong column, impossible join, inflated number, returned with total confidence. Now instead of waiting for a correct answer you get an instant wrong one. We wrote about why that is worse in why LLMs cannot do math.

The actual fix: put the definitions in a system

The only way to stop your data team being an API is to move the definitions out of their heads and into something the warehouse can consult on its own.

That is what Cartographer does. It reads how your warehouse is actually used, the real query history, not just the schema, and builds a Decision Context Graph: the entities, the measures, the join paths with their cardinality, the time columns, and the metric definitions, bound to the actual tables. That is metric alignment that holds: one definition of revenue instead of forty-seven, and it does not depend on anyone remembering the rule. The work that used to take a quarter of manual modeling takes a few hours, and it does not go stale, because it is rebuilt from how the data is really queried.

Once that layer exists, "net revenue retention in EMEA last quarter" resolves to the same governed answer whether the analyst is at her desk or on a beach. Business users explore it through the Living Map and get their own answers, and the questions stop arriving in your inbox. The data team stops being the lookup service and starts owning the layer everything else queries. You move from the bottleneck to the people who built the thing that removed it.

The point is not to replace your data team. It is to stop spending them on lookups. Real data-driven decision making does not run through one person's inbox. The Human API was never a good use of the smartest people in the building. Give them back the part of the job they were hired for.

If your team is the relay between every executive and the warehouse right now, that is the bottleneck we are trying to dissolve. Come see how.