Data contracts: an API, but for data

datacontract.com used to host one of the two competing data-contract specifications; it is now an interactive guide and editor for the standard that won. Its one-line definition is the cleanest in the space: "a data contract is a document that defines the ownership, structure, semantics, quality, and terms of use for exchanging data between a data producer and their consumers. Think of an API, but for data." And its framing sentence explains why the idea outgrew documentation: "data contracts are not just documentation. They are the foundation for building trust and data governance with a high degree of automation." These are my notes on the site and the standard it now teaches.

Two specs walked in, one standard left

The quiet headline is a standards story that almost never happens. The site's team built the Data Contract Specification on OpenAPI principles; Bitol, a Linux Foundation project, stewards the Open Data Contract Standard. Rather than fight it out, in the site's own words: "we joined forces with Bitol, contributed concepts and learnings, and with the release of ODCS 3.1, we can finally deprecate the Data Contract Specification proposal in favor of a common single standard." The site states the principle behind the retreat plainly: "we believe in open standards. That's why we created the Data Contract Specification based on OpenAPI principles, and later deprecated it to bring our ideas into the Open Data Contract Standard, because a standard supported by many is more important than your own specification." For anyone who sat out the format war waiting to see which spec to adopt, the waiting is over; there is one standard now, and even its former competitor says so.

Put simply: the data-contract format war is over. The datacontract.com team deprecated its own specification into ODCS 3.1 under the Linux Foundation, which means adopting data contracts no longer requires betting on a spec.

The anatomy of a contract

The site teaches the standard as a step-by-step build, and the walkthrough doubles as the anatomy. Fundamentals: "the version of the standard, unique identifier, name, data contract version number, and status," the metadata that makes contracts versionable. Schema: "the structure and semantics of your data," where "each property includes technical details, business semantics, and governance attributes," one field carrying all three layers at once. Quality: "define checks like valid value constraints, row count thresholds, and custom SQL validation logic. These can be tested automatically with the Data Contract CLI." Team: "who owns and maintains the data contract," with members, roles, and support channels "how data consumers can reach out to the owners." Terms of use: "the purpose, usage guidelines, and limitations for your data," which the site frames as "establishing clear governance boundaries." Then servers, where the data physically lives, and custom properties as the escape hatch. Ownership, semantics, quality, and recourse, in one versioned YAML file next to the code.

Put simply: an ODCS contract packs fundamentals, schema with per-field semantics and governance, machine-testable quality rules, named owners with support channels, terms of use, and server locations into one versioned file. The novelty is not the list; it is that a CLI can enforce part of it.

The quality section is the hinge

What separates a data contract from the data dictionaries that have gone stale in every company since databases existed is the part a machine can check. Valid-value constraints, row-count thresholds, and arbitrary SQL checks, executed automatically by the Data Contract CLI, turn the document from a description into a gate: the contract fails loudly when the data stops matching it, instead of quietly drifting out of date. This is the same move Bain's data chapter makes when it says governance in an agentic world "must be embedded in the systems and pipelines themselves," and the same one the non-negotiable stack makes with schema documentation and quality tests as code: the enforcement lives where the data flows, not in a review meeting. A contract without the executable quality section is a wiki page with better formatting.

Put simply: the testable quality rules are what make a contract a contract. If the CLI can fail your pipeline when reality diverges from the document, you have governance; if not, you have documentation with a YAML accent.

Why this lands on the agent thread

The site says the quiet part in one sentence: "Data Contracts are powerful when exchanging data with other teams or AI agents." An agent consuming a dataset needs exactly what a human consumer needs, only with no ability to shrug and ask a colleague: what the fields mean, what quality was promised, who owns it, and what it may be used for. That is the contract's five-item definition read back as an agent's context requirements, and it slots straight into the governed-layer picture this site keeps assembling: the warehouse between the AI and your systems needs its interfaces specified, and a versioned, owner-signed, machine-testable contract is what a specified interface looks like for data. The irony the site should fix: all of this lives in a client-rendered JavaScript bundle, so a plain fetch of the page returns a title and nothing else; Google renders JavaScript eventually, but every agent that reads pages the cheap way gets an empty document. The message is right; the medium disagrees with it.

Put simply: agents make data contracts urgent, because an agent cannot compensate for an unspecified interface the way a human eventually does. The contract is the semantic layer's per-dataset unit: meaning, quality, ownership, and terms, versioned and testable, where the agent can read it.