What Is Open Semantic Interchange (OSI)?

The problem it solves

Ask four tools in the same company for last quarter's revenue and you can get four numbers. Not because anyone is careless, but because the definition has been re-implemented in each of them. It is written in LookML in the BI tool, again in a dbt model, again in a Snowflake semantic view, again in a spreadsheet that the finance team actually trusts. Each copy was correct when it was written. They drift independently from the day they are created.

This has always been expensive. What changed is that AI made it dangerous. When a human sees two dashboards disagree, they investigate. When an AI agent queries one of the four definitions, it returns a confident answer in fluent prose with no indication that three other definitions existed and that it picked one arbitrarily. The cost of semantic fragmentation used to be reconciliation meetings. Now it is an agent that is wrong at machine speed and sounds certain.

The industry's answer was to agree on a shared file format. If every platform can read and write the same description of a metric, the definition can live in one place and be exchanged rather than duplicated.

What OSI actually is

OSI is a specification, not a product and not a piece of software you run. It defines a vendor-neutral, extensible way to represent the constructs a semantic layer is made of, so that a model written by one tool can be interpreted consistently by another, including by agentic applications.

The constructs it covers are the ones you would expect: data sets, metrics, dimensions, relationships between entities, and contexts. Models are expressed in YAML or JSON, which means they are diff-able, reviewable in a pull request, and readable by both a person and a machine.

Snowflake launched the initiative and published the first version of the specification on 27 January 2026, distributed on GitHub under the Apache 2 license, with a stated intention to move to neutral, foundation-led governance as it matured. That has now happened: the project continues at the Apache Software Foundation as Apache Ossie, currently incubating.

Who is behind it

The membership is the reason to take it seriously, because a semantic interchange format is only worth as much as the number of tools that read it. The working group has grown past thirty organizations and spans the categories that would need to agree for a standard like this to mean anything.

Direct competitors agreeing on a file format is unusual, and it is the strongest signal that semantic fragmentation had become a problem none of them could solve alone.

OSI, semantic layers and context layers

These three get used interchangeably and they are not the same thing. The distinction is worth being precise about, because it determines what you still have to build.

A reasonable way to hold it: OSI is the shipping container. The semantic layer is the warehouse. The context layer is what an AI agent talks to. All three are empty until someone supplies the actual definitions.

What OSI does not do

This is where expectations most often break, so it is worth stating plainly.

It does not define your metrics. The specification gives you a grammar for expressing a metric. It has no opinion on whether your company's revenue excludes intercompany transactions. Adopting OSI on Monday leaves you with an empty, beautifully portable file.

It does not execute anything. OSI is an interchange format. Query planning, caching and access control remain the job of whatever engine consumes the model.

It does not resolve disagreements. If three definitions of active customer exist in your organization, OSI will happily represent all three. Deciding which is canonical is a governance decision that no file format can make.

Support is still arriving. The specification is young and members are implementing read and write support on their own timelines. Check what your specific platform supports today rather than assuming the membership list implies shipped functionality.

Getting an OSI model when you do not have one

The awkward part of any interchange standard is that it presumes you already have something to interchange. Most organizations do not have a complete, agreed semantic model sitting ready to export. That is the actual bottleneck, and the standard does not address it.

There are three realistic ways to fill it. You can author it by hand, convening stakeholders and writing definitions, which is thorough and reliably takes months. You can convert what already exists in LookML, dbt models or BI metadata, which is fast but inherits whatever fragmentation is already in those tools. Or you can recover it from evidence, mining the SQL query history to extract the metric formulas, filters and join paths the business demonstrably uses, then adjudicating the conflicts that surface.

The third is the approach we take at Momenta, and the reason is that it starts from what the business actually does rather than what people recall in a meeting. The output is emitted as an OSI semantic model alongside native formats for Snowflake, Databricks and dbt, so the definitions stay portable from the moment they are created.

Why this matters more because of AI

