Portable Meaning: The OSI Bet
“A vendor-neutral spec finally lets a metric definition travel between tools. But portable meaning is a bet you have to earn — and the thing that earns it isn't the syntax.”
For most of data's history, a metric definition was a local artifact. "Net revenue" meant whatever the SQL in your BI tool said it meant, and moving to a different tool meant rewriting it — quietly changing it in the process. Meaning didn't travel. It got re-derived, tool by tool, slightly differently each time. That's how a definition forks without anyone deciding to.
The last two years put a real dent in that. In September 2025, Snowflake launched the Open Semantic Interchange — a vendor-neutral, YAML-based spec for how semantic models are defined and shared — alongside Salesforce, dbt Labs, BlackRock, and RelationalAI. Within months the coalition passed three dozen members, including Databricks, Google, and AWS. dbt Labs open-sourced MetricFlow under Apache 2.0 as a reference implementation, and the v0.1 spec went live in early 2026.
When that many competitors agree meaning needs a shared language, it tells you where the real value moved: to the definition, not the tool that renders it. The bet is that your metric definitions become portable — write them once, in the open format, and carry them from tool to tool without re-deriving.
That's the promise. Here's the asterisk.
Portable is a bet, not a guarantee
A standard existing is not the same as your metrics being portable. Two things have to be true, and the second one usually isn't yet.
First, your definitions have to live in the portable layer — the open spec, or a metrics-as-code tool that emits it — instead of baked into one tool's proprietary surface. Second, the tools on both ends have to implement the spec the same way.
The live tension is the warehouse-native semantic layers. Snowflake's Semantic Views and Databricks' Metric Views are genuinely convenient — you define a metric where the data already lives, and the warehouse computes it natively. But a semantic definition written into Snowflake doesn't move to Databricks by copying a file, and vice versa. The convenience and the lock-in are the same feature: the definition is close to the engine because it's coupled to the engine.
So "we support the open standard" and "your metrics are portable today" are different sentences. The first is a direction. The second is something you have to engineer, verify, and keep verifying as each vendor's implementation drifts.
The DSL is not the skill
Here's the part that matters for anyone deciding what to learn. It's tempting to treat this as a language war — learn the winning metrics DSL, bet on the right syntax. That's the tool-shaped version of the question, and it's the wrong one.
The syntax is the easy part. What OSI and MetricFlow and every warehouse-native layer are all trying to serialize is the same underlying thing: what a metric means, at what grain, with which filters and exclusions, joined along which valid paths. Get that modeling right and expressing it in any given DSL is an afternoon. Get it wrong and no format saves you — you've just made a forked, ambiguous definition portable, which means you can now be wrong in more places at once.
This is the whole thesis wearing a standards-body badge. The model is the product; the spec is just a way to ship it somewhere else without losing it in translation. The durable skill was never the DSL. It's the judgment the DSL is trying to capture.
The test
Ask one question about your own stack: could you regenerate your top ten metrics in a different tool tomorrow?
Not "is there a standard" — could you, with the definitions you actually have, reproduce those ten numbers somewhere else and get the same answers? If the definitions live in one governed, portable layer, the answer is close to yes. If they're scattered across a BI tool's saved measures, a warehouse's native views, and three analysts' heads, the answer is no — and the standard doesn't help you until you fix that.
The distance between your "yes" and your "no" is your lock-in — measured not in vendor contracts, but in how much meaning you'd have to re-derive to leave. The OSI bet only pays out for teams who did the modeling. For everyone else, portable meaning is a spec they can't use yet, because they never wrote the meaning down in the first place.