How to adopt Apache Ossie without your metric definitions drifting again

Why does the same metric still mean different things across Power BI, Databricks and your AI agents?

Because each platform holds its own copy of the logic, and nothing keeps those copies aligned. Net revenue is a DAX measure in a Power BI semantic model, a metric view in Databricks, a SQL query behind another dashboard and, more and more often, whatever an AI agent infers from column names. Each version was right when someone wrote it. Over time, one starts excluding cancelled orders and another doesn't.

Ossie's own framing names four symptoms: metric drift across dashboards, costly manual reconciliation, unreliable grounding for AI, and complex point-to-point integrations between tools. AI agents make the third one visible: an agent that finds three revenue measures has no way of knowing which one Finance approved. We cover that pattern in why your AI chatbot gives different numbers than your Power BI dashboards.

What is Apache Ossie, in plain terms?

Apache Ossie is an open specification for describing semantic metadata, so that metrics, dimensions, relationships and business context can move between BI, analytics and AI platforms without being rebuilt by hand.

Snowflake introduced it as Open Semantic Interchange (OSI) in September 2025, together with a group of BI, catalog and AI vendors. The specification was published under Apache 2.0 in January 2026. In July 2026 the project was accepted into the Apache Incubator and renamed Apache Ossie. More than 70 organisations are listed in its ecosystem, including Snowflake, Databricks, Microsoft, Salesforce, dbt Labs, Qlik, ThoughtSpot and Tabular Editor. Databricks maintains converters between its metric views and Ossie, and dbt Labs open-sourced MetricFlow as a reference implementation.

An Ossie model is a declarative YAML file with four building blocks:

• Datasets: business entities that map to a table, view or query.
• Fields: row-level attributes, which can be flagged as a dimension or a time dimension.
• Metrics: aggregations, which can span several datasets.
• Relationships: the join keys between datasets.

Models, datasets, fields and metrics each carry a description and an ai_context with instructions, synonyms and examples for AI agents. The detail that matters most for adoption: one metric can hold its expression in several dialects, including ANSI_SQL, DAX, DATABRICKS, SNOWFLAKE, TABLEAU, MDX and BIGQUERY. Vendor-specific details go into custom_extensions.

Ossie is still incubating and the specification is evolving. The Apache Software Foundation notes that incubation doesn't necessarily reflect the completeness or stability of the code. That's a reason to start with a scoped set of metrics, not a reason to wait. You can read more at ossie.apache.org and in the specification on GitHub.

What does Ossie standardise, and what does it leave to you?

Ossie standardises how a metric is written down and exchanged. It doesn't decide what the metric means, who owns it or who approves a change.

What Ossie gives you:

• one structure for metrics, dimensions and relationships
• one metric with an expression for each platform
• descriptions and AI context in the same file
• an open format that any vendor can read and write

What it leaves to you:

• agreeing what "net revenue" counts, and what it leaves out
• naming the person who can change that definition
• approving changes and keeping their history
• keeping the business meaning and every platform expression in sync

The specification has no fields for ownership, stewardship, certification or approval. That's a sensible choice for an exchange format, but it means adopting Ossie isn't only a technical project. If two departments disagree about revenue today, writing both versions in YAML won't settle it. You'll simply have the disagreement in a cleaner format.

The agreement is the part most organisations underestimate, and it usually already has a home: the business glossary, where a term has a definition, an owner and an approval trail. If you haven't settled your KPIs yet, start with one KPI, one definition.

Who should own Ossie definitions: business or IT?

Both, for different parts: the business owns the meaning, and the data team owns the expressions. A finance lead decides that net revenue excludes VAT and cancelled orders. An analytics engineer writes that rule in DAX for the Power BI model and in SQL for the Databricks metric view. Neither can do the other's job well.

The risk is splitting the two across different places. If the business definition lives in a wiki and the expressions live only in a Git repository, nobody notices when one changes and the other doesn't. Keep both in one record, and send a change to either through the same owner review. That way the sentence Finance approved and the code that runs in each platform can't quietly drift apart.

How do you know your reports actually follow the Ossie definition?

You check them, and you keep checking, because publishing a definition doesn't change the measures that already exist. Most Power BI estates already contain dozens of measures and metric views that calculate some version of your core KPIs. Writing the agreed definition in Ossie doesn't touch any of them.

Drift also keeps coming back, for ordinary reasons:

• Copied measures: a team copies a semantic model and adjusts one measure for a local need.
• Local tweaks: an analyst adds a filter "just for this report" and keeps the same name.
• New reports: someone builds a new measure from scratch instead of reusing the agreed one.
• Changed definitions: the owner updates the rule, and older implementations stay as they were.

