One truth for people and machines

A manager asks the company's new AI assistant for last quarter's margin. The answer arrives in four seconds, well written and with a table. It's wrong. The model wrote its own SQL, summed gross rather than net sales and used a cost table finance stopped updating months ago. Nobody notices until the board meeting.

The scene is a composite, and it points to a problem the previous season left on the table: models make it easier to produce answers, but a convincing answer can spread a wrong definition into more decisions. A semantic layer helps govern metrics; sources and the interpretation of each question still need checking.

What a semantic layer is

Between the raw data, spread across the ERP, the CRM and the data warehouse, and the people asking questions, there's a translation that is almost always done by hand. Which table holds sales. Which columns get summed. Which filters apply. What “active customer” means. A semantic layer centralizes that translation in reusable definitions of metrics and dimensions. Depending on the tool, it is configured in code or in a managed model.

The idea isn't new. Looker's LookML popularised it more than a decade ago, and tools like the dbt semantic layer or Cube brought it to the center of the modern data stack. What changed is who it serves.

Why “headless”

In many BI implementations, a metric's logic ends up duplicated across reports and spreadsheets. The copies drift. But this is not an unavoidable limitation of visualization: Power BI, for example, lets teams share semantic models across reports and query them from Excel. The problem arises when consumers keep independent rules instead of reusing a governed definition.

An architecture with a shared semantic layer separates the definition from the views that consume it. It can expose metrics through an API or other interfaces, depending on the platform. A dashboard, spreadsheet, internal app and AI agent can query the same definition instead of keeping copies of the formula. For a change to reach everyone, consumers must migrate, the metric must be versioned and teams must check that none still calculates it independently.

A shared definition reduces drift between reports; it works only when everyone queries the same version and the sources are trustworthy.

The effect on hallucinations

When an agent answers data questions by writing free-form SQL against raw tables, it has to guess: which table to use, how each thing is calculated, which cases to exclude. It guesses confidently and sometimes gets it wrong, and the error arrives beautifully written.

When the same agent queries a semantic layer, the situation changes nature. It no longer writes the margin formula: it asks for the “net margin” metric filtered by quarter, and the layer runs the official definition. The model contributes what it does well, understanding the question in natural language, and leaves what it shouldn't improvise, the business rule, to a governed definition. It can also show the query that ran and the definition it used, so a person can verify it.

It doesn't remove every error: an ambiguous question stays ambiguous, a stale source stays stale and the agent can still pick the wrong metric. Sources, permissions and results need checking as well as formulas. The layer reduces one specific risk: the model improvising how your business is calculated.

Where to start

You don't need to model the whole company. Start with the ten metrics that drive the most decisions, with the definitions the business agreed on. Connect them to the real sources, expose them through an interface and point everything that recalculates those numbers on its own at it: the most used reports first, then the agents.

The scenes in these episodes are composites of common situations, not customer cases. Any figures in them are illustrative.