Two 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.

Two entirely different things could have just happened.

In the first, the model reconstructed the standard from whatever traces of it passed through training — an approximation of a document, possibly an old revision, blended with the hundred similar customer schemas it has seen. In the second, the assistant fetched the actual entity document, ran it through a deterministic conversion, and read the answer off the result.

The two answers are indistinguishable in tone and not remotely equivalent in value. For a standard, the point is exact details; "approximately the ODM customer" is just another bespoke schema wearing a badge. Getting agents into the second category is what our ODM support is for.

Grounding: the document is the input, not the topic

CoreModels treats a MACH ODM entity document — the published Markdown, verbatim — as a decodable schema format under the key odm. An agent connected to our MCP server at /mcp (at https://coremodels.example.com, over OAuth) can call the transform_schema tool with the document text as sourceSchema, odm as sourceFormat, and whatever it needs as targetFormat — jsonschema for a formal schema, sql for DDL, avro for a registry payload, odcs for a contract, and the rest.

The agent is no longer being asked what it remembers; it is executing a conversion of the document in front of it. The required list in the output is the standard's required list. The enum members are the standard's members. If the document is a revision published last week, the answer is about last week's revision, with no retraining involved.

Precise semantics instead of guessed structure

Three details of the conversion matter disproportionately for agent work; each sits exactly where an unaided model would improvise.

Practice levels arrive machine-readable. The MUST/SHOULD/COULD column from the entity document's field table lands on each property as an x-odm-practice annotation — including the negative and softer forms the standard's language uses. So an agent asked "can we omit this field and still conform?" can answer from the document's own guidance instead of inferring obligation from a field's presence in an example. Hand transcription almost always drops this piece — and it is precisely what an agent needs to reason about conformance rather than shape.

Quoting survives. If the document defines status codes as the strings "1", "2", "3", the converted schema keeps them as strings. The pipeline reads the YAML's representation rather than eagerly deserializing it, so anything the author deliberately quoted stays quoted and only plain scalars re-type. An agent generating fixtures, test payloads, or validation code inherits that precision instead of introducing a type bug no reviewer would catch by eye.

The artifact is self-contained. The document's OpenAPI-style cross-references are rewired so they resolve inside the produced schema, and supporting types travel with it under $defs. The agent holds one complete document with nothing left to chase — and a dangling pointer is exactly the kind of gap a fluent model fills with something plausible. Where a reference genuinely cannot resolve, it is not smoothed over: it lands in the ledger.

The standard's own sample object comes along as examples, giving the agent a known-good instance to reason against, and the entity-purpose paragraph becomes the schema description — human intent alongside structure.

Evidence instead of self-reported confidence

Every conversion comes back with a lossiness ledger — each entry a kind, a path, and a plain-language explanation of what could not be carried exactly. An agent that relays a conversion can relay the ledger with it: converted cleanly, or converted, with one reference this document never defines. That is a checkable statement about the work, not a confidence score about the model.

success: true means the operation ran, not that nothing changed — and an agent operating on that contract can report honestly without being asked to introspect. The same call also returns the executed plan as a replayable artifact, so a human reviewer can re-run exactly what the agent ran and get the same output.

Consultation: after import, ask the model

Conversion is the entry point; the durable win comes after an entity is imported into a CoreModels project — behind a dry run, approved by a human with Admin, as writes should be.

From then on, agents consult the governed model instead of re-reading Markdown. Over MCP they can pull a project summary of types and elements, search nodes, export the project's schema in seven formats, and validate a concrete JSON document against the project's stored schema. An agent triaging a malformed customer record does not need the document at all — it asks the model, which already carries the standard's meaning.

Provenance closes the loop: every produced schema is stamped with its origin and practice levels, so an agent holding the artifact can distinguish "required because the standard says MUST" from "required because this organization decided so." When those two collide, that distinction is the whole recommendation.

Boundaries, made legible

Two limits are worth stating plainly; both are features.

The read/write split is enforced at the endpoint. /mcp serves read-only tools; the write tools live on the separate admin endpoint and require Editor or Admin membership on the project regardless. An agent can convert, transform, search, and validate all day without being able to change what your organization means. Every tool declares its behavior — read-only and open-world hints included — so a client can reason about a tool before calling it.

And odm is decode-only. No tool call will emit "an ODM document"; a request to encode into the format fails by name rather than quietly producing something. Agents generate fluent Markdown on demand, and a pipeline that could manufacture standard-shaped documentation would launder generated prose as community consensus. The arrow runs one way: the Alliance authors, agents consume.

The general pattern

Agents do not need standards summarized, paraphrased, or recalled. They need standards available — as exact inputs, behind tools whose write paths are gated, with ledgers that report what happened and refusals that are explicit rather than silent.

Grounded that way, an assistant's claim that a schema follows the Open Data Model stops being a fluent guess and becomes something rarer: a statement someone else can check.

To connect an agent, see the MCP quickstart in the CoreModels docs.