Most large enterprises already have semantic models. They have several. One sits in Power BI, one in a set of Tableau data sources, one in a MicroStrategy project that predates everyone on the current team, one in LookML, and since last year, one more in a Snowflake semantic view somebody built for a pilot.

Each was built by a different team, in a different year, for a different tool. That arrangement held for a long time, because a person read every dashboard and a person noticed when two numbers disagreed.

Four things changed at roughly the same time:

• BI consolidation turned semantic models into migration scope, on a schedule set by a licensing decision.
• Warehouse vendors began hosting semantics natively, through objects like Snowflake Semantic Views, Databricks Metric Views, and Oracle Analytic Views.
• Agents and text-to-SQL interfaces began reading those definitions to answer business questions, with no person checking the result.
• Auditors began asking what a metric meant on a specific date, and who changed it.

Each of those promotes a metric definition from a setting inside a BI tool into shared infrastructure. Infrastructure has to return the same answer in every system that reads it, survive a platform change, carry its own access rules, and answer for its own history.

This paper covers what a definition now has to do, how the definitions most enterprises already own quietly drift, and a diagnostic you can run against one of your own metrics this week with no vendor in the room.

Why Definitions Got Promoted

For most of the past decade, a metric definition was a property of a report. It lived in the tool that rendered it, and its scope ended at the edge of that tool.

That scope was tolerable because every tool had a human reader. When the finance dashboard and the sales dashboard disagreed, someone noticed, made a few calls, and wrote a footnote.

Four pressures ended that tolerance.

BI consolidation became a standing condition

Large enterprises rarely run one BI platform. Most run three or four, accumulated through acquisitions, departmental purchases, and the occasional executive preference.

Consolidation projects arrive on a vendor's renewal clock, and they almost always get scoped as report migrations. The semantic models underneath the reports, years of joins, hierarchies, level-of-detail calculations, and time intelligence, turn out to be the real scope about three weeks in.

The default response is to rebuild those models by hand in the new tool. A rebuild is a second copy of every definition, written by a different person, under deadline. It also guarantees the next consolidation will cost the same.

The warehouse started hosting semantics

Snowflake Semantic Views, Databricks Metric Views, and Oracle Analytic Views put metric definitions directly inside the data platform. That's a real improvement for anything that queries the warehouse, including the AI interfaces those vendors ship alongside them.

It also adds a location. An enterprise with three BI tools and one warehouse-native semantic object now has four places a definition of revenue can live, and nothing that keeps them in agreement.

The warehouse-native objects solve the problem for one platform. Most estates have more than one platform, and will for the foreseeable future.

Systems started reading definitions before answering

Structured AI consumption through interfaces like Snowflake Cortex Analyst and Databricks Genie reads a semantic definition to decide what "revenue" or "active customer" means, then generates SQL to answer a business question with it.

A human analyst who hits two plausible definitions asks someone. An agent picks one and proceeds with confidence, right or wrong.

When the agent's number disagrees with the board deck, the question becomes which definition the agent read, and whether it matches the one finance signed off on. Most organizations can't answer that from their current tooling.

Audit questions reached the metric

Disclosure and controls work under SOX, CSRD, and ISSB increasingly lands on metric definitions: what a reported figure meant, how it was calculated, and whether the calculation changed between periods.

A definition that lives inside a BI tool's model file has whatever version history that tool happens to keep, which is often none. Reconstructing what a metric meant last quarter becomes a project staffed from roadmap work.

The market moved at the same time

Two signals landed in the same window. Gartner revived the Metadata Management Magic Quadrant in November 2025, and categories don't come back when demand is flat.

The second signal is standardization. Open Semantic Interchange moved to the Apache Software Foundation as Ossie, now incubating with more than 50 participating organizations behind a YAML and JSON specification for exchanging semantic models.

A shared file format settles how a definition travels between tools. It leaves open who governs what goes in the file, which version is authoritative, and whether the same definition actually reached every system that needed it.

Where This Shows Up First

The shift is easy to miss. It shows up in four ordinary meetings that go worse than they should.

The revenue dispute: The CFO's deck shows one revenue figure and the sales dashboard shows another. Two analysts spend a week establishing that one model excludes refunds in a filter and the other joins to a different customer dimension. Both were built correctly, by their own standard.