Semantic standards have been proposed before and mostly failed, because the pain they addressed was tolerable. Analysts reconciled the numbers, dashboards carried footnotes, and everyone lived with it. The reason this attempt has attracted competitors who agree on very little else is that AI removed the tolerance.

A human analyst handed an ambiguous metric asks a question. A language model handed an ambiguous metric picks one interpretation and writes a confident paragraph about it. The failure is silent, it is fast, and it is reproduced everywhere the agent is deployed. Governance that used to happen after the query, when someone sanity-checked the output, now has to happen before the query, in the definitions the agent is allowed to draw from.

That is why an interchange format matters more than it used to. An agent does not live inside your warehouse. It calls BI tools, notebooks, applications and APIs. If the definition of revenue is trapped inside one platform's modeling syntax, every other surface the agent touches is improvising. A portable model is what lets the same governed definition follow the agent wherever it goes.

Should you adopt it now?

The honest answer depends less on the specification and more on where you are.

If you have no semantic model yet, the standard is not your bottleneck and adopting it changes nothing on its own. Build the definitions first. What OSI should influence is the format you write them in once you have them, so you do not commit the canonical version to a single vendor's syntax and pay to undo that later.

If you already have a mature model in one platform, treat OSI as an export target rather than a migration. There is little reason to move working definitions out of a system that executes them well. There is good reason to be able to emit them in a form that other tools and agents can read.

If you are choosing tooling right now, membership in the working group is a reasonable signal of intent but not of capability. Ask vendors the narrower question: can your product import and export OSI models today, and which parts of the specification are covered? A roadmap commitment and shipped support are different purchases.

If you are running AI agents on enterprise data, this is the case where the standard pays off soonest, because the number of surfaces that need the same definition is highest and growing.

FAQ

What does OSI stand for? Open Semantic Interchange. It is an open specification for exchanging semantic models between analytics, BI and AI tools, launched by Snowflake and now developed at the Apache Software Foundation as Apache Ossie.

Is OSI the same as Apache Ossie? Yes. Apache Ossie is the continuation of the Open Semantic Interchange initiative under Apache Software Foundation governance, where it is currently incubating. If you find documentation under either name, it refers to the same specification.

When was the OSI specification released? The first version was published on 27 January 2026, distributed on GitHub under the Apache 2 license. The working group has described it as a starting point expected to evolve with community feedback rather than a finished standard.

What file format does OSI use? YAML or JSON. Both are text-based, so a semantic model can be version-controlled, reviewed in a pull request and diffed like any other code artifact.

What does the OSI spec actually define? The semantic constructs a model is built from: data sets, metrics, dimensions, relationships and contexts, described in a way that different tools and agentic applications can interpret consistently.

Who supports OSI? The working group has grown past thirty organizations, including Snowflake, Databricks, dbt Labs, Salesforce, Alation, AtScale, Coalesce, Collate, Sigma, Omni, Hex, Qlik, ThoughtSpot, Lightdash, JetBrains, Google and AWS. Support in the specification and shipped support in a given product are different things, so verify the latter for your own stack.

Does OSI replace the dbt Semantic Layer or Snowflake semantic views? No, it complements them. Those are systems that execute governed definitions at query time. OSI is the portable format for moving definitions between such systems, so a metric defined once does not have to be rewritten for each.

Do I need OSI if we only use one platform? Less urgently, but it is still cheap insurance. Semantic models written directly in one vendor's syntax are the hardest thing to migrate later, and the same portable model is what feeds AI agents and BI tools that sit outside the warehouse.

How does OSI relate to MCP? They solve adjacent problems. OSI standardizes what a semantic model looks like as a file. The Model Context Protocol standardizes how an AI agent requests context at runtime. A common pattern is an OSI-described model exposed to agents over MCP.

How do we produce an OSI model from what we have today? Three options: author definitions by hand with stakeholders, convert existing LookML or dbt metadata, or extract them from SQL query history and adjudicate the conflicts. The first is slow, the second inherits existing fragmentation, and the third starts from evidence of what the business actually measures.