The Meeting That Stops Happening

The clearest measure of a governance tool is not a feature list. It is a meeting that falls off the calendar.

The meeting in question is the one where a producer team, a consumer team, and someone from the platform group sit down with a data contract on screen and reconcile it against reality — line by line, because the contract was written eleven months ago and the warehouse has moved since, and nobody can tell from the artifacts alone which parts still hold. That meeting takes ninety minutes, produces a spreadsheet, and recurs.

Here is what replaces it once ODCS is wired into CoreModels, told as the work each person no longer does.

The producer stops being a translation service

Before: every consumer who wanted the payments dataset in a usable form filed a request, and someone on the producing team hand-wrote a JSON Schema, or a DDL script, or an Avro schema, from the contract. Each artifact was correct on the day it was written and quietly wrong within a sprint.

After: the contract is imported once. A single call to the schema import endpoint with format: "odcs" and the contract text turns the contract's schema section into governed Types and Elements in a CoreModels project. Schema objects arrive under their contract names; properties arrive as Elements with their required flags, their array bounds, and their nested object structures. The physical detail — the varchar(18), the primary-key and uniqueness markers, the classification and encrypted-name markers, the partition positions — rides the transform layer's preservation channel, where varchar(18) stays varchar(18) on an ODCS round trip; the project persists the structural model, and the contract file remains the source of record for those physical facts.

Reading the response takes two minutes, and it is the last two minutes of translation work anyone does. The lossiness ledger states, in plain sentences with exact paths, what the model could not hold structurally: quality checks preserved verbatim rather than modeled, foreign-key relationships preserved verbatim rather than turned into graph relations, a time-of-day column approximated as a datetime with the original type kept, contract sections like servers and SLA preserved untouched in the transform layer rather than forced into the model. Nothing on that list is a surprise sprung later; it is the complete account, delivered up front.

The consumer stops asking

Before: "Can someone send me the schema?"

After: the consumer exports it. Exporting a project's schema needs only read access, so a consumer with Viewer rights can pull the model as JSON Schema for their API validation, as SQL DDL for their staging tables, as Avro or Protobuf for their streaming layer, as LinkML or OWL if they work in a semantic tooling stack — each generated from the same governed model, each accompanied by its own honest ledger of what that particular target format could not express.

The three artifacts cannot disagree about structure, because none of them is maintained by hand. They are views. When the model changes, they change together, and when a target format cannot carry something — a controlled vocabulary that SQL has no inline construct for, say — the export says so rather than pretending.

The governance lead gets a contract they did not have to write

The reverse direction is the outcome teams tend not to expect. A model your organization has governed for years — one that never came from any contract — exports as ODCS with format: "odcs". The standard's required head is minted for you: apiVersion: v3.1.0, kind: DataContract, an id derived from the model, and defaults of version 1.0.0 and status active where the model carries no contract history of its own. Required elements come out with required: true. Collections come out as arrays carrying their item types and, where the model has bounds, their minItems/maxItems options. Datetimes come out as timestamps.

Nobody on the team had to learn the specification to produce a document that conforms to it. That is the encoder's job, and it holds itself to the standard's own constraints — the required top-level fields, the valid kind, and property logical types drawn from the spec's enum.

When a contract itself is round-tripped through the stateless mapping path — ODCS in, ODCS out, in one call — the head that comes back is the head that went in: the original contract id, its version, its status, its domain and tenant, its purpose/limitations/usage block, and its verbatim-preserved sections, all re-emitted exactly. A project export mints a fresh head instead: the project holds the model, and the contract file keeps the contract's identity.

The reviewer gets a diff instead of an archaeology dig

This is the part that quietly changes how contract changes get approved.

The exporter is deterministic. The same model produces byte-for-byte the same document, and re-encoding an exported contract is a fixed point — run it through again and nothing moves.

That sounds like a formatting nicety and is actually the enabling condition for review. When exported contracts are stable, the diff between last quarter's contract and this quarter's contains only the facts that changed. Three changed lines means three changed facts. A reviewer can read it in a pull request, and a consumer can be told exactly what moved without anyone opening a spreadsheet.

The colleague who hasn't adopted anything gets helped in one call

Someone on another team has an ODCS contract and wants it as Avro this afternoon. No project, no import, no commitment. The stateless mapping endpoint takes the contract as the source format and the target format they need, converts it through the same engine, returns the result with the same lossiness ledger and a replayable plan, and writes nothing anywhere. If their assistant is connected to our MCP server, the same operation is one tool call away.

What they see in the one-off is what they would get in production, because it is the same code path.

The ledger of what changed

Count the manual translations in the sequence above: zero. Count the facts a human retyped and could have mistyped: zero.

And the roles fall out naturally rather than being administered. Importing a contract into a project requires admin rights on that project — meaning changes are gated. Exporting requires only read access — consumers serve themselves. The stateless paths write nothing at all, so exploration is free.

The contract stops being a document that someone owns and emails around. It becomes an interface: one governed model, many honest views, and a receipt on every conversion.

For the exact request shapes and a runnable walkthrough, see the schema transform documentation in the CoreModels docs.