The migration that rebuilds instead of moves: A MicroStrategy-to-Power BI consolidation is scoped from a report inventory. Halfway through, the team finds that the metrics depend on level-of-detail logic, role-playing date dimensions, and filtered calculations that have no one-to-one equivalent in the new tool. They get rewritten by hand, and the rewrites get tested by comparing screenshots.

The agent that answers confidently and wrong: A text-to-SQL pilot reads a semantic view built for the pilot. Its definition of gross margin matches the warehouse team's version, which differs from the one in the Tableau data source the finance team uses. The pilot stalls at review because no one can say which definition was supposed to win.

The access review: Row-level access for regional sales data is defined three times: as user filters in Tableau, as roles in Power BI, and as a row access policy in the warehouse. Three teams maintain them on three schedules. The auditor's sample finds one region where they disagree.

Each of these usually gets filed as a different problem: a reporting problem, a migration problem, an AI problem, a security problem. They resolve to the same missing capability, which is a definition that exists once and reaches every system from that one place.

What a Definition Now Has to Do

Documentation can describe a definition. Infrastructure has to do all five of the following.

Produce the same number in every system that computes it

A metric gets computed wherever it gets queried: the warehouse, each BI tool, each agent. The requirement is that every one of those computations comes from the same governed logic.

Passing looks like: the same metric, queried with the same filters in three tools and one agent, returns the same number, and the logic behind it is readable in each system that executes it.

Agreement by convention, where three teams agree to keep three copies aligned, passes on the day it's set up. It starts failing the first time one team ships a change the others didn't hear about.

Survive a platform change without being rebuilt

BI platforms and data platforms will change on someone else's schedule. The definition should outlast any one of them.

Passing looks like: the definitions in a tool being retired get reverse-engineered with their expressions intact, reconciled against definitions elsewhere, and deployed into the replacement without a person re-typing the logic.

A definition that can only be rebuilt by hand is locked into the tool that holds it, whatever the contract says about data ownership.

Carry its access policy with it

Who may see which rows of a metric is part of the metric's meaning. A regional sales figure with the wrong row filter is a different figure.

Passing looks like: a row-level policy defined once alongside the definition, then enforced natively in every system the definition reaches.

Rebuilding the same policy per tool produces the same drift as rebuilding the same metric per tool, with an auditor as the one who finds it.

Supply meaning to systems that read definitions instead of documentation

A wiki page describing a metric is readable by a person and invisible to an agent choosing between two columns with similar names. Anything a metadata consumer can't query, it works around, usually by guessing.

Passing looks like: definitions, their business vocabulary, and their bindings to physical assets available as structured context an agent can query, with the agent's answer traceable back to the definition it used.

There are two ways to give an agent context. It can receive raw material (schemas, glossary entries, a graph to traverse) and assemble meaning at query time, which costs compute and tokens and returns a probabilistic answer. Or it can receive a definition that was already governed and deployed, and return a deterministic one.

Answer what it meant on a date someone else picks

Regulators and auditors name dates, and they're rarely today's. The question is what the definition said, who changed it, and when.

Passing looks like: version history on every definition, with attribution, a readable difference between any two versions, and a way back.

Current-state definitions answer today's question well. Any question about a closed quarter needs a time axis, and adding one after the fact means reconstructing history from tickets and memory.

How Definitions Quietly Drift

These failures are quiet by construction. Two definitions that disagree look exactly like two definitions that agree until someone puts the numbers side by side.

Each of the six below is observable from inside your own organization today, without a vendor conversation.

The definition lives in the tool

How you'd notice: ask where the authoritative definition of your top revenue metric is written. The answer is a list of tools.

What it costs: every tool is a copy, and every copy drifts on its own schedule. The disagreement surfaces in a meeting, never in a test.

Synchronization stands in for a single source

How you'd notice: the definitions are kept aligned by a sync job, a shared spreadsheet, or a standalone semantic layer product that sits in the query path between the BI tools and the warehouse.

What it costs: sync jobs fail quietly and drift between runs. A product in the query path keeps the business logic inside its own runtime, so every query depends on it staying available, and removing it means rebuilding every definition it held.

Expressions don't survive the crossing

How you'd notice: a migration plan has a line item for "recreate calculations," and no one can estimate it.

What it costs: level-of-detail expressions, time offsets, window calculations, and filtered metrics are written in each tool's own dialect. Converting them by hand is where a large share of migration defects come from, and where much of the schedule goes.

Access policy gets rebuilt per tool

