What a semantic layer is, and whether you need one.

The same metric gets rebuilt in every tool that shows it. The dashboard carries its own formula, the spreadsheet carries another, and whatever answers questions in plain English works out a third. Nobody made a mistake. They were built at different times by different people from the same raw tables.

A semantic layer moves the definition out of the tools and into one place they all ask. A tool requests the metric by name and gets back the agreed calculation, rather than being trusted to reproduce it.

Less than the name suggests. Four kinds of statement, written once and versioned like code.

• Metrics

  A name and the expression behind it. This is the part people picture, and on its own it is not enough to make the metric safe to use.

• Dimensions

  How the metric may legitimately be sliced. Stating this stops a metric being broken down by something it cannot be broken down by, which is a common source of totals that do not add up.

• Joins and grain

  Which tables relate, on which key, and what one row represents in each. Grain is the part that silently multiplies figures when it is left out, and it is left out often.

• Access rules

  Who may see which rows. Holding this beside the definition is most of the appeal for anyone reporting on separate clients out of shared tables.

Modelled tables put the consistency into the data itself. A semantic layer puts it into a service sitting in front of the data. Both end with one answer, and the difference is where the agreement is enforced.

Tables can be read by anything that speaks SQL, which includes every reporting tool and every AI agent, with nothing to adopt. A layer has to be spoken to, so every tool either goes through it or quietly does not.

So the rule of thumb is about churn rather than size. If your definitions change often and several tools read them, a layer earns the service it costs. If your metric set is stable, model the consistency into the tables and skip the extra hop, because the second version of the truth you are trying to avoid is exactly what a bypassed layer creates.

An agent answering a question about a client's marketing picks columns and writes a query. It can only use meaning that is reachable from the data. A definition held in a dashboard's configuration is invisible to it, which is why a chatbot and a dashboard built on the same warehouse can disagree.

That is the real requirement, and a semantic layer is one way to meet it rather than the only one. Named columns, a stated grain and one metric name per concept meet it too. What does not meet it is a definition that exists only inside a reporting tool.

The transform step does this job in the tables. One name per metric, one type, one grain and one currency, applied in SQL inside a warehouse you own, which means the definition and its implementation are the same artefact and cannot drift apart.

Anything that reads SQL reads the same figures. The client dashboards and the chatbot are both reading the modelled tables rather than each carrying a private idea of what a metric is.