What Is a Semantic Layer? Why Microsoft and Snowflake Are Building a Shared Standard for Business Metrics

A semantic layer is the set of agreed business definitions that sits between your raw data and the reports, dashboards and artificial intelligence (AI) tools people use. It records what "revenue," "active customer" or "gross margin" means, how each one is calculated, and how your tables relate to each other, so every tool gives the same answer to the same question.

It has been part of business intelligence (BI) for years, mostly out of sight. It is getting more attention now for two reasons. AI assistants that answer questions about company data depend on it to know which numbers to use. And in late September 2026, Microsoft and Snowflake said they are working together on Apache Ossie, an open standard meant to let those definitions move between tools instead of being rebuilt in each one.

A semantic layer is a shared dictionary for your business numbers

Most companies have met the problem it solves, even if they never named it. Finance reports revenue net of refunds. The sales dashboard counts revenue when a deal closes. Marketing pulls revenue from the payment processor. All three are reasonable, all three are labelled "revenue," and the next leadership meeting starts with working out why the figures don't match.

A semantic layer settles that once. Instead of each report carrying its own formula, the definition lives in one place, and every report, dashboard and query uses it. Snowflake's documentation for its semantic views gives a useful picture of what goes inside: the business entities you care about, such as customers and orders; the relationships between them; row-level facts, such as an individual sale amount; metrics built from those facts, such as total revenue; and dimensions to slice them by, such as region or product line.

Done well, it also translates. Database columns often carry names like cust_ord_amt_net. The semantic layer maps them to terms people use, so someone building a report doesn't need to know which column means what.

Most companies already have more than one semantic layer

If your team uses Power BI, you already have a semantic layer: the Power BI semantic model, where measures are written in Data Analysis Expressions (DAX). Snowflake now has semantic views inside the data warehouse. The dbt Semantic Layer, Tableau, Looker and many other tools each keep their own version too.

That is where the trouble starts. A company that uses two or three of these tools usually defines its key metrics two or three times, in different languages, maintained by different people. Over time the copies drift apart, and the original problem comes back in a new form: the same question returns different answers depending on which tool you ask. dbt Labs describes the result as conflicting definitions and dashboard drift.

AI assistants depend on the semantic layer to give the right answer

When someone asks an AI assistant "What was revenue last quarter?", the assistant has to decide which data to use and how to calculate it. If a governed definition exists, it can use that. If not, it has to guess from table and column names, and two people asking the same question can get two different answers.

This is why the large platforms are tying their AI features to semantic definitions. Snowflake's semantic views feed its Cortex Analyst tool for plain-language questions. Microsoft says its Fabric IQ insights in Copilot use established Power BI metrics and respect existing permissions. When Snowflake first announced the standard, Gartner analyst Yogesh Bhatt told CIO Dive that "metadata is key to an enriched semantic layer", while noting that standardizing it will take time to mature.

Apache Ossie is an open format for moving metric definitions between tools

The standard started as the Open Semantic Interchange (OSI), which Snowflake announced in September 2025 with partners including dbt Labs, Salesforce, Sigma, BlackRock, Mistral AI and RelationalAI. In July 2026 it was renamed Apache Ossie and accepted into the Apache Software Foundation (ASF) incubator, the step open source projects go through before becoming full Apache projects. By then the group had grown from 17 launch partners to more than 50 organizations, including Databricks.

Ossie is a file format, not a product. It describes metrics, dimensions and relationships in a vendor-neutral way, so a tool can export its definitions to Ossie and another tool can import them. Snowflake's announcement is clear about the limits: Ossie is not a query engine or a BI tool, it does not yet standardize how queries are written, and its roadmap is decided by community discussion and vote.

Microsoft's support is what makes this more than a Snowflake project. In late September, Microsoft and Snowflake said they are collaborating on Ossie, and Snowflake published an initial Power BI converter that translates definitions between Power BI semantic models and Ossie, and from there into Snowflake semantic views. Snowflake says the specification now recognizes DAX as a query expression language, so measures written for Power BI can be represented in Ossie. Snowflake describes the converter as early work, with more to come, and Microsoft has not announced dates for built-in Fabric features based on Ossie.

What the standard means for teams using Power BI, Snowflake or AI assistants

For now, it depends on how many tools your team uses.

If your reporting runs through one tool, you already have one semantic layer, and Ossie changes little day to day. The most useful thing is to make sure your metrics are actually defined there, rather than rebuilt inside individual reports.

If you use Power BI on top of Snowflake, or several BI and AI tools against the same data, Ossie is worth watching. The promise is that a metric defined once could be converted into each tool's format instead of rewritten by hand. The converter is new, so treat it as something to test rather than rely on yet.

If you are rolling out AI assistants on company data, the semantic layer matters most of all. An assistant can only be as consistent as the definitions it reads, whatever standard ends up winning.

How to get your metric definitions ready

None of this requires new software. A practical starting point looks like this:

List the 10 to 15 metrics people use to make decisions, especially the ones that cause arguments.
Write one plain-English definition for each, including what is included and excluded, and name an owner.
Note every place each metric is calculated today: spreadsheets, BI reports, your customer relationship management (CRM) system, finance tools.
Move each definition into one governed place, such as your BI tool's semantic model or semantic views in your data warehouse.
Point dashboards and AI assistants at those definitions, not at raw tables.

Teams that do this will be ready to take advantage of a shared standard once tools support it, and they will see more consistent numbers in the meantime.

Common questions

Is a semantic layer the same as a data warehouse? No. The warehouse stores the data. The semantic layer stores the business meaning on top of it: what the metrics are and how to calculate them.

Does a small team need one? If you report from one tool and a handful of metrics, the semantic model built into that tool is enough. It becomes more important as you add tools, data sources or AI assistants.

Will Ossie replace Power BI semantic models or Snowflake semantic views? No. It is an exchange format. Each tool keeps its own semantic layer, and Ossie is meant to move definitions between them.

Is Ossie free to use? Yes. It is an open source project, and dbt Labs noted that the first version of the specification was published under the Apache 2.0 license.

Sources

‍

Byte