Where Business Definitions Should Live When You Run dbt, Snowflake or Databricks, and Power BI

Why do business definitions drift across dbt, Snowflake and Power BI?

Business definitions drift because each layer of the stack now has its own place to define a metric, and each of those places was built for its own consumers. Five years ago a company usually had one semantic layer, the BI model. Today a team running dbt on Snowflake or Databricks with Power BI on top can define the same metric in four places:

• dbt models and the dbt Semantic Layer, where MetricFlow metrics are written in YAML next to the models they read.
• Snowflake semantic views, schema-level objects that Cortex Analyst and other Snowflake AI features use to answer questions in plain English.
• Databricks metric views, Unity Catalog objects defined in YAML that dashboards, Genie and SQL share.
• The Power BI semantic model, where DAX measures drive every report, Excel PivotTable and Copilot answer built on it.

Each of these is a semantic layer, and each one is a good idea on its own. The trouble starts when the same word, such as "net revenue", is defined in several of them by different people at different times. The warehouse team optimizes for SQL and AI agents, the analytics engineers for tested models, and the Power BI developers for the report that finance opens on Monday. Nobody is wrong, and the numbers still disagree.

AI has raised the stakes. When Cortex Analyst, Genie, Copilot or an agent connected over MCP answers a question, it uses whichever definition its own platform holds and states the result with full confidence. A difference that a careful analyst would notice in a reconciliation spreadsheet now reaches executives as a chat answer. Snowflake's own Power BI quickstart describes the problem plainly: when every tool keeps its own copy of a definition, those definitions drift, and nobody notices until the numbers disagree.

One metric defined across the stack

The fastest way to see the problem is to follow one metric through the stack. Finance defines net revenue as invoiced sales minus discounts, returns and credit notes, recognized on the date goods ship. Here is how that metric might look in each tool of a realistic stack, written by four different people.

dbt. The analytics engineer computes a net_amount column in the fct_orders model, gross amount minus discounts, returns and credit notes, and exposes it as a MetricFlow metric. The metric aggregates by order date, because that is the time dimension the model was built around.

models:
  - name: fct_orders
    semantic_model:
      enabled: true
    agg_time_dimension: ordered_at
    columns:
      - name: order_id
        entity:
          type: primary
          name: order
      - name: ordered_at
        granularity: day
        dimension:
          type: time
    metrics:
      - name: net_revenue
        description: "Order value after discounts, returns and credits"
        type: simple
        agg: sum
        expr: net_amount

The snippet uses dbt's latest metrics YAML spec, which the dbt documentation lists as supported on the dbt platform Latest release track, in dbt v2 and in dbt v1.12. Projects on older versions use the legacy semantic_models format.

Snowflake. The data platform team builds a semantic view for Cortex Analyst. It reads the same table but calculates its own net amount from the gross and discount columns, written before net_amount existed, and reports by ship date. Returns and credit notes are not subtracted.

CREATE OR REPLACE SEMANTIC VIEW sales_sv
  TABLES (
    orders AS analytics.marts.fct_orders PRIMARY KEY (order_id)
  )
  FACTS (
    orders.line_net AS gross_amount - discount_amount
  )
  DIMENSIONS (
    orders.ship_date AS shipped_at
  )
  METRICS (
    orders.net_revenue AS SUM(orders.line_net)
      COMMENT = 'Net revenue after discounts'
  );

Databricks (in a stack that runs on Databricks instead of Snowflake). The same logic appears as a measure in a metric view, again without returns.

version: 1.1
source: main.sales.fct_orders
fields:
  - name: Ship date
    expr: shipped_at
measures:
  - name: Net revenue
    expr: SUM(gross_amount - discount_amount)

Power BI. The BI developer builds the finance report on a shared semantic model. The DAX measure subtracts returns from a separate table, and the report's date table is related to the invoice date.

Net Revenue =
SUM ( Sales[GrossAmount] )
    - SUM ( Sales[DiscountAmount] )
    - SUM ( Returns[ReturnAmount] )

Four implementations across the Snowflake and Databricks variants of the stack, all called net revenue, and none of them matches the finance definition exactly:

For a month with late shipments and a large return, these produce at least three different numbers, and the only one with the right rules for returns uses the wrong date. Each one is internally consistent and passes its own tests. The question "which one is right?" cannot be answered inside any of the four tools, because none of them stores the finance definition or knows the other three exist.

Which business definitions belong in dbt, the warehouse and Power BI?

