What is a semantic layer?
6 min readUpdated
A semantic layer is a governed map between raw database tables and the business concepts people actually ask about: metrics, dimensions, and the relationships between them. It exists so that a question like "what was net revenue last quarter?" resolves to one agreed definition rather than whichever SQL a given person or model happens to write. Without one, a natural-language analytics system will produce fluent answers that disagree with each other and with the finance team.
The problem it solves
Ask five analysts for last quarter's revenue and you can get five numbers without anyone being wrong. Revenue might or might not include intercompany eliminations, might be booked on invoice date or recognition date, and might exclude a category that one team has always excluded.
Point a language model at the raw tables and you inherit that ambiguity, plus a new one: the model will resolve it differently on different days, in ways nobody can see. The answer arrives formatted and confident, with no sign of the assumption it made.
What the layer actually contains
- MetricsThe measures the business agrees on, such as net revenue, gross margin, and active accounts. Each is defined once, with the filters and grain built into the definition rather than re-derived per question.
- DimensionsThe ways a metric may legitimately be sliced: region, product line, fiscal period. Declaring these prevents a breakdown by a column that looks plausible but does not mean what its name suggests.
- Joins and grainHow entities relate, and at what level of detail. This is where double-counting is prevented. A metric joined across a one-to-many relationship without a declared grain will silently inflate.
- CertificationWhich definitions an accountable person has approved. An uncertified metric may still be useful; it should not be presented with the same authority as one finance has signed off.
Certified metrics versus ad-hoc SQL
Both have a place. The mistake is presenting the first as though it were the second, which is what happens when a system answers every question with the same confident formatting regardless of whether a definition was governed.
| Ad-hoc generated SQL | Certified metric | |
|---|---|---|
| Definition | Re-derived per question | Declared once, reused |
| Consistency | Varies by phrasing and by model | Same answer every time |
| Accountability | Nobody approved it | A named owner approved it |
| Grain safety | Fan-out is possible | Grain declared and enforced |
| Good for | Exploration, novel questions | Anything a decision rests on |
How this works in Nexatron
Nexatron expresses its semantic layer in MetricQL: metrics, dimensions, hierarchies, and joins are declared once and compiled to warehouse SQL at query time. The same definition answers a question typed into the product, a certified-metric lookup, and a query arriving from an AI agent over MCP, so a person and an agent asking the same question get the same number.
Certification stays a human decision. Technical semantics are generated automatically when a source is connected; promoting a definition to certified is an analyst action, on purpose, because auto-certifying a plausible-looking metric is how an incorrect definition becomes enterprise truth.