What a semantic layer is, how it differs from the warehouse and the dashboard, where it can live, and how to introduce one without a big project.
In short
A semantic layer is a shared model that sits between your data and the tools people use, and defines business metrics, dimensions and relationships once. Reports, spreadsheets and AI assistants then ask for "net revenue by region" and get the same calculation every time, instead of each tool and analyst writing their own version.
When the CFO and the sales director bring different revenue figures to the same meeting, the data is rarely wrong. Both numbers are correct for their own definition, written in two different reports. A semantic layer (semantiskt lager) is the fix for that problem. This explainer from Devies, a Gothenburg-based product and engineering consultancy, is for data leads, controllers and BI owners who want one definition of each metric across the business.
What is a semantic layer?
A semantic layer is a model that translates technical data structures into business concepts and defines how each metric is calculated. It holds three things:
- Metrics: measures with their calculation, such as net revenue, gross margin or active customers, including filters and time logic.
- Dimensions: the ways you slice metrics, such as customer, product, region and date, with their hierarchies.
- Relationships and rules: how tables join, which grain each metric is valid at, and who may see which rows.
Every tool that queries it receives results calculated the same way. The definition of "active customer" lives in one place, has an owner and changes once.
A metric is a business quantity with a fixed definition, such as "net revenue: invoiced amount minus credit notes, excluding VAT and intra-group sales". A semantic model is a concrete implementation of a semantic layer in a specific tool, such as a Power BI semantic model.
How is a semantic layer different from a warehouse or a dashboard?
A semantic layer is neither storage nor presentation: it is the agreed meaning in between. The table separates it from neighbouring concepts.
Concept
What it holds
Relation to the semantic layer
Data warehouse or lakehouse
What it holds
Cleaned and integrated data in tables
Relation to the semantic layer
Supplies the data the semantic layer calculates on
Gold layer in a medallion architecture
What it holds
Business-ready tables for specific uses
Relation to the semantic layer
Often the source for the semantic layer; it can hold some logic, but not query-time calculations
Semantic layer
What it holds
Metric definitions, dimensions, relationships, security
Relation to the semantic layer
The single place where business logic lives
Dashboard or report
What it holds
Visuals and layout
Relation to the semantic layer
Consumes metrics; should not define them
Business glossary
What it holds
Written definitions of terms
Relation to the semantic layer
Describes the meaning; the semantic layer implements it
Data catalog
What it holds
Inventory of data assets
Relation to the semantic layer
Lets people find the semantic layer and see its lineage
The rule of thumb is simple: if a calculation appears in more than one report, it belongs in the shared model. Our article on the medallion architecture explains how the gold layer prepares data for it.
Where can a semantic layer live?
A semantic layer can live inside a BI tool, in the transformation layer or in a dedicated product, and the right place depends on how many tools need the same metrics.
In the BI tool
In Microsoft's stack, the semantic layer is the Power BI semantic model, formerly called a dataset. It is built on Analysis Services technology and holds tables, relationships, DAX measures and row-level security. A shared semantic model that many reports connect to is the most common semantic layer in Nordic mid-sized companies, and it works well as long as most consumers use Power BI or Excel.
In the transformation layer
The dbt Semantic Layer, powered by MetricFlow, defines metrics in the same project as the data transformations and serves them to several BI tools through integrations. When a metric definition changes in dbt, it changes everywhere it is used. The hosted Semantic Layer requires a paid dbt plan.
As a shared standard
Vendors are moving towards portable definitions. The Open Semantic Interchange (OSI) initiative, started by Snowflake with dbt Labs, Salesforce and others, published the first version of an open, Apache-licensed specification for semantic model definitions in January 2026. It is early, so treat it as a direction rather than a requirement in a platform choice today.
Why does a semantic layer matter more with AI?
A semantic layer gives AI assistants a governed vocabulary, so a natural-language question maps to an approved calculation instead of a guess. When an assistant writes its own SQL against raw tables, it may join the wrong tables, miss a filter for intra-group sales or pick the wrong date field, and the answer looks just as confident as a correct one.
Pointing the assistant at the shared model narrows its job: it chooses metrics and dimensions that already exist, and the calculation is the same one the finance report uses. Row-level security in the model also applies to the assistant's answers. This does not make AI answers infallible, but it removes the largest single source of wrong numbers.
How do you introduce a semantic layer?
Start with the metrics people argue about and move them into one shared model, one at a time. Trying to model the whole business first usually stalls.
- List the disputed metrics. Revenue, margin, order intake and active customers are typical. Our article on why Power BI shows different numbers shows how to trace the differences.
- Write the definition in business language and get the owner, usually finance for financial metrics, to approve it.
- Implement it once in a shared semantic model with the right grain, filters and time logic.
- Repoint reports to the shared model and remove local copies of the calculation.
- Certify and document the model so people know which one to use.
- Add metrics in order of demand, and change definitions only through the owner.
Three pitfalls are common. The first is building one giant model for the whole company: it becomes slow, hard to change and owned by nobody, so split it by domain with shared dimensions such as date, customer and product. The second is leaving copies of old calculations in reports "for now", which brings the disputes back. The third is skipping version control and testing: a shared model is production software, and a mistake in it reaches every report at once.
The result shows on the KPI dashboards leaders actually use: the same number appears in the board pack, the sales dashboard and the assistant's answer.
Keep reading
From our work
Client Case: Stena LineStena Line modernised its Azure data platform - improving Power BI reliability, reducing pipeline runtimes and scaling with medallion architecture.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is the difference between a semantic layer and a semantic model?
A semantic layer is the architectural concept: one place where business metrics, dimensions and relationships are defined for every tool. A semantic model is a concrete implementation of that idea in a specific product, such as a Power BI semantic model or a set of dbt metric definitions. A company can have one semantic layer implemented as several connected semantic models, as long as each metric is defined only once.
Is a Power BI semantic model a semantic layer?
It can be. A shared Power BI semantic model, used by many reports and certified as the trusted source, works as the semantic layer for Power BI and Excel users. It becomes less suitable when many other tools, applications or AI services need the same metrics, because they do not all query Power BI models natively. Then a layer in the transformation tool or platform may fit better.
Do we need a semantic layer if we already have a data warehouse?
Usually yes, once several reports use the same metrics. A data warehouse stores clean, integrated data, but it does not stop each report from calculating revenue or margin in its own way. The semantic layer adds the shared calculation, filters and access rules on top. Some logic can be pushed into warehouse tables, but query-time calculations such as ratios and time comparisons need a semantic layer.
What is a metrics layer?
A metrics layer is another name for a semantic layer focused on metric definitions. The term became common with tools such as dbt's MetricFlow, which define metrics in code alongside data transformations and serve them to several BI tools. In practice the two terms are used interchangeably; the important property is that each metric is defined once and reused everywhere.