A one-off audit finds today's differences and misses next month's. To turn Ossie into a definition that is enforced, not a document you publish once, compare catalogued measures against the agreed calculation logic on an ongoing basis, and flag the ones that don't conform so their owners can act.

Where should your Ossie definitions live?

For most organisations, the practical answer is a business glossary for the agreed meaning and approval, with Git alongside it for engineering workflows. Here's how the main options compare.

Git is excellent for engineers: version control, code review and automated deployment. Keep it. What it doesn't give you is a place where Finance can read the sentence, challenge it and approve it. The realistic setup is often both: the glossary as the governed record, and the exported Ossie YAML in Git for pipelines and deployments.

A practical framework: Agree it, Translate it, Approve it, Publish it, Monitor it

• Agree it: the business owner and the people who use the metric agree the definition in plain language in the glossary: what's counted, from which date, and what's left out.
• Translate it: the data team writes the Ossie metric, with an expression for each platform you use, plus a description and AI context.
• Approve it: the named owner approves the meaning and the expressions, and every change is kept in the history.
• Publish it: export the definition as Ossie YAML to the platforms and AI agents that need it.
• Monitor it: flag the measures and metric views that no longer conform, so their owners can fix them.

What to do first

Don't start with your whole data model. Pick the 10 to 20 KPIs that already cause arguments, usually the ones on the monthly management report. And don't start from a blank page either: the measures and metric views you already have show how each KPI is calculated today, including where the versions differ.

1. List the KPIs that appear on management reports and that people dispute.
2. Collect the DAX measures, metric views and SQL that calculate them today.
3. Turn what you find into one draft glossary term per KPI, and name an owner.
4. Let the owner agree the definition, add the Ossie expressions and approve them.
5. Export those terms as Ossie YAML and check existing reports against them.

When the first batch holds, add the next one. A small set of definitions that people trust is worth more than a complete model nobody has agreed.

Where dScribe fits

In dScribe, the Ossie definition sits inside the business glossary term, next to the business definition, the owner and the approval history. Business people agree the meaning, the data team adds the platform expressions, and both live in one governed record. Take one term, Net revenue:

• Business definition: "Invoiced revenue after discounts, excluding VAT and cancelled orders."
• Owner: Finance.
• Approval history: every change to the definition or an expression, with who approved it and when.
• Ossie definition: the metric with an expression per platform, as below.

metrics:
  - name: net_revenue
    description: Invoiced revenue after discounts, excluding VAT and cancelled orders.
    expression:
      dialects:
        - dialect: ANSI_SQL
          expression: SUM(CASE WHEN orders.status <> 'cancelled' THEN orders.amount - orders.discount END)
        - dialect: DAX
          expression: CALCULATE(SUMX(orders, orders[amount] - orders[discount]), orders[status] <> "cancelled")
    ai_context:
      synonyms:
        - "net sales"
        - "revenue after discounts"

The snippet is illustrative and follows the current draft of the Ossie specification.

Here's how that term moves through its life in dScribe:

1. Start from what exists. dScribe scans the existing "Net revenue" metric view in Databricks and suggests a draft glossary term.
2. Agree and approve. Finance agrees the business definition and approves it.
3. Translate and export. The data team adds the DAX expression, which goes through the same owner review as the business definition. dScribe exports the term as Ossie YAML, on its own or together with a set of terms.
4. Serve AI agents. An AI agent asking about net revenue gets the approved definition, owner and formula through dScribe's MCP server.
5. Flag drift. A "Net Revenue" measure in a regional Power BI report still includes cancelled orders. dScribe flags it as not conforming to the linked term, so its owner can fix it before the numbers diverge in a meeting.

The business sees and approves the sentence, the data team maintains the expressions, and Power BI, Databricks and AI agents read from the same approved record. dScribe also tells you when a report doesn't. Terms are linked, not copied, to the datasets, columns and reports that use them, through connectors for Power BI, Microsoft Fabric, Databricks, Snowflake, dbt, Tableau, Qlik and Looker. The same definition shows up in dScribe search, in the browser extension on Power BI reports and through the open API. For the wider picture, see how to create one source of truth that both people and AI use.

In short

Ossie gives every platform the same language for a metric. Your glossary decides what that metric means, and checks that every report still follows it. Agree the definition first, write it once with an expression per platform, put one owner in charge of changes, and keep checking the measures that are already out there.