What Open Semantic Interchange is
Open Semantic Interchange, or OSI, is an open specification for describing business metrics, dimensions and relationships in a single, tool-independent format. Snowflake announced the initiative on September 23, 2025, alongside a group of launch partners that included Salesforce, dbt Labs, BlackRock, RelationalAI, Alation, Atlan, Cube, Hex, Honeydew, Mistral AI, Omni, Select Star, Sigma and ThoughtSpot (Snowflake, 2025). The specification itself, published under an Apache 2.0 license, defines how a dataset, a metric, a dimension and the relationships between them should be written down so that any tool reading that file interprets "monthly active users" or "net revenue" the same way (dbt Labs, 2026).
That is a narrower problem than it sounds. OSI does not move data, query a warehouse or replace a BI tool. It standardizes the metadata layer sitting above the data: the definitions, not the numbers themselves.
Why it exists
A metric like "active customer" typically gets defined more than once inside the same company. Finance defines it one way in a planning tool. The BI team defines it slightly differently in a dashboard. A data scientist writes a third version into a notebook. Each definition lives inside its own proprietary format, tied to whichever platform created it: dbt's MetricFlow, Cube's semantic layer, LookML inside Looker, AtScale's model. Moving a metric definition from one tool to another has generally meant rebuilding it by hand.
That duplication became more expensive with the arrival of AI agents that query data directly. CIO Dive reported that without a shared semantic layer, teams can spend weeks reconciling conflicting definitions across platforms before an AI system can be trusted to answer a business question correctly (CIO Dive, 2025). Snowflake's framing, echoed by the launch partners, is that metadata has effectively been vendor-locked: real, valuable definitions trapped in a format only one tool can read (Snowflake, 2025).
OSI's pitch is to let a metric be defined once and read by whichever tool needs it, including the agents now querying warehouses directly.
How OSI differs from what already exists
Semantic layers are not new. dbt's MetricFlow, Cube, LookML and AtScale have all shipped their own metric-definition formats for years, and each works well inside its own ecosystem. The difference with OSI is that no single vendor owns the format. dbt Labs, one of the parties whose own MetricFlow format OSI is meant to eventually interoperate with, published its own explanation of the spec in January 2026, describing OSI as a common interchange layer rather than a replacement for any one company's existing semantic tooling (dbt Labs, 2026).
The coalition has kept adding members since the September launch. Domo joined in November 2025 and Strategy (formerly MicroStrategy) joined in December 2025, both confirmed through the companies' own announcements (Domo, 2025; Strategy, 2025). Qlik joined on January 27, 2026, the same day dbt Labs published its explanation of the finished v1.0 specification on GitHub (Qlik/Business Wire, 2026; dbt Labs, 2026). The specification is real and shipping. Whether the vendors that helped write it actually build support for it into their products, rather than continuing to promote their own proprietary format, is a separate and still open question.
It is worth distinguishing OSI from data contracts, another standardization effort the industry has recently converged on. A data contract governs the agreement between whoever produces a dataset and whoever consumes it upstream, in the pipeline: schema, freshness, ownership. OSI sits downstream of that, at the point where a metric gets defined for a dashboard, a report or an AI model to read. The two solve different problems and a team can adopt one without the other.
What to look at when evaluating this
For a data team deciding whether OSI is relevant right now, a few questions matter more than the press releases:
Does your BI or AI tool actually read OSI files, or just claim membership in the initiative? Joining a coalition and shipping a working import or export path are different commitments. Check the vendor's own documentation for OSI support, not just its name on the partner list.
How many metric definitions do you actually have duplicated across tools today? OSI solves a duplication problem. A team with one BI tool and one warehouse has less to gain than a team running Tableau, a notebook environment and an AI copilot against the same data, each with its own metric definitions.
Is the specification still changing? A v1.0 specification released in January 2026 is young. Teams building against it should expect revisions and should not treat early adoption as a finished integration.
What commonly goes wrong
The most common failure mode with any open specification announced by a large vendor coalition is mistaking the announcement for the outcome. A launch partner list is a statement of intent, not a shipped integration. Teams that assume every partner has working OSI support in production, based on press coverage alone, will be disappointed when they go looking for the actual import path in a specific tool.
The second failure is treating OSI as a replacement for the governance work of agreeing on definitions in the first place. The specification gives teams a common file format to write a metric definition in. It does not resolve the underlying disagreement between finance and the BI team about what "active customer" means. That conversation still has to happen; OSI just gives the resulting agreement somewhere portable to live.
It is not yet clear how many of the sixteen-plus companies that joined the initiative between September 2025 and January 2026 have shipped production support for reading or writing OSI files, as opposed to committing to the specification's governance. That distinction is the one worth tracking as the format moves past its first year.
Sources: Snowflake announcement · dbt Labs · CIO Dive · Domo · Strategy · Qlik