Open Semantic Interchange: the standard that stops your Data 360 metrics from being trapped in one tool

Here’s a problem every mature data team has and almost nobody has solved. “Net revenue” is defined in Tableau Semantics for the analysts. It’s defined again in a dbt model for the pipeline. There’s a third version living in a hand-rolled Snowflake view that finance trusts, and a fourth encoded in a Power BI measure nobody remembers writing. Four definitions, four subtly different numbers, and now you want to ground an agent on “revenue”, so the agent inherits whichever one it happened to be pointed at, and confidently reports a figure that disagrees with the board deck.

This is semantic fragmentation, and it used to be a governance annoyance. In the agentic era it’s a correctness problem, because an agent that can’t be told the single authoritative definition of a metric will invent one. The industry’s answer arrived in 2026, and it’s worth a Salesforce data team’s attention even though it isn’t a Salesforce product: Open Semantic Interchange (OSI), now Apache Ossie, a vendor-neutral, YAML-based standard for expressing metrics, dimensions, and relationships so that one definition can travel across every tool that touches your data. This post is what it is, the structure of an actual Ossie model, what it pointedly does not do, and why it matters for Data 360 specifically.

The fragmentation OSI is built to kill

Every serious analytics tool has grown its own semantic layer: Tableau has Tableau Semantics, dbt has its Semantic Layer and MetricFlow, there’s LookML, Cube, AtScale, Power BI’s model, and a warehouse view for everything the tools couldn’t express. Each one is a place to define what “active customer” or “gross margin” means. The trouble is that none of them can read the others. Your metric definitions are portable the way a document is portable when everyone uses a different word processor and none of them opens the others’ files.

The cost of that was tolerable when semantics served dashboards. Analysts reconciled the differences by hand and moved on. It stopped being tolerable the moment metrics started feeding AI. An agent doesn’t reconcile; it picks a source and speaks with total confidence. Two agents grounded on two tools’ definitions of the same metric will give two answers to the same question, and the business has no way to know which, if either, is right. We wrote about the semantic layer as the thing that stops an agent inventing your metrics; OSI is the layer above that, the thing that stops each tool inventing its own version of the metric in the first place.

The precedent is exact, and it’s one Salesforce architects already know. Storage used to be locked in per-vendor formats until Apache Iceberg made an open table format that every engine could read, which is why Data 360’s own lakehouse runs on Iceberg and zero copy works at all. OSI is Iceberg’s idea applied one layer up: not an open format for the bytes, but an open format for the meaning.

What OSI is (and who’s behind it)

OSI began in September 2025 as an initiative announced by Snowflake, Salesforce, and dbt Labs alongside a dozen-plus launch partners. The v0.1 specification went public under the Apache 2.0 license in early 2026, and the coalition compounded from seventeen launch organizations to more than fifty. Databricks, ThoughtSpot, Collibra, AtScale, Atlan, GoodData, Qlik, Informatica, and a long tail of the analytics ecosystem. In June 2026 the project was donated to the Apache Software Foundation, renamed Apache Ossie (to avoid colliding with the several other things called “OSI” in open source), and entered the Apache Incubator. The current spec is an in-progress draft; the direction is a neutral, community-governed standard rather than any one vendor’s format.

That governance detail is the strategically important part. A metric-definition standard controlled by a single warehouse vendor would just be that vendor’s lock-in wearing an “open” badge. Housing it at Apache, with Snowflake and Databricks and Salesforce and dbt at the table, is what makes it credible as neutral ground, the same reason Iceberg’s Apache governance mattered. The breadth of the roster is the signal: these companies compete hard, and they agreed on this because AI made the fragmentation everyone’s problem at once.

Mechanically, Ossie is a single specification, expressed in YAML or JSON, that any tool can read and write. It defines a vendor-neutral way to describe your business metrics, dimensions, relationships, and the broader context around them, in a document a human can read and a machine can validate. That’s the whole idea: write the definition once, in Ossie, and any participating tool can import it as its own.

The structure of an Ossie model

Concreteness helps here, because “semantic standard” is abstract until you see the shape. An Ossie document has a root semantic_model containing datasets, the relationships between them, and the metrics defined on top, with expressions carried per SQL dialect so the same definition can materialize correctly in different engines. A trimmed model for a revenue metric looks like this:

version: 0.2.0.dev0
semantic_model:
  - name: sales
    description: Core sales and revenue semantics
    ai_context: >
      Net revenue is booked revenue minus refunds. Use this metric for any
      question about "revenue" unless the user explicitly asks for gross.
    datasets:
      - name: orders
        source: analytics.sales.orders
        primary_key: [order_id]
        fields:
          - name: order_id
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: order_id
            datatype: String
          - name: order_date
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: order_date
            datatype: Date
            dimension:
              is_time: true
          - name: net_amount
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: gross_amount - refund_amount
            datatype: Decimal
    relationships:
      - name: order_to_customer
        from: orders
        to: customers
        from_columns: [customer_id]
        to_columns: [customer_id]
    metrics:
      - name: net_revenue
        description: Booked revenue net of refunds
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: "SUM(orders.net_amount)"
        datatype: Decimal
    custom_extensions:
      - vendor_name: TABLEAU_SEMANTICS
        data: '{"format": "currency", "currencyCode": "USD"}'

Four things in that document are worth calling out, because they’re where the design earns its keep:

ai_context is a first-class field, not an afterthought. The spec gives you a place to write the natural-language guidance an agent needs: “use this metric for revenue unless the user asks for gross.” That’s the standard acknowledging out loud that the primary consumer is now an LLM, not just a BI renderer. The definition and the instructions for using it travel together.
Expressions are carried per dialect. net_amount is gross_amount - refund_amount in ANSI_SQL, and the format allows other dialects alongside it. This is how one definition stays correct across engines that don’t speak identical SQL, and, as we’ll see, it’s also where the honesty about limits comes in.
Relationships are explicit. order_to_customer maps from_columns to to_columns the same way a foreign key would, so a tool importing the model knows how the datasets join without guessing, the guess being exactly what produces a wrong number in an ungoverned agent.
custom_extensions is the escape hatch. Vendor-specific metadata (Tableau’s currency formatting, here) rides in a namespaced block, so a tool can carry its own richness without breaking the portable core. That’s the pragmatic detail that makes adoption plausible instead of all-or-nothing.

What Ossie deliberately does not do

This is the part that separates people who understand the standard from people who’ll be disappointed by it. Ossie does not store your data, query your data, or replace your warehouse, lakehouse, BI tool, or semantic-layer product. It is not a runtime. It is not an engine. It computes nothing.

The clean analogy from the project itself: Ossie is to semantic layers what PDF is to word processors. A PDF doesn’t replace Word or Google Docs. It’s the neutral format they agree to exchange so a document written in one is readable in another. Ossie is the interchange format your tools use to agree on what a metric means; each tool still executes the query in its own engine. Data 360 still runs the calculation, Snowflake still runs its own, dbt still builds its models, but they can all import the same definition of net_revenue instead of each maintaining a private one that drifts.

That framing dissolves the two most common misconceptions in one stroke. It is not a competitor to Tableau Semantics or the dbt Semantic Layer, those are runtimes that can speak Ossie. And it will not, by itself, make your metrics consistent. It gives you a format in which to express a single definition; agreeing on that definition across teams is still human work the format can’t do for you.

What this means for a Salesforce data team

Salesforce is a founding member, and the connective claim is straightforward: Data 360’s semantic layer, Tableau Semantics, is where you define governed metrics, and OSI is the standard by which those definitions become portable. Importable from a warehouse, exportable to the rest of the stack. Three practical consequences follow for a Salesforce shop.

It’s an answer to the lock-in question you should already be asking. Every time you invest in modeling metrics inside one vendor’s semantic layer, the reasonable worry is that you’re pouring concrete, that the definitions are now trapped there. A credible open interchange standard is the hedge: model in Tableau Semantics, and the definitions aren’t a hostage, because the format they can be expressed in is neutral and community-governed. That changes the risk calculus of committing to the Salesforce semantic layer, and it’s the honest counterpoint to the platform-vs-warehouse debates that usually get framed as all-or-nothing.

It’s the missing piece of cross-platform grounding. If your architecture spans Data 360 and a warehouse (and most do, which is the entire premise of zero copy) then grounding an agent consistently means the agent has to see the same metric definition regardless of which side computed it. OSI is the mechanism by which “net revenue” defined once is the “net revenue” the agent grounds on everywhere, instead of one definition in Salesforce and a different one in Snowflake feeding two agents that disagree.

