ODCS

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.

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.

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

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.

Where does `servers:` go?