The rare case where competitors agreed on something. Worth knowing what they agreed to.
Last week we looked at the semantic layers every major platform now ships and found the same catch in all of them: a metric defined inside one platform is only consistent inside that platform. The answer the industry is building to that problem is an open standard for metric definitions. It began as the Open Semantic Interchange (OSI) and is now called Apache Ossie.
This post explains Apache Ossie in plain terms, a little over a year after it launched. It’s written for the people who will be asked to rely on it: data leaders, governance teams and anyone signing a contract for a semantic layer. We’ll cover what it is, what it changes for a buyer, what it doesn’t cover yet, and what to ask vendors who say they support it.
What Apache Ossie is
Apache Ossie is a vendor-neutral file format for describing business metrics and the data behind them. A definition written in it says, in YAML or JSON:
- Datasets: which tables or views the metric reads, their keys and fields.
- Relationships: how those datasets join to each other.
- Metrics: the named calculation, such as total revenue or win rate, with a description.
- AI context: synonyms, instructions and examples that help an AI assistant use the metric correctly.
The idea is that a definition written once can move between a warehouse, a BI tool, a CRM and an AI agent without being rewritten by hand in each one. Think of it as a common file format for “what we mean by this number”, in the way PDF is a common format for a document.
How the open semantic interchange got here
The timeline is short, which matters for how much you should rely on it today:
- September 2025: Snowflake launched the Open Semantic Interchange with launch partners including Salesforce, dbt Labs, BlackRock and RelationalAI, alongside BI and catalog vendors such as Sigma, ThoughtSpot, Hex, Atlan and Alation.
- October 2025: dbt Labs moved MetricFlow, its metric engine, to the Apache 2.0 licence and aligned it with OSI.
- 2026: the first versions of the specification were published, and converters for individual tools began to be merged.
- July 2026: the project was accepted into the Apache Incubator and renamed Apache Ossie, partly to avoid confusion with other projects that use the OSI initials. More than 50 organisations now contribute.
“Incubating” is an Apache term with a specific meaning: the project is being set up under Apache governance and hasn’t made its first official Apache release yet. The specification itself is still before version 1.0, and the next draft changes the file layout, so files written for the current release won’t validate unchanged against the next one.
What changes when metric definitions are portable
For a buyer, a working standard changes three things.
Switching costs fall. Today, every metric written in a platform’s own format is a small reason not to leave that platform. A few hundred definitions reviewed and signed off by finance become a lock-in nobody chose. If those definitions can be exported in an open format, they belong to you rather than to the tool that holds them.
Agents from different vendors can share a vocabulary. A CRM agent and a warehouse assistant reading the same Ossie definition of “pipeline coverage” are much more likely to return the same number than two agents each working it out from raw tables.
Governance gets one artefact to review. Instead of checking a calculated field in one tool and a saved query in another, a governance team can review one definition file and know where it is used.
What it doesn't cover yet
A fair reading of the specification and the project’s own roadmap shows real gaps. None of them is a reason to ignore Ossie. All of them are reasons not to treat “supports Ossie” as the end of a vendor conversation.
- Some common metric types can't be expressed yet. Derived metrics (a metric built from other metrics), cumulative metrics and filtered metrics are listed as missing. Win rate, conversion rate and year-to-date figures are often exactly these types.
- The same definition can still produce different numbers. The specification declares how datasets relate but doesn't yet define how a tool must evaluate a query across those relationships, and it has no way to state whether a join is one-to-one or many-to-many. Two tools can read the same file and compute different results. Proposals to fix both are open.
- Trust and approval aren't part of the standard. There are no fields for who approved a definition, when it was last checked, or where the data came from. Those still live in your own process and tooling.
- Access control sits elsewhere. Who is allowed to see a metric is handled by catalogs and platforms, not by the definition format.
- Conversion can lose detail. Moving a definition from a tool's native format into Ossie and back can drop parts the standard can't represent. Some converters drop them with a warning, so read the warnings.
Converter or native support? How to read vendor claims
“We support Ossie” can mean very different things, and the difference matters to you:
- Native support: the product reads and writes Ossie files itself. dbt Core 1.12, for example, can import Ossie documents directly, although only for the 0.1 versions of the spec.
- A converter: a separate translation step, usually in the Ossie repository, that turns the vendor's own format into Ossie and back. Converters exist for dbt's MetricFlow, Salesforce, GoodData and others. They are useful, but someone has to run and maintain them, and detail can be lost along the way.
- An announcement: a roadmap slide. Useful for direction, not for planning.
Four questions to add to your vendor checklist
Last week we suggested three questions for any semantic layer vendor: can I export my definitions, can another tool use them unchanged, and what happens to them if I leave. Apache Ossie lets you sharpen them with four more:
- Which version of the Ossie specification do you read and write today? Ask for a version number, not "we support it".
- Is that native, or through a converter? If it's a converter, who maintains it and where does it run?
- Which of our metrics can't you represent in Ossie? Bring a real example, such as a ratio or a year-to-date measure, and ask to see the exported file.
- If two tools read the same Ossie file, how do you guarantee they return the same number? A specific answer here tells you a lot about how seriously the vendor has engaged with the standard.
Where this leaves you
Apache Ossie is the most credible attempt so far to make metric definitions portable, and the amount of industry backing it has is unusual. It is also early. The practical position for most organisations is to keep the authoritative version of each metric somewhere you control, in a form that can already be converted to Ossie, and to plan on adopting the standard more fully as it reaches a stable release and more tools read it natively.
Portability is becoming possible. It isn’t yet automatic, and the work of agreeing what a metric means inside your organisation still has to happen first.
Frequently asked questions
What is Apache Ossie?
Apache Ossie is an open, vendor-neutral format for defining business metrics, the datasets they read and how those datasets join, written in YAML or JSON. It started as the Open Semantic Interchange (OSI) and was renamed when it entered the Apache Incubator in July 2026.
Is Apache Ossie the same as the Open Semantic Interchange (OSI)?
Yes. OSI was the project’s original name when Snowflake launched it in September 2025 with partners including Salesforce and dbt Labs. It became Apache Ossie in July 2026, partly to avoid confusion with other projects that use the OSI initials.
Is Apache Ossie ready for production use?
Parts of it are usable now, mainly for exporting and importing simple metric definitions between tools that support it. The specification is still before version 1.0, some metric types can’t be expressed yet, and file layouts are changing between versions, so plan on it as a standard to build towards rather than one to depend on fully today.
Does Apache Ossie replace a semantic layer?
No. Ossie is a format for describing metric definitions so they can move between tools. You still need a semantic layer, or a metric engine, to store those definitions, compile queries from them and apply access control.