It reframes the metric-definition project as an asset, not a tool artifact. Once your definitions live in a portable standard, they stop being a byproduct of whichever BI tool you happened to buy and start being a governed corporate asset: versioned, reviewed, and deployable like the semantic models already are in Data 360, but now without the implicit “…as long as you stay on this tool” clause.

The honest caveats

Temper the enthusiasm with three real limits, because a standard finalized this recently has not yet met production at scale.

It’s early. The spec is an incubating Apache project on an in-progress draft, and “fifty vendors signed a press release” is not the same as “fifty tools ship solid import/export you can rely on.” Import/export fidelity will be uneven for a while. Treat OSI today as a direction to architect toward and to ask your vendors about on roadmaps, not a switch you flip across the estate next quarter.

Dialect translation is hard. Carrying an expression per SQL dialect works cleanly for SUM(net_amount). It gets thorny fast for semantics that don’t translate one-to-one across engines: window functions, semi-additive measures, time-zone handling, null semantics. The format has a place to put multiple dialects precisely because one expression often won’t be correct everywhere, and filling those in faithfully is work the standard enables but doesn’t do for you.

The hard part was never the format. The reason four definitions of “net revenue” exist isn’t that nobody had a YAML file. It’s that finance, sales ops, and analytics never agreed on whether refunds and intercompany eliminations are in or out. OSI gives you an excellent place to write down the agreement. It does not produce the agreement. If your organization can’t get to one definition of a metric, a portable format just lets you export the disagreement to more tools, faster.

What to do now

You don’t adopt OSI as a project this quarter; you position for it. Keep defining governed metrics where your agents and analysts consume them, for a Salesforce team, that’s Tableau Semantics in Data 360, and doing that work is valuable regardless of the standard’s maturity. Ask your warehouse, BI, and transformation vendors where OSI/Ossie import and export sit on their roadmaps, and weight that answer when you’re choosing where to invest in modeling. And use the standard’s arrival as the forcing function for the conversation that matters: getting finance, ops, and analytics into one room to agree on what your core metrics mean, so that when the portable format is ready to carry a single definition, you have a single definition worth carrying.

The metric layer is following storage into the open. Iceberg made your data portable; OSI is making its meaning portable. For a Salesforce team betting on Data 360 and Agentforce, that’s not a threat to the platform. It’s the thing that makes committing to the platform’s semantic layer safe, because the definitions you build there are no longer a one-way door.

Understanding the basics

What is Open Semantic Interchange (OSI)?

Open Semantic Interchange is a vendor-neutral, open-source standard, expressed in YAML or JSON, for defining business metrics, dimensions, and relationships in a single format that any participating tool can read and write. It was announced in September 2025 by Snowflake, Salesforce, dbt Labs, and others; its v0.1 spec was released under the Apache 2.0 license in early 2026; and in June 2026 it was donated to the Apache Software Foundation and renamed Apache Ossie. Its purpose is to end semantic fragmentation, the problem of the same metric being defined differently in every tool, so that one authoritative definition can travel across warehouses, BI tools, transformation frameworks, and AI agents.

Is Apache Ossie a query engine or a replacement for my semantic layer?

No. Ossie does not store data, query data, or run computations, and it does not replace your warehouse, lakehouse, BI tool, or semantic-layer product. It’s an interchange format, the neutral file those systems exchange so a metric defined in one is readable by another, analogous to how a PDF is exchanged between word processors without replacing them. Runtimes like Tableau Semantics or the dbt Semantic Layer still execute the queries; Ossie is how they can agree on the definition first.

How does OSI relate to Salesforce Data 360?

Salesforce is a founding OSI member. In the Salesforce stack, you define governed metrics in Tableau Semantics, which is part of Data 360; OSI is the standard by which those definitions become portable across the rest of your data stack and consistent for the agents that ground on them. For teams whose architecture spans Data 360 and an external warehouse, OSI is the mechanism that lets an agent see the same definition of a metric regardless of which platform computed it, and it’s a hedge against lock-in, since metrics modeled in Data 360’s semantic layer can be expressed in a neutral, community-governed format rather than being trapped in one tool.

Building a metric layer in Data 360 and want it grounded consistently across your agents and your warehouse. Without painting yourself into one vendor’s corner? Talk to us. Getting the semantic foundation right before it feeds an agent is exactly the work we do.