What you will learn
- What a semantic layer is and what it replaces
- How dimensions, measures, and entities fit together
- The build order from definitions to governed serving
- Why AI tools make semantic layers more important, not less
What this project is
Ask five teams for monthly active users and you may get five answers, each defensible, each different. Filters differ, date logic differs, deduplication differs. A semantic layer ends that argument by defining each metric once, in code, with its dimensions and grain, and serving it through one query interface.
This matters more as AI tools query data directly. A language model asking for revenue will use whatever definition it finds, and if five definitions exist, it picks one at random. A semantic layer gives AI tools the same governed definitions humans use, which is why it has become infrastructure rather than a nice-to-have.
Core features
- Metric definitions with measures, dimensions, filters, and grain, stored as versioned code.
- Entity definitions linking metrics to customers, orders, and products consistently.
- A query interface serving metrics to dashboards, notebooks, and AI tools alike.
- Access controls per metric and dimension, enforced at query time.
- Change review with impact previews for every definition change.
- Usage tracking showing which metrics and tools depend on each definition.
How it is built
- Core metrics first. The five to ten metrics that cause the most disagreement, defined and served.
- Dimensions second, standardising the groupings every metric shares.
- Tool integration third, connecting dashboards and notebooks to the layer.
- AI access fourth, exposing governed metrics to language-model tools.
- Governance last. Ownership, deprecation, and change review at scale.
Technology considerations
The semantic layer needs a query engine that translates metric definitions into warehouse SQL, with caching for common queries. Definitions belong in version control with review, since a metric change is a business change. The serving layer must enforce permissions per metric and dimension, or a governed definition still leaks restricted data. Build effort depends on metric counts; confirm with a quote.
- Versioned metric definitions stored as code with review.
- A query engine translating definitions into warehouse queries.
- Caching for frequently requested metric queries.
- Permission enforcement per metric and dimension at query time.
Challenges to plan for
- Definition arguments. Teams disagree about what a metric should mean, and the platform must record decisions, not just definitions.
- Performance. A query layer adds latency, so caching and warehouse optimisation matter for adoption.
- Coverage gaps. A layer covering ten metrics while teams need fifty pushes users back to raw tables.
- Change breakage. A metric change ripples into dashboards, so impact previews and notice periods are essential.
A worked example
A company launches an AI assistant that answers questions about sales performance, and early users notice it gives different revenue figures depending on how they phrase the question. The problem is not the AI; it is five revenue definitions scattered across dashboards. The company builds a semantic layer defining revenue once, with its filters, grain, and dimensions, and connects both dashboards and the AI tool to the same query interface.
Now a question about revenue by region returns the same number in a dashboard and in the AI assistant, because both read the same definition. When finance changes the revenue definition to exclude cancelled orders, the change ships as a reviewed version with an impact preview listing every dashboard and AI prompt that uses it, and a notice period before it takes effect. The AI tool stops inventing definitions, the dashboards stop disagreeing, and the arguments move from whose number is right to whether the definition itself should change, which is a much better argument to have.
Who it is for, and its limits
This fits companies with several analytics tools, or any team adding AI access to data, where consistent definitions matter.
It does not fit a single dashboard on a single warehouse, where view definitions suffice. It also does not settle business arguments by itself; it records and enforces the settlement.
Frequently asked questions
What is the difference between a semantic layer and a dashboard?
A dashboard presents numbers. A semantic layer defines them once and serves them to any tool, so dashboards agree by construction.
How many metrics should a first version define?
The handful that cause real disagreement, usually five to ten. Coverage grows from usage, not from a big upfront catalogue.
Do AI tools use semantic layers?
They should. A governed layer gives language models the same metric definitions humans use, instead of letting them guess.
What is grain in a metric definition?
The level each row represents, such as one row per order or per customer per day. Grain mistakes cause double counting.
Can metrics differ by team?
Sometimes legitimately, and then they should be distinct named metrics with stated definitions, not silent variants of one name.
Why do AI tools need a semantic layer?
Because a language model asking for revenue will use whatever definition it finds, and if five definitions exist it picks one at random. A governed layer gives AI the same definitions humans use.