A data leader needs one answer first. Does a shared definition format turn any business question into governed, deterministic SQL across the whole data estate? OSI solves one part of that job. It also stops at the definition. The table below sets the scope before the detail.
Open Semantic Interchange vs semantic execution layer
| Dimension | Open Semantic Interchange (the standard) | Semantic execution layer (Colrows) |
|---|---|---|
| What it is | A vendor-neutral YAML interchange spec | A compile-then-execute engine |
| Job | Move portable definitions between tools | Resolve, prove, and govern the query itself |
| Governance | v1.0 core does not codify access policy as first-class | Compile-time RBAC + ABAC + row and column predicates |
| Execution | None. It is a format | Dialect-perfect SQL to 16+ engines |
| Maintenance | Hand-authored, tool-exported YAML | Autonomous, continuously maintained graph |
Read it this way. OSI is a shared way to write meaning down. A semantic execution layer is a compiler that proves and governs the query. The two solve different problems. For the wider evaluation frame, see the semantic layer buyer's guide 2026.
What OSI is
OSI is a standard for writing semantic definitions. It describes measures, dimensions, and metadata in one shared YAML format. The goal is portability. A definition authored for one tool should read cleanly in another.
Today every vendor stores metrics in its own shape. A Snowflake object, a dbt model, and a Cube definition all mean similar things in different syntax. OSI gives them one interchange format. You write the definition once, and any OSI-aware tool can read it. That reduces lock-in at the definition level.
The value is real. A shared format lowers the cost of moving between tools. It also gives AI and BI systems one consistent description of a metric. But note the scope. OSI describes the metric. It does not run the query that returns the number.
Timeline and status
OSI launched in September 2025. The founding group included Snowflake, Salesforce, dbt Labs, BlackRock, and RelationalAI, with more organizations following.
The v1.0 specification was released on 27 January 2026. It uses YAML and carries an Apache 2.0 license. In June 2026 the effort entered the Apache Incubator as Apache Ossie. That move placed governance of the standard under the Apache Software Foundation. The specification did not change. Only its stewardship did.
Who backs it
More than 50 organizations back OSI. The list spans the modern data stack. It includes Snowflake, Databricks, dbt Labs, Cube, AtScale, ThoughtSpot, Atlan, Salesforce, Tableau, and BlackRock.
Working converters have been merged too. There are converters for dbt MetricFlow, GoodData, Salesforce, and Apache Polaris. A converter maps an existing definition into the OSI format. That is how portability starts to become concrete rather than promised. The breadth of support is the strongest signal that OSI matters.
What OSI standardizes, and what it does not
OSI standardizes the definition format and the metadata around a metric. It gives you one way to name a measure, declare its dimensions, and attach descriptions and synonyms. That is a genuine gap in the market, and OSI fills it well.
OSI is not an execution engine. It does not plan a query, choose a join path, or emit SQL. It has no runtime. It describes intent. It does not carry it out.
The v1.0 core also does not make access policy a first-class part of the format. Row-level rules, column masks, RBAC, and ABAC are not codified in the spec. So a portable definition can travel between tools while the governance around it stays behind. This is the same distinction we draw in governance as code vs governance as semantics. A format can carry meaning. Enforcement still needs a place to run.
The reality check
Backing a standard is not the same as shipping native support for it. Many of the 50-plus organizations have signed on. Fewer have shipped a production reader and writer that round-trips real definitions without loss.
Phase-2 adoption across those platforms is the 2026 test. De-facto-standard status is targeted for 2027. So the honest position today is this. OSI is promising and moving fast. Portability is not solved yet. Do not plan a migration on the assumption that every tool already speaks OSI without friction.
Why portable definitions still leave a gap
Say you have a clean OSI definition of net revenue. It names the measure, its dimensions, and its filters. Now a question arrives. Show last-quarter net revenue by region, for a user who may only see two regions.
The definition alone cannot answer that. Something has to resolve the request into a query. Something has to choose the correct join path and prove it is valid. Something has to apply the row-level rule that hides the other regions. Something has to emit SQL in the exact dialect of the target engine. A definition does none of this. An engine does. For the theory behind that split, see what is a semantic compiler.
This is why native single-vendor objects and cross-vendor formats share the same limit. They define meaning well. They still hand execution to something else. For the single-vendor version of that question, see the Snowflake Semantic Views vs Databricks Metric Views comparison, or the wider Snowflake and Databricks semantic layer picture.
Fix the Context, Not the Model. A well-governed semantic layer that understands business context creates more reliable AI-driven analytics than fine-tuning the model itself. OSI gives that context a portable shape. A semantic execution layer compiles, proves, and governs it at run time.
How a semantic execution layer uses OSI
OSI and a semantic execution layer are complementary, not competing. One writes meaning down. The other runs it. A semantic execution layer such as Colrows is architected to sit downstream of a portable definition and do the part OSI leaves open.
The definition, however it is written, still has to land in a typed semantic graph before it can be executed. Only then can a layer add the execution work that a format cannot carry:
- Compile-time governance. RBAC, ABAC, and row and column predicates apply before the query runs. Filtered rows are never read.
- Join path proof. The compiler proves a valid join path before execution, so the query is correct by construction.
- Point-in-time reproducibility. Every answer carries an audit trail and can be reproduced as of a past moment.
- Dialect-perfect SQL. One graph compiles to the exact SQL of 16+ engines, so the same definition runs everywhere.
The runtime is one line: intent → context resolution → constrained planning → governed execution. OSI feeds the first step with portable definitions. The layer carries them through the rest. For the applied builds, see semantic layer for Snowflake and semantic layer for Databricks.
Buyer guidance
Require both. Ask a vendor for OSI alignment so your definitions stay portable and free of lock-in. Then ask for a governed execution layer that proves and enforces the query. One without the other leaves a gap.
OSI alignment protects the definition. A semantic execution layer protects the answer. If you are weighing whether to assemble this yourself, read build vs buy a semantic layer. If you are comparing formats and tools, the dbt Semantic Layer vs Cube vs AtScale breakdown shows how each stores meaning today. To see the execution side in practice, compare Colrows with the native tools.
Frequently asked questions
What is the Open Semantic Interchange?
The Open Semantic Interchange (OSI) is a vendor-neutral standard for writing semantic definitions in YAML. It describes measures, dimensions, and metadata in one shared format. The goal is portable definitions between tools. OSI launched in September 2025, and the v1.0 specification was released on 27 January 2026 under Apache 2.0.
Is OSI the same as Apache Ossie?
They are the same effort at different stages. OSI is the specification. Apache Ossie is the project name it took when it entered the Apache Incubator in June 2026. The move places governance of the standard under the Apache Software Foundation. The format itself did not change.
When did OSI v1.0 ship?
The OSI v1.0 specification was released on 27 January 2026. It uses YAML and carries an Apache 2.0 license. The spec defines how to write semantic definitions in a vendor-neutral way. It does not include an execution engine. It is a format, not a runtime.
Does OSI include access governance?
The v1.0 core does not make access policy a first-class part of the format. It standardizes the definition and its metadata. Row-level rules, column masks, RBAC, and ABAC are not codified in the spec. You still need an execution layer that enforces those controls when the query runs.
Does OSI make my semantic layer portable today?
Not yet, in practice. Backing OSI is not the same as shipping native support for it. More than 50 organizations participate, and converters exist for dbt MetricFlow, GoodData, Salesforce, and Apache Polaris. Broad Phase-2 adoption is the 2026 test. De-facto-standard status is targeted for 2027.
Who backs OSI?
More than 50 organizations back OSI. They include Snowflake, Databricks, dbt Labs, Cube, AtScale, ThoughtSpot, Atlan, Salesforce, Tableau, and BlackRock. Converters have been merged for dbt MetricFlow, GoodData, Salesforce, and Apache Polaris. The breadth of support is why the standard matters.
