Two analysts built two Power BI reports on the same Snowflake retail warehouse. Both reports have an "Avg Customer Discount" visual, both read the same FACT_SALES table, and both return a number to two decimal places. The numbers don't match.

Open the semantic models and the reason is one line apart. In the first model, DISCOUNT = ('FACT_SALES'[SALES_AMOUNT]-'FACT_SALES'[DISCOUNT_AMOUNT])/100. In the second, DISCOUNT = 'FACT_SALES'[DISCOUNT_AMOUNT]/100.

Same name, same table, two definitions, and every dashboard built on either one inherits the disagreement. It's a common scenario that exists somehwere in every BI stack.

This brief walks the metric from two Power BI models into one governed definition, then out to Snowflake, Power BI, and Tableau, with the artifacts you'd see at each step.

Two correct models can still disagree

Each analyst wrote a defensible discount calculation by their own standard, inside the tool they were working in, for the report they were asked to build.

The drift comes from where the definition lives. A metric written inside a Power BI semantic model has a scope that ends at that model. The next report, the next tool, and the next migration each get a fresh copy, typed by a different person with a different read of what "discount" was supposed to mean.

So the fix has to start with the copies you already have, because they hold years of logic your team would otherwise re-type from screenshots.

Import reads the definitions you already run

MetaKarta starts by reverse-engineering existing semantic models into a Semantic Model Catalog, a governed container stored in the same shared metadata repository as the rest of the platform. Both Power BI semantic models come in together, with their tables, columns, metrics, and joins.

The import sorts every metric into one of four cases, and the demo models carry one of each:

• High-Value Customer exists only in the first model, so it comes in once and becomes available to fields from both.
• Churned Customers exists only in the second model and gets the same treatment.
• Net Sales Amount is defined identically in both ([SALES_AMOUNT]-([DISCOUNT_AMOUNT]+[TAX_AMOUNT])), so the merged model holds one copy.
• Discount carries two different expressions under one name, so the merge keeps both, as DISCOUNT and DISCOUNT 1.

The fourth case is the one that matters. A merge that silently picked a winner would hide the disagreement your executives keep tripping over.

The conflict shows up as two expressions, before anything merges

Keeping both versions turns an argument about screenshots into two expressions on one screen. When the imports land in an existing catalog, the Merge Semantic Catalogs view shows the Base Catalog, the Imported Catalog, and the proposed Merged Catalog side by side, with a YAML diff and a list of problems.

Data Lineage supplies the evidence. Each measure traces back through the BI model and the SQL to its source columns, so the steward who has to choose can see where the two calculations diverge instead of guessing.

The data steward keeps the first expression and deletes DISCOUNT 1. In your estate, that decision belongs to whoever owns the definition of discount, and Data Governance records who made it.

Every expression gets converted into the target dialect

The merged model's expressions are still DAX, because that's what they were imported from. The warehouse underneath it is Snowflake, so the expressions need a Snowflake version before anything deploys there.

Validation flags every expression that won't run in a deployment target. The Churned Customers dimension, for example, came in as a DAX comparison against today's date, and its Snowflake version reads:

IFF("EFFECTIVE_TO" < CURRENT_DATE, 'YES', 'NO')


The expression editor lets a modeler write that conversion by hand, dragging columns in from the model. Convert Model Expressions does the same work across a whole model in the background, through MetaKarta's built-in conversion or an AI-assisted pass when needed. When the warnings clear, every metric carries an expression for each dialect it has to run in.

Before anything ships, the Test view runs the model against live data. Drag the metrics into Columns, Filters, and Order By, click Execute, and use Show SQL to read the generated query. That's where you check the governed discount against the number finance expects.

One model deploys as a native artifact in each target

From the Editor tab's Deploy view, one governed model goes out to each target as that platform's own object.

Snowflake. Choose Snowflake Database and Deploy, and a semantic view appears in the deployment database and schema set on the connection. Open it in Cortex Analyst and ask a question: the agent reads the same governed discount the dashboards will.

Power BI. Choose Power BI Server and Cloud and Deploy. The deployment creates the Power BI connection to the governed model, and a new report built on it returns the governed discount.

Tableau. Set Tableau Server and Cloud as a BI deployment target and the same model lands as a Tableau data source. Build a worksheet on it and compare the number with Power BI.

Write once, compile anywhere.

The model is also text. Open Script shows it in Semantic Hub Language (SHL), the open-source, YAML-based language Semantic Hub compiles from, so every definition is readable by a person and diffable between versions.

The next change lands everywhere at once

The real test comes three months later, when finance decides discount should exclude a promotion code. That change gets made once, in the governed model, by the person who owns the definition, and the next deployment carries it into Snowflake, Power BI, and Tableau together.

Each target runs the artifact the model compiled for it, so no private copy is left to drift. We don't sit in your query path. We've already compiled into your database and tools.

Lineage picks up the change the same way. The compiled artifacts sit in the same repository as the traces behind them, so anyone checking a dashboard number can follow it back to the governed definition, and from there to the source columns.

Where the governed metric pays off

The two discount expressions in this walkthrough are a small example of a common problem: correct models, built in separate tools, that quietly disagree. The fix is one definition, imported from what you already run, reconciled once with the evidence on screen, and compiled natively into every system that reads it.

The compiled artifact is the proof.

MetaKarta builds that into the Metadata Management Platform through Semantic Hub, on the same shared metadata repository as Data Lineage, Data Catalog, and Data Governance. Get in touch to learn more about how MetaKarta compiles one governed metric into Power BI, Snowflake, and Tableau.

‍