Connect MACH Open Data Model
Stop shipping a recollection of the standard as if it were the standard.
How CoreModels works with MACH ODM
ODM entity documents are meant to be shared. Implementation teams type them into JSON Schema under deadline. Versions diverge. Required flags flip. Nobody can say which published revision the running API implements.
CoreModels imports the published definition as the baseline. Generated or existing schemas are then findings, not folklore. Because ODM is decode-oriented in the converter, you govern from the entity docs rather than pretending generated copies are authoritative.
Use this when “we follow MACH” needs to be a check, not a README claim.
Recipes
No recipes yet for MACH ODM. The articles below still describe the problem this connector is built to close.
Uses
Problems this connector fixes
Articles that explain the gap, then point at the recipe that closes it.
Transcription Is Where Conformance Goes to Die
Open almost any codebase that claims to follow an open data standard and, sooner or later, you find the file. It sits in a `schemas/` folder, named something like `customer.schema.json`, and near the top there is a comment: *adapted from the MACH ODM entity definition*. No version. No date. No link back to the source. Somebody, once, working against a deadline, read a published entity document and typed out what they believed it said.
OutcomesA Revision Lands: The Open Data Model on Working Terms
Standards adoption is usually described in terms of intent: we align with the Open Data Model, our partners can integrate faster. Those sentences are cheap. The useful question is narrower and more revealing: when a revision to an entity document is published on an ordinary weekday morning, what does your team actually do?
GovernanceTwo Verbs and a Dry Run: Governing a Standard You Do Not Own
Our ODM surface has exactly two verbs, and the distance between them is the entire governance argument.
EcosystemThe 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.
AgentsTwo Ways to Answer a Question About the Standard
Someone drops a question into a channel: *does the Open Data Model require an external identifier on the customer entity, or is it optional?* An AI assistant watching the channel answers in four seconds, in complete sentences, with a confident field list.
QuickstartYour First MACH ODM Transform: Markdown In, JSON Schema Out
The MACH Alliance publishes its Open Data Model (ODM) as entity documentation: Markdown files with prose, a field table, embedded YAML schema definitions, and sample objects. That is a great format for humans and a frustrating one for machines — you cannot validate a payload against a Markdown page.
APIMACH ODM over HTTP: One Converter, Two Importers, and an Honest "No Export"
Every schema format on the CoreModels transform surface declares its direction, and we hold ourselves to those declarations in public. The `odm` format — MACH Alliance Open Data Model entity documents — is **decode-only**: ODM entities are authored documentation, not a generated artifact, so there is no encode back to prose. Rather than paper over that, the HTTP surface is built around it. This article walks the complete set of routes that touch ODM, with real request and response bodies, the role each route requires, and exactly what happens when you try the direction that does not exist.
MCPConverting MACH ODM Entities with an Agent: transform_schema over MCP
Picture the request as it actually arrives: someone pastes a MACH Alliance Open Data Model entity document into a chat and asks their agent, "stand up a Postgres table for this." The document is Markdown — an H1, some prose, YAML blocks inside a schema section. Between that paste and a `CREATE TABLE` statement sits exactly one tool call.
AutomationODM at Scale: Batch Conversion, Deterministic Pipelines, and Replayable Plans
One entity document is a demo. A standards repository is dozens of them — identity, product, inventory, pricing — revised by pull request, consumed by teams who need formal schemas, not Markdown. The moment MACH Open Data Model documents become an input to your build, three engineering questions appear: can the conversion run unattended, will the same input always produce the same output, and what happens when one file in the batch is broken?
Deep diveInside the MACH ODM Coder: What Maps, What Rides Along, What Gets Reported
A MACH Alliance Open Data Model entity document is five things wearing one Markdown file: an H1 that names the entity, an `## Entity purpose` section of prose, an `## Object` table with normative practice levels, a `## YAML Schema Definition` section holding the actual schema, and a `## Sample Object`. The CoreModels `odm` coder reads all five — and this article is the precise account of where each one lands, what travels as annotation rather than structure, which situations produce lossiness records, and why this format is the one place in our lineup where round-trip is deliberately not the goal.