The practical rule is to compute as far upstream as every consumer can read, and to define meaning in one place above every tool. A business definition has two halves that belong in different places. The implementation is the formula a machine runs. The definition is the agreed meaning, the owner, the rules and the approval status that people and AI agents need to trust the number.

Two choices make this work in practice.

• Pick one primary semantic engine per metric. If Snowflake semantic views are the governed source for Cortex Analyst, do not also maintain an independent MetricFlow version of the same metric. Where a second implementation is unavoidable, such as the DAX measure Power BI needs, treat it as a copy that must match the primary one.
• Push the hard logic into dbt. If returns and credit notes are subtracted in a dbt column, every semantic layer that sums that column inherits the rule. The less logic each semantic layer carries, the less room there is for drift.

The metrics layer and semantic layer vs data marts articles cover the history of this split in more depth.

dbt MetricFlow vs Snowflake semantic views vs Databricks metric views vs Power BI

The four layers differ less in what they can calculate than in who can read them. That reach decides where a definition is useful, and where it becomes one more copy.

The last row is the one that matters for governance. Each layer knows its own definitions well and the others not at all. A longer vendor-by-vendor comparison, including Looker and standalone tools, is in our guide to semantic layer tools for BI and AI agents.

Can one semantic layer feed Power BI?

Partly, and the routes that exist either query through a connector or translate the definition into a second copy. Because Power BI is often the last mile to finance, every warehouse and transformation vendor now offers a path into it. As of November 2026:

• dbt. The dbt Semantic Layer Power BI connector is in preview as of November 2026. It shows metrics as virtual tables, one for each saved query plus a METRICS.ALL table, and the Semantic Layer turns Power BI's queries into SQL before they reach the warehouse. dbt's documentation says production readiness depends on Microsoft's participation in the Apache Ossie standard.
• Databricks. A metric view can be published to Power BI as a semantic model, a feature in private preview as of November 2026. Dimensions become columns and eligible measures become DAX measures; measures that read columns not declared as fields are dropped, which is what would happen to the metric view measure in the example above. Databricks notes that its BI compatibility mode is not available in the Power BI connector.
• Snowflake. Snowflake documents a quickstart that converts a semantic view into a Power BI semantic model through Apache Ossie, with a review step before changes are carried back. In the other direction, Semantic View Autopilot can generate a semantic view from an uploaded .pbix or .pbit file.

These bridges are useful, and Apache Ossie, the vendor-neutral YAML format formerly called Open Semantic Interchange, makes them easier to build. Deciding which version is the truth is still left to people. After a translation there are two definitions, in two languages, maintained by two teams. If someone edits the DAX measure in Power BI to fix a report, the semantic view in Snowflake does not know.

Why business definitions need one place above the semantic layers

Business definitions need one place above the semantic layers because the questions that matter most, what the metric means, who owns it and which version is right, cannot be answered from inside any one of them. A semantic layer stores a formula. It does not store the controller's approval, the policy that says returns are netted in the month of shipment, or the fact that the same metric exists in three other tools.

That place is a governed business glossary inside a context layer. For each metric it holds:

• The approved definition in plain language, with the rules behind it and the synonyms people use.
• A named owner who decides when implementations differ.
• Links to every implementation: the dbt model and MetricFlow metric, the Snowflake semantic view or Databricks metric view, the Power BI measure.
• Lineage from source systems through dbt and the warehouse to the report, so a difference can be traced to where it starts.
• Access for AI agents over MCP, so an assistant can return the definition and owner together with the number instead of guessing which version to trust.

This is the difference between a semantic layer and a context layer, explained in context layer vs semantic layer. The context layer leaves the calculation to the tools that compute net revenue and makes sure each of them implements the same agreed definition, in a way people and agents can check. For stack-specific detail, see the context layer for dbt, Snowflake and Databricks.

Should business definitions be written back into the semantic layers?

Writing an approved definition back into dbt, Snowflake or Power BI removes hand-typed copies, but it only works with a review step and with the written object checked again afterwards. There are two ways to keep implementations in line with one definition:

• Link and compare. Each team keeps writing its own YAML, DDL or DAX, and the governed definition records which implementation is canonical and flags the ones that differ. This works with every tool in the stack and leaves engineers in control of their code.
• Generate and write back. The semantic layer object is generated from the governed definition, so nobody retypes it. Open formats make this practical: Snowflake's SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML procedure creates a semantic view from an Apache Ossie document, Snowflake's Power BI quickstart carries a change made on either side to the other through Ossie with a review step, and Microsoft's Power BI authoring MCP server, generally available as a local server and in preview as a hosted endpoint as of November 2026, lets an AI agent add or change measures in a semantic model.

Write-back has limits worth knowing before you automate it. A generated object is only as good as the definition behind it, so the approval step matters more, not less. Translation is lossy: Snowflake drops Ossie fields and metrics that have no supported SQL dialect without raising an error, and Databricks drops measures that do not fit its Power BI publishing rules. And a written object can still be edited in place, so it has to be scanned back in and compared with the definition, which brings you back to link and compare. Most teams end up combining the two: generate where a tool accepts an open format, and link and compare everywhere else, including the DAX measures that finance adjusts by hand.

How to consolidate business definitions in five steps

Start with the ten to twenty metrics that leadership actually reviews, not with every measure in every model.

1. Inventory the implementations. For each metric, find every place it is computed: dbt models and metrics, semantic views or metric views, Power BI measures. Scanning metadata from each platform is faster than asking teams.
2. Write the approved definition and name an owner. Agree the meaning in business language first, including the time basis, what is excluded and the currency. The owner is a business person, usually in finance or operations.
3. Choose the primary implementation. Decide which engine computes the governed version, and move row-level logic such as returns and currency conversion into dbt so every layer inherits it.
4. Link and compare. Link each implementation to the definition, mark the ones that do not match, and fix or rename them. A Power BI measure that intentionally differs should get a different name, such as "Net Revenue (invoice date)".
5. Make the definition the first thing agents read. Expose the glossary to AI assistants over MCP, and add the approved definition to Power BI's AI instructions and to warehouse semantic metadata, so Copilot, Cortex Analyst and Genie answer from the same meaning.

How Dawiso keeps one definition across the stack

Dawiso is the context layer that holds the approved definition and connects it to the platforms that implement it. Its connectors scan metadata read-only, without copying data:

• Power BI: workspaces, semantic models, tables, columns and measures with their DAX expressions, and reports. Semantic models can also be read through a workspace XMLA endpoint.
• Databricks: Unity Catalog catalogs, schemas, tables, views and metric views with their YAML definitions, plus Genie spaces and dashboards, with lineage across them.
• dbt: projects, models, columns, tests and exposures, and lineage from the transformation layer.
• Snowflake: databases, schemas, tables, views and their columns.

In the Dawiso Business Glossary, each metric is a business indicator with its definition and rules, an approval state and a named business owner and steward, and it can be related to the scanned objects that implement it, so the Power BI measure, the dbt model and the Databricks metric view sit next to one approved meaning. Dawiso's KPI application adds a dedicated place for calculations, ownership and lineage of key metrics. AI tools that support MCP, such as Claude and Cursor, can query Dawiso through the Dawiso MCP Server: they can search objects, read their attributes, such as a term's definition and workflow state, and trace lineage.

For Snowflake, Dawiso can also hand structure back. A data product defined in Dawiso can be exported as an OSI YAML file that describes its output ports: the tables and columns they reference and the foreign-key relationships between them. Run in a Snowflake worksheet inside a SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML call, it creates a semantic view; through Dawiso's export API, the file can be returned already wrapped in that statement. Metric formulas are not part of the export, so they stay in the semantic layer that computes them, related to the approved definition.

The semantic layers keep computing the numbers where they run best. Dawiso records what each number is supposed to mean and shows where it is computed.

Sources

• dbt Labs - Migrate to the latest YAML spec
• dbt Labs - dbt Semantic Layer
• dbt Labs - Power BI integration (preview)
• Snowflake - CREATE SEMANTIC VIEW
• Snowflake - Overview of semantic views
• Snowflake - Creating semantic views with Snowsight
• Snowflake - SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML
• Microsoft Learn - Power BI authoring MCP server
• Snowflake - Connect Power BI with Ossie semantics
• Databricks - Metric view YAML syntax reference
• Databricks - Connect metric views to Power BI (November 2026)
• Databricks - Use BI compatibility mode to query metric views (November 2026)
• Microsoft Learn - New name for Power BI datasets
• Microsoft Learn - Prepare your data for AI
• Apache Ossie - Apache Ossie (Incubating): The New Name for Open Semantic Interchange
• Dawiso Help - Business Glossary, Key Performance Indicators, Power BI, Databricks, dbt, MCP and OSI export