TL;DR. Apache Ossie standardized the easy half first: a compact definitions format that more than 50 organizations could sign. The hard half arrived in late July as the foundational semantics spec (PR #246), which pins down how those definitions evaluate: join direction, fan-out prevention, many-to-many resolution, NULL bucketing, typed errors, plus a compliance suite to enforce it. The review turned into the project's first real fight. Reviewers showed that today's converters already corrupt models silently, that measure-anchored joins break assumptions BI tools depend on, and one long-time BI architect filed a counter-proposal: standardize a single SQL extension, measures, and let tools keep their own behavior. The outcome decides whether "supports Ossie" ever means "returns the same number," which is a bigger question for AI agents than for the humans who currently reconcile the differences by hand.
When Open Semantic Interchange entered the Apache Incubator in July, the striking thing was the agreement: Snowflake, Databricks, dbt Labs, Salesforce, and dozens of others behind one definitions format. The striking thing about August is where the agreement stopped. A pull request called Initial Foundational Semantics Spec (PR #246, opened July 22 by willpugh) tries to standardize not what a metric is but how it evaluates, and the review thread has become the project's first genuine dispute, complete with a formal counter-proposal to standardize something much smaller instead.
This is not incubator drama. It is the oldest question in standards work, surfacing in the semantic layer at the exact moment AI agents became the consumer everyone designs for: how much behavior does a standard have to own before compliance means anything?
Definitions were the easy part
Ossie's core spec is deliberately small: datasets, fields, relationships, metrics, two escape hatches, 653 lines. That smallness is why the signing list got long. A format that says "here is what Monthly Active Users means" asks vendors to give up almost nothing, because everything that determines what number actually comes back stays in their engine.
The foundational semantics spec is the attempt to take that second step. Together with a companion compliance suite (PR #237) and a draft of the underlying algebra (PR #262), it specifies evaluation behavior: joins run from the fact table outward so fact rows are preserved, reaggregation over many-to-many relationships is prevented rather than silently double counted, ambiguous join paths get disambiguated by rule, rows that match no dimension land in an explicit NULL bucket instead of disappearing, and failure cases raise typed errors instead of tool-specific behavior. The compliance suite makes it enforceable: implementations declare conformance levels in a machine-readable file and get tested against them.
Read the two PRs together and the ambition is clear. This is the difference between a standard for describing metrics and a standard for computing them.
The review found real corruption, not style nits
The strongest argument for pinning down behavior came from the review itself, in the form of what already goes wrong without it.
One reviewer, MarioDeFelipe, traced a concrete round-trip failure through the dbt converter (issue #311): a composite primary key on tenant_id and order_id goes in, the key group gets flattened into independent columns, and the model comes back declaring a primary key of order_id alone. No error, no warning. In a multi-tenant schema that is not a cosmetic loss; every uniqueness and join assumption downstream of that key is now quietly wrong. His conclusion was that conformance has to cover transport, not just query time: an implementation should represent a construct, reject it, or explicitly report it as unsupported, and never silently reshape it.
A second objection cut deeper, because it targeted the spec's own design rather than a converter bug. Reviewer christianeu-db pointed out that under measure-anchored join semantics, "two queries differing only in their measures can return different domains for the same dimension." BI tools are built on the opposite assumption: a dimension's members are stable, and measures vary across them. A spec that makes the dimension domain depend on which measure you asked about is not a formalization of what BI tools do. It is a change to it, and the thread's proposed fix, a fixed-grain evaluation mode, is so far an idea rather than spec text.
The counter-proposal: standardize less, on purpose
Then came the fork in the road. Justin Talbot, who spent years leading query language work on the BI side, put his concerns about PR #246 and the compliance suite on the record before any vote, as reported in the Apache Data Lakehouse Weekly. His adoption argument is blunt: no BI vendor has implemented the proposed semantics or queried through the proposed model, and some of the specified behavior around join direction, fan-out prevention, and many-to-many resolution conflicts with choices Tableau and Power BI shipped years ago and their users depend on. The coverage puts the document at 1,308 lines specifying the core of how a semantic layer behaves. Standardizing untested behavior at that scale, his argument goes, produces a spec vendors politely route around.
His alternative is a fraction of the surface: extend SQL with measure columns. A measure carries its own aggregation expression and evaluates without duplication after joins, but the standard would not force join types or join paths; tools keep their own behavior and layer it on top. The idea has serious prior art. Julian Hyde and John Fremlin formalized it in Measures in SQL (SIGMOD 2024): a new column kind that makes calculations composable and closed under ordinary SQL semantics, with an explicit evaluation context replacing the multidimensional machinery BI languages bolt on.
Two sizes of standard. The big one buys identical answers if anyone implements it. The small one gets implemented and leaves the answers tool-defined.
Both sides are making a bet about adoption, and both bets have failed before in other standards. Large normative surfaces stall when no implementation exists to prove them feasible. Small normative surfaces succeed quickly and then discover that the differences they left unstandardized were the ones users actually suffer from. There is no clever third option; there is a choice about which failure you would rather risk.
What this decides for AI agents
For human analysts, semantic drift between tools is an annoyance with a known workaround: someone notices the finance dashboard and the BI tool disagree, someone reconciles, someone eventually finds the three columns holding the same metric. The workaround is a person with context and doubt.
An agent has neither. It consumes the definition, picks a query path, and answers. If evaluation semantics stay per-tool, then a fully governed, Ossie-compliant metric still returns engine-dependent numbers, and an agent asked the same question through two stacks will confidently report both. Nothing in the definitions layer catches this, for the same reason the core spec has no place for lineage or freshness: the format standardizes what a metric means, and stops before what a query returns.
That is why the foundational semantics fight matters more than its incubator setting suggests. Deterministic evaluation is a precondition for handing definitions to software that cannot doubt the answer. The catalog world is converging on the same realization from another direction: OpenMetadata now markets its catalog as a context layer for AI, and a context layer whose numbers change with the query engine is a context layer that tells agents things it cannot promise. Whichever proposal wins, the honest reading of the current state is the same: today, "supports Ossie" does not mean "returns the same number," and no deployed tool claims otherwise.
The realism extends to versioning. Per the same community reporting, the project's first release discussion settled on starting at 0.3.0 rather than 1.0.0. That is the right signal for a spec whose behavioral core is still contested, and worth remembering when a vendor deck treats the standard as settled.
If you are writing Ossie models today
The dispute does not make the format unusable. It tells you what to rely on and what to check.
- Pin the spec version you write, and treat every "supports Ossie" claim as version-specific. The flagship consumer, dbt, still accepts 0.1.x documents while the draft sits at 0.2.0.dev0.
- Round-trip your models and diff them. The composite-key corruption in issue #311 was found by converting out and back. Anything you exchange through converters deserves the same test, especially keys and relationships.
- Keep aggregation logic where you can test it until evaluation semantics land. A measure defined once but evaluated differently per engine is a definition, not a guarantee.
- Watch PRs #246 and #237, not the marketing. Whether the compliance suite merges, and what conformance levels survive review, will say more about the standard's trajectory than any partnership announcement.
None of this is a criticism of the project. Fighting about join semantics in public, with a compliance suite on the table, is the standard working as designed. The projects that skip this fight ship the ambiguity instead.
Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. Standards like Ossie are the wire format that layer speaks outward; the evaluation guarantees under debate here are part of what has to be true before an agent's answer can be trusted. If that boundary is the one you are working on, book a call.
Sources
- Apache Ossie, PR #246: Initial Foundational Semantics Spec, opened July 22, 2026, and its review thread.
- Apache Ossie, PR #237: Create the initial compliance suite, opened July 20, 2026.
- Apache Ossie, PR #262: Adds the algebra to enable BI operations in a safe way (draft), opened July 24, 2026.
- Apache Ossie, issue #311: composite keys flattened in dbt conversion.
- Alex Merced, Apache Data Lakehouse Weekly: August 5 - August 12, 2026 (Talbot proposal, 1,308-line figure, and 0.3.0 release discussion as reported).
- Julian Hyde and John Fremlin, "Measures in SQL", SIGMOD Companion 2024, arXiv:2406.00251.
- Apache Ossie, project roadmap (aggregation, relationship, and grain semantics as current working-group effort).