How you'd notice: row-level security exists in every BI tool and in the warehouse, maintained by different teams, with no single place to read the full policy.

What it costs: the policies diverge, and the divergence stays invisible until an access review or an incident finds it.

Agents read raw schema

How you'd notice: the AI pilot's context is a set of table and column descriptions, plus whatever the model infers from names.

What it costs: the agent assembles meaning at query time, which costs compute and tokens on every question. It also guesses wherever two columns look alike, and the guesses vary between runs.

There's no history

How you'd notice: ask what a metric's definition said six months ago. The answer involves someone's memory or a commit in a repository the BI tool doesn't use.

What it costs: every audit question about a past period becomes a reconstruction project, on a deadline set by someone outside the company.

What the Gap Actually Costs

Three costs follow from the gap.

The reconciliation tax: Count the incidents per quarter where two systems disagreed about the same metric, and the hours spent establishing which was right. Most teams have never counted, and the number will probably surprise them. That time comes out of engineering and analytics capacity, every quarter, with no end date.

The rebuild cost: Every BI or platform migration pays to recreate semantic models that already exist. The organization pays for its definitions once when they're built and again each time a vendor decision moves them. Definitions held inside a run-time product add an exit cost on top, payable the day that product leaves.

The assembly cost: Agents that build meaning from raw schema spend compute walking the graph and tokens generating SQL on every question, then spend more on retries when the answer comes back wrong. That cost scales with usage, so it grows exactly as AI adoption succeeds.

Audit preparation is where all three surface at once. It runs as a project with a staffing plan, when it could be a query someone runs on a Tuesday.

A Diagnostic You Can Run This Week

Pick one metric that matters: a figure in a board deck, a number in a regulatory filing, or a KPI an executive watches weekly. Run these six questions against it using the tooling you already own.

Count the passes. The pattern matters more than the score.

Failures clustered in questions 1 and 2 point at definitions that live in the tools. Failures in 3 and 4 point at definitions that can't leave the tools. Failures in 5 and 6 mean the definitions were never built to be read by anything other than a person in the present.

Then run the same six against a second metric owned by a different team, ideally one that touches a legacy BI tool. If the two scores match, the problem is how definitions are held across the estate. If they differ, the problem may be one tool.

Write the answers down. In a vendor evaluation six months from now, this becomes the list of things you insist on seeing demonstrated against your own models.

What Comes Next

Two things follow from the score.

The first is architectural. There are only a few places a definition can be held: inside each BI tool, in a run-time service in the query path, inside one data platform's native semantic objects, or in a governed model that compiles into the native format of every system that consumes it.

Where the definition is held decides which of the requirements above are reachable at all.

A definition copied into each tool fails the first requirement by construction. A definition held in a run-time service fails the exit test by construction. A definition held natively in one warehouse passes for that warehouse and leaves every other system where it was.

The second is operational. Every failure above is a decay problem: definitions that agreed once, policies that matched once, a migration that was supposed to be the last one. The work of keeping definitions aligned had no owner.

The practice that closes it has a name, MetadataOps: metadata management run as a continuous enterprise operation, with an owner, a lifecycle, and a quality measure. Its lifecycle runs Harvest, Model, Version, Compile, Verify, and the Compile stage is where a governed definition becomes something every consuming system actually executes. The MetadataOps Kit covers the practice, the lifecycle, and a metadata quality scoring model.

Conclusion

A metric definition has become shared infrastructure, read by BI tools, warehouses, agents, and auditors, and most enterprises still hold it the way they did when a person read every dashboard. The fix is a definition that exists once, governed and versioned, and reaches every consuming system in that system's own native format.

MetaKarta builds that into the Metadata Management Platform through Semantic Hub. Semantic Hub reverse-engineers the semantic models an enterprise already runs, from Oracle OBIEE, MicroStrategy, SAP BusinessObjects, IBM Cognos, Power BI, and Tableau, reconciles them into one governed model, and compiles it into native artifacts: Snowflake Semantic Views, Databricks Metric Views, Oracle Analytic Views, Power BI semantic models, Tableau data sources, and Looker's LookML.

Nothing sits in the query path, so the definitions keep executing if MetaKarta is ever removed. Semantic Hub shares a metadata repository with Data Lineage, Data Catalog, and Data Governance, so every compiled definition carries its lineage, its owner, and its version history.

Get in touch to learn more about how MetaKarta compiles one governed definition into every BI tool, warehouse, and agent your estate already runs.

‍