The Composable Stack's Missing Noun

Assemble a modern commerce or content platform the MACH way — microservices-based, API-first, cloud-native, headless — and you get the promised benefits almost immediately. Best-of-breed everywhere. Vendors swappable in principle. No monolith to renegotiate every five years.

You also get a subtler bill, and it arrives at every seam. The commerce engine has a notion of a customer. The customer data platform has a different one. The order management system has a third, the loyalty service a fourth, and the analytics warehouse a fifth that is nobody's on purpose. None are wrong; each is right for its own service. But a composable stack is defined by its integrations, and every integration is where two of those notions must be made to agree. What the architecture removed in coupling, it reintroduced as translation.

The missing piece is not another API. It is a shared noun — an agreed definition of what a customer is that no single vendor owns.

What the Open Data Model contributes

The MACH Alliance's Open Data Model is the ecosystem's answer to that gap: a vendor-neutral vocabulary of business entities, published openly so any vendor and any implementer can align with the same definitions rather than negotiating pairwise.

It made an interesting formal choice. The standard is published as documentation — entity documents in Markdown, in a public standards repository, each with an entity-purpose narrative, a field table carrying MUST/SHOULD/COULD practice levels, OpenAPI-style YAML schema blocks, and a sample object. That is not an oversight. A composable ecosystem is a social system before it is a technical one; a standard that reads like a specification a human can argue with gets adopted, while a bare schema file gets skimmed and misapplied. The prose is where the intent lives, and the practice column is guidance no machine format has an obvious slot for.

The cost is the one every implementer meets on day one: the standard that is best for reaching agreement is not directly executable by anything in the stack.

Where we sit: the translator, not a participant

CoreModels is not part of the composable stack. We do not sell a commerce engine, a CMS, or a CDP, and we have no entity model of our own to promote into the standard's place. Our position is between the standard and everything downstream of it.

Concretely: odm is one format key among the fourteen our transform surface speaks, and it is decode-only. An entity document decodes into a neutral intermediate model, and from there it can be encoded into any target the engine supports — JSON Schema, ShEx, Avro, JSON-LD, SQL DDL (Postgres, MySQL, or SQL Server), OWL, an Apache Ossie/OSI semantic model in YAML or JSON, LinkML, Protobuf, an ODCS data contract, or the Synapse draft-07 profile. There are no pairwise converters, so a new target format arrives for every source format at once, ODM included.

That structure makes the compositions practical rather than theoretical. The published entity document is the agreement; the API team gets JSON Schema; the warehouse team gets DDL in their dialect; the streaming team gets Avro for the registry; a contract-first consumer gets an ODCS document; the semantics group gets LinkML or OWL. All of them derive from the same source, and each conversion arrives with its own honest ledger of what that target format could not hold — because SQL has no inline enum, or because a given format has no controlled-list construct, and pretending otherwise is how integrations rot.

The standard's own conventions are respected on the way in, too. OpenAPI-style #/components/schemas/... pointers are rewired to resolve inside the produced document; a pasted OpenAPI components: schemas: wrapper is tolerated; multiple fenced blocks and subsections within the schema section are merged. We meet the documents where the standard actually puts them.

Why decode-only is a position, not a limitation

There is no encode path for odm. Ask the transform surface to produce an ODM document and it refuses by name, telling you the format is not an export target.

That refusal is deliberate. ODM entity documents are authored documentation — prose, guidance, worked examples, community agreement. A tool that could emit ODM-shaped Markdown would be a tool for manufacturing things that look like standards — in an ecosystem whose entire value rests on everyone reading the same document, a hazard rather than a feature. The Alliance authors the standard. We consume it. The arrow points one way on purpose, so nobody builds a pipeline on a capability we never intended to offer.

Neutrality is the load-bearing wall

We implement the standard as published; we do not extend it, fork it, or reinterpret it. What comes out of the converter is ordinary JSON Schema 2020-12 — any validator, any tool, no CoreModels runtime required. The two annotations we add, x-odm-practice for the practice level and x-odm-source naming the standards repository, are x--prefixed extension keywords that conforming validators ignore and your own tooling can read. Nothing is smuggled into the wire format, and nothing about the output depends on us continuing to exist.

Meanwhile, the parts of a document we cannot represent are never quietly improved. The translator carries every keyword across verbatim, including keywords it has never seen, and reports what genuinely cannot be resolved. When a keyword we do not model shows up in a future revision of the standard, it rides through untouched instead of being dropped by a whitelist written before that revision existed.

This matters more for ODM than for a proprietary format: a shared vocabulary only works while it is genuinely shared. The failure mode of interoperability standards is rarely neglect; it is a vendor's dialect quietly becoming the de facto meaning, at which point portability evaporates and the standard becomes branding. A translator that stays out of the semantics is the only kind that can sit in this position honestly.

It also makes adoption reversible, which makes it safe to start. Because everything decodes into a neutral model and encodes back out into standard formats, leaving is a supported operation rather than a negotiation: you export in whatever formats you use and walk away with documents any tool can read.

The composable ecosystem will keep adding standards. Our bet is structural rather than partisan — a neutral model in the middle, honest translation at every edge, each standard implemented as its stewards published it, and a one-way arrow where a two-way one would be irresponsible.

For the full list of formats an entity document can travel to, see the schema transform documentation in the CoreModels docs.