Connect ODCS data contracts
Make the contract a derived artifact of governed meaning, not a YAML twin of the table.
How CoreModels works with ODCS
ODCS settled the format question for data contracts. Enforcement is still the open problem. Hand-maintained contract YAML decays at the same rate as the `schema.yml` files it was supposed to improve on.
CoreModels decodes ODCS into the governed model and encodes the governed model back to ODCS. The dbt contract-of-record recipe is the same idea from the producer side: import marts, audit them, publish ODCS for everyone who never runs dbt.
A contract nobody governs is a wish. A contract inside the audit loop is a definition with a history.
Recipes
No recipes yet for ODCS. 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.
The Cheapest Way to Break a Data Contract Is to Retype It
Here is one property from an ordinary data contract, written in the Open Data Contract Standard:
OutcomesThe 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.
GovernanceSeven Things Our ODCS Support Refuses to Do
We could describe how CoreModels handles data contracts as a list of capabilities. It is more useful to describe it as a list of refusals, because in governance the interesting question is never what a tool can do. It is what the tool will not do to your document when nobody is watching.
EcosystemODCS Is Not Competing With Your Schema Format
A question we get early in most conversations: "If we adopt ODCS, do we stop using JSON Schema?"
AgentsThe Fine Print Is Where Agents Fail
Every data contract has a headline and a fine print. The headline is the list of columns and their types; any competent reader gets that right. The fine print is the rest: that this primary key is explicitly `required: false`; that this column is classified `restricted` and has an encrypted counterpart; that the quality check on the amount column demands a null count of exactly zero at error severity.
QuickstartOne Contract, Three Schemas: An ODCS Quickstart
A data contract is a promise with a schema inside it. The ODCS documents your platform team publishes — Open Data Contract Standard, the Bitol project's v3 line — carry tables and columns, but also servers, quality checks, SLAs, ownership: everything the promise needs and most target formats cannot hold. This quickstart takes one real contract through a single CoreModels call three times — to JSON Schema, to SQL, and back to ODCS — and shows you how to read what each conversion kept, what it set aside, and where the set-aside parts went.
APIODCS Over HTTP: The Transform Routes for Data Contracts
Direction first, because we publish it per format and it decides what you can build. The format key `odcs` appears in both of CoreModels' transform lists — decode (`jsonschema | shex | avro | jsonld | sql | osi | osi-json | owl | linkml | protobuf | odcs | odm`) and encode (`jsonschema | shex | avro | jsonld | sql | osi | osi-json | owl | linkml | protobuf | odcs | synapse`). ODCS round-trips. Its neighbors do not all manage that: `odm` decodes only (ODM entities are authored documentation, and we do not generate prose), and `synapse` encodes only (its output is plain draft-07 JSON Schema — re-import it as `jsonschema`). What `odcs` means here is a Bitol Open Data Contract Standard v3 document — `apiVersion: v3.1.0`, `kind: DataContract` — as YAML or JSON.
MCP"Turn Our Data Contract Into an Avro Schema": ODCS Through `transform_schema`
"The platform team publishes the orders contract — can you make the Avro schema for the streaming team?" That sentence, said to an agent with no tools, produces plausible-looking `.avsc` with invented decisions baked in. Said to an agent connected to CoreModels over MCP, it becomes a call to `transform_schema`: a deterministic engine does the conversion, and the agent gets back the schema, the executed plan, and a machine-readable account of what the trip cost. This article is the complete loop for ODCS — connection, the exact tool contract, two real conversions, and the contract-specific habits that separate a good agent from a confident one.
AutomationThe Contract Pipeline Is a Plan File: Automating ODCS With Replay
Automation is where schema tooling usually stops being honest. A conversion that a human runs once gets its output eyeballed; the same conversion in a nightly job gets trusted. So the two properties that matter most for automating data contracts are not features, they are guarantees: CoreModels transforms are **deterministic** — the same contract in produces byte-identical output every run, which makes diffs a real review surface — and every mapping executes from a **plan** that comes back in the response as JSON you can commit, review, and replay. This article builds an ODCS pipeline on those guarantees: a published subset of an internal contract, regenerated on every change, with drift caught by the engine instead of by a consumer.
Deep diveAnatomy of the ODCS Coder: What Maps, What Rides, What's Declared
Where does `servers:` go?