TL;DR. Apache Ossie (incubating) is the new name for Open Semantic Interchange, the vendor-neutral spec for exchanging semantic models that entered the Apache Incubator on July 10, 2026 with more than 50 organizations behind it. It standardizes the definitions layer: datasets, fields, relationships, and metrics, in JSON or YAML, so that Monthly Active Users means one thing across every tool that consumes it. What it does not standardize is everything that makes a definition trustworthy: the words confidence, lineage, freshness, and provenance appear nowhere in the core spec. Definitions travel; trust does not. For AI agents, which consume definitions without the institutional knowledge a human analyst carries, that missing half is the difference between a governed answer and a confident guess.
On July 10, 2026, the Open Semantic Interchange project entered the Apache Incubator under a new name: Apache Ossie. The rename is cosmetic, chosen to stop colliding with the two other OSI acronyms everyone in this industry already carries. The move underneath it is not cosmetic. A spec that began as a Snowflake-led initiative in September 2025, with dbt Labs, Salesforce, and BlackRock among the launch partners, is now governed by the Apache Software Foundation: public mailing lists, votes on spec changes, committership earned by contribution rather than badge. The contributor list has grown from 17 launch partners to more than 50 organizations, and it now includes Databricks, which is notable because Snowflake and Databricks agreeing on a metadata format is not a frequent event.
The problem Ossie exists to solve is old and real. Every BI tool, query engine, and now every AI agent framework holds its own private notion of what a metric is. The same Monthly Active Users gets defined in the warehouse's semantic views, again in the BI tool's modeling layer, again in a dbt project, and the three quietly drift. Ossie's bet is that the definition should be written once, in a neutral format, and consumed everywhere. For AI, the pitch is sharper still: an agent that receives a governed metric definition does not have to reverse-engineer what revenue means from column names.
That is the half of the story the launch posts tell. This post is about both halves: what the spec actually carries, what the early adoption actually looks like, and what the format has no place for. The second half is not a flaw. It is a scope decision, and knowing where the scope ends is what tells you what the standard will and will not do for you.
What Ossie actually standardizes
The core spec is currently version 0.2.0.dev0, explicitly marked draft, and it is compact: four building blocks and two escape hatches.
A semantic model is the top-level container. It holds datasets, which are logical business entities pointing at a physical table, view, or query. Datasets carry fields, the row-level attributes used for grouping and filtering, with a typed vocabulary that separates a column's data type from its semantic role. Relationships declare how datasets join, the foreign-key knowledge that production databases so often leave undeclared. Metrics are aggregate expressions over those fields, with dialect-aware expression support so the same metric can carry its ANSI, Snowflake, and Databricks renderings side by side.
A model in the wire format looks like this:
semantic_model:
name: growth
datasets:
- name: users
source: analytics.prod.users
ai_context: "One row per registered account. Excludes internal test accounts."
metrics:
- name: monthly_active_users
expression: COUNT(DISTINCT user_id)
ai_context: "Active means at least one session in the calendar month."
The two escape hatches matter as much as the four objects. ai_context is a free-text or structured hint aimed directly at LLM consumers, a place to write the sentence a model needs before it queries. custom_extensions is the vendor annex: opaque, vendor-keyed attributes that travel with the document but mean nothing to anyone but their author.
That is the whole surface. It is small on purpose, and the smallness is why 50 organizations could agree on it.
The adoption reality check
The standard's promise is native import and export everywhere. The current reality is narrower, and precisely documented.
| Who | What ships today | The caveat |
|---|---|---|
| dbt Core 1.12+ | Native parsing of Ossie documents in an osi/ directory, alongside native semantic models | Accepts spec versions 0.1.0 and 0.1.1 only; "any other version string raises a parse error." Unsupported constructs are dropped with a warning while parsing continues. |
| Reference converters | Converters for dbt MetricFlow, GoodData, Salesforce, and Apache Polaris merged in the incubator repo | Converters, not native support: a translation step you run, not a format your platform speaks |
| Everyone else | Announcements and roadmaps | No shipped import or export |
The dbt row deserves a careful read, because it is simultaneously the best news and the sharpest warning. Best news: the largest analytics-engineering install base can already read Ossie documents natively, months into the standard's life. Sharpest warning: dbt is pinned to spec 0.1.x while the spec itself is at 0.2.0.dev0, so the ecosystem's flagship consumer and the standard's own draft have already diverged. A document written against the current spec does not parse in the tool with the best support. And when dbt meets a construct it does not implement, the construct is dropped with a warning while everything else loads, which is a reasonable engineering choice and also a quiet way for two systems to believe they share a definition while holding different halves of it.
None of this is a criticism of a project in incubation. Draft specs churn; that is what draft means. It is a reason to treat "we support the standard" claims as version-specific statements for the next year or two, and to pin the version you write.
What the spec has no place for
Read the 653 lines of the core spec with a different question: not what can I express, but what can I not express. The absences are systematic.
The words confidence, lineage, freshness, and provenance do not appear in the spec. Neither does verified. There is no field, on any object, for who approved a definition, when it was last checked against reality, or how sure anyone is that it still holds. The only two occurrences of "audit" describe an example timestamp column. This is checkable in one search of the spec text.
The physical world is likewise out of frame. A dataset's source is a string pointing at a table, view, or query. Whether that table still exists, how big it is, how it is indexed, which of its columns are stale, what querying it costs: none of that has a place in the document. Ossie describes the logical layer and trusts that the physical layer underneath it behaves.
The exchange format carries the definitions. Everything that would tell a consumer whether to trust them stays behind.
To be precise about it: custom_extensions can smuggle any of this as vendor-keyed opaque data, and ai_context can mention it as prose. But an escape hatch is the opposite of a standard. A consumer that reads one vendor's confidence annotation reads it as noise from every other vendor, which is exactly the interoperability failure the spec exists to end.
This is a defensible scope decision, and the spec's own goals say why: standardization, extensibility, interoperability. Definitions are the part every vendor shares; trust machinery is the part where they differ. Standardize the shareable half first. The point is not that Ossie chose wrong. The point is that the boundary exists, and everything on the far side of it is still every team's private problem.
Why the missing half matters more for agents than for people
A human analyst who receives a metric definition brings context the document never carried: they know the finance team distrusts amount_total, they remember the migration that left three columns holding the same metric, they notice when a number looks wrong. The definition is one input among many.
An AI agent consuming an Ossie document has the document. ai_context helps precisely as far as someone wrote it, kept it current, and anticipated the question. Whether the definition is stale, whether the source table was superseded last quarter, whether anyone with authority ever confirmed the expression matches what finance reports: the agent cannot ask, because the format cannot say. A governed definition consumed without its trust context produces the most dangerous kind of wrong answer, the kind delivered fluently and with a citation.
That trust context is a layer of its own: what is actually there, what it means, and how it connects, resolved against the live database rather than declared once in a document. The two layers are complements. An interchange format moves definitions between systems; a context layer is where a definition's relationship to reality gets maintained. Ossie standardizing the first does not create the second, and the second is where agent answers go right or wrong.
Where Datapace fits
Datapace sits on the far side of Ossie's boundary, on purpose. We are building a context layer around production databases: resolved meaning (which column is canonical, which rows count, how tables actually join) plus the operational evidence beside it (cost, performance, usage, lineage), with a policy gate over what AI may do and access. That is, almost line for line, the list of things an Ossie document cannot carry.
The two compose cleanly, and export is the natural seam: definitions resolved and verified against the live estate on our side, serialized outward as standard Ossie documents that any compliant tool can consume, with dbt export alongside. The standard gives the output a neutral wire format; the resolution work underneath is what makes the output worth exchanging. It is under construction rather than shipped, and Ossie's arrival makes the boundary between the two layers easier to draw than it was a year ago. If your agents consume definitions today and you want the trust half too, see what we are building or book a call.
Sources
- Apache Ossie project, "Apache Ossie (Incubating): The New Name for Open Semantic Interchange", July 10, 2026.
- Apache Ossie, Core Metadata Specification, v0.2.0.dev0 (draft).
- dbt Developer Hub, "Apache Ossie semantic layer documents" (dbt Core 1.12+; accepted versions and dropped-construct behavior).
- Snowflake, "Snowflake, Salesforce, dbt Labs, and More, Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative", September 2025.