The Missing Artifact

Take the modern data stack layer by layer and ask one question of each: can I have that as a file?

Storage says yes — open table formats with manifests you can read. Events say yes — a registry hands over a schema per subject. Services say yes — a schema document or an API description. The warehouse says yes — DDL on demand. Every one of those layers has a portable artifact you can diff, review, and hand to a tool built by someone else.

Then ask the layer that says what any of it means. Which table is the sales fact. What total_revenue computes. How orders join to items. What the business calls the price column. You get a screenshot, a link to a workspace, or an export exactly one product can read.

That asymmetry is the hole Apache Ossie is trying to fill, and whether it gets filled is mostly a question about implementers, not the specification.

What the spec's own shape says

Ossie — formerly Open Semantic Interchange, now carried under the Apache Ossie name and published from the apache/ossie repository — is a document format for the semantic layer. It is on its 0.1 line; the release we target is 0.1.1. We implement it. We do not speak for the project.

Its neutrality is visible in the document structure itself, which is the only place neutrality can really be designed in.

Expressions are declared per dialect, so an ANSI SQL form sits beside engine-specific forms and no engine's syntax is treated as the expression. Vendor-specific data gets a sanctioned, labeled home in named custom extensions instead of being smuggled into general-purpose fields. AI guidance is spec-level — ai_context with instructions, synonyms, and examples — so the briefing an assistant needs travels with the model rather than living inside whichever vendor's assistant you configure. And the root of the document is deliberately small: a version, the semantic models, and a couple of sibling keys. There is not much surface for a vendor to colonize.

Three tests for whether an implementation is neutral

A neutral format survives only if the tools around it behave. These are the tests we hold ourselves to, and they generalize to any implementer of a young standard.

Does it re-emit what it does not understand? Documents in the wild carry keys the spec does not define: vendor improvisations, fields from a revision that has not landed. Our reader parses into a generic object graph and walks it defensively, never binding to rigid classes, so an unknown key cannot break a decode. Where the structure allows, unknown keys are preserved verbatim and re-emitted unchanged; where they cannot be carried, they are named in the change report rather than dropped in silence. Shorthands get the same treatment: a single-object semantic model is accepted where the spec expects a list, a bare-string expression is read as the ANSI SQL dialect, and a scalar primary key is read as a one-column key. Tolerant on the way in, strict on the way out.

Does it privilege one dialect or one serialization? We expose two format keys for one format because the ecosystem has two consumers: osi emits the spec's YAML, and osi-json emits the identical model as JSON — the serialization dbt ingests. On decode, either serialization is accepted under either key, since JSON is a subset of YAML and a single parse honestly reads both. Preserved per-dialect expressions are re-emitted in stable order with none promoted. Our encoder supplies an ANSI SQL expression only when the source carried none at all and the spec requires every field to have one — a floor, not a preference.

Does it invent private keys? Our governed model can hold things Ossie cannot express: controlled value lists, type inheritance, relations that are not dataset-to-dataset, components that are not metrics. The tempting move is a private extension that carries them through our own round trip beautifully. We decline it. Those constructs are omitted from the document and declared in the lossiness ledger instead. A neutral format stays neutral only if implementers resist forking it one convenience at a time.

What it composes with

An interchange format is worth exactly what reads and writes it. Two composition points are concrete in our implementation.

The first is downstream tooling. dbt ingests OSI semantic models as JSON, which is why the JSON serialization is a first-class output rather than a post-processing step bolted onto a YAML writer.

The second is the rest of the estate. In CoreModels, Ossie is one of thirteen format keys sharing a single dispatch, with a governed graph at the center and JSON Schema, ShEx, Avro, JSON-LD, SQL DDL, OWL, LinkML, Protobuf, ODCS data contracts, ODM entity documents, and Synapse schemas as the other spokes. Translating pairwise between N formats needs on the order of N-squared translators, each with its own bugs; a hub needs N, each auditable on its own. We demonstrate that rather than asserting it: a cross-format test drives a LinkML schema through the intermediate model and out as an Ossie document that decodes cleanly.

There is a genuine division of labor in that hub. Ossie carries meaning — metrics, join semantics, synonyms, machine-readable guidance — and deliberately carries no field type system. The structural formats carry types and have no slot for meaning. Neither substitutes for the other, and a hub is where they stop competing to be the one true description of a table.

Why neutrality earns its keep at this layer in particular

Storage formats are replaceable because their contents are mechanical: the same rows, encoded differently. Convert them and nothing is lost but time.

A semantic model's contents are judgment: years of decisions about what counts as an active customer, which channel belongs in which metric, which join is legitimate. Losing a storage format costs an engineering project. Losing a semantic layer costs the reasoning that produced it, and no migration tool reconstitutes reasoning.

That asymmetry is why we treat neutrality here as an obligation rather than a position. If a semantic model can enter a system and cannot leave it in the shape it arrived — or leaves subtly enriched with keys only that system understands — then the format was open and the outcome was lock-in anyway.

Whether Ossie becomes the lasting answer for this layer is for its community to decide. What implementers control is whether adopting it is safe: whether documents survive translation honestly, compose with the rest of the estate, and never become hostages of the tool that promised to free them.

For the full list of formats CoreModels translates alongside Ossie, see the transform section of our documentation.