What Are Data Contracts? Definition and Example (2026)

The 4 required fields in every ODCS contract are apiVersion and kind, then id and version. Everything else is optional, but a contract that stops there promises nothing.

Identity and purpose: a name, a status that runs from proposed and draft through active to deprecated and retired, an owning domain, and a plain statement of what the data is for and what it must not be used for. Schema: each column with a logical type, whether it can be null, whether it is part of the primary key and how sensitive it is. Quality rules: nullValues and duplicateValues are the standard metrics, along with invalidValues and rowCount. Each is compared with a limit such as mustBeLessThan, and tagged with a dimension like completeness or uniqueness.

Service levels: ODCS names properties such as latency, frequency, availability and retention, plus timeToDetect and timeToRepair. Prefer latency to a freshness figure, since the standard does. Ownership and support come down to who is on call for the table and where consumers report problems. A contract with no named owner is documentation under another name.

Keep it small. Contract only the columns and rules a consumer actually depends on, since every line is a promise someone must keep. The full standard is maintained by Bitol under the Linux Foundation's AI & Data umbrella, and its JSON Schema lets a CI job validate that the file itself is well formed.

Take the orders contract version 1.1.0. Its quality rule allows fewer than 1% null values in customer_email, and its SLA promises each load within 4 hours. A load arrives with 20,000 rows, 340 of them with a null email. That is 340 / 20,000 = 1.7% null.

1.7% is over the 1% limit, so the rule fails, and the load is quarantined instead of published. The same load landed 6 hours after the cut-off, 2 hours past the 4 hour latency promise, so the SLA is also breached. Both failures route to the producer, because the contract names the producer as the owner.

The point of the arithmetic is who finds out. Without the contract, the 1.7% sits in the table until an analyst sees a drop in email campaign reach. With it, the producer sees a failed check at load time and fixes the cause before any consumer reads the data.

dbt calls them model contracts. Setting contract: enforced: true makes every column declare a name and a data_type, and before building the model dbt compares the query's output with that list. A mismatch stops the build with an error that lists each column and the reason, along with its definition type and its contract type. A model contract covers the shape of the output, while dbt data tests check its content after the build.

Constraints depend on the platform. Postgres enforces not_null and primary_key as well as foreign_key and unique, and it handles check too, but most cloud warehouses enforce only not_null and record the rest as metadata. A contract that lists a unique constraint on a warehouse that ignores it promises something nothing checks, so read the adapter's table before relying on a constraint. Contracts also do not apply to Python models or ephemeral models, and they skip materialized views. Sources and seeds are skipped, and so are snapshots.

Kafka has the same idea on the write path. Confluent Schema Registry attaches metadata and rules to a schema: domain rules for integrity checks at serialization and deserialization, and migration rules that transform old messages so producers and consumers on different versions still agree. On the write path it is the only check that blocks bad events before they exist.

A contract is only worth having if consumers can trust it to stay put. Use semantic versioning: a change that breaks any consumer needs a new major version, an additive change needs a minor one, and wording fixes need a patch.

For the orders contract at 1.1.0, adding an optional coupon_code column is additive and moves it to 1.2.0. Dropping customer_email, renaming amount, changing amount from a number to a string, or making a nullable column required moves it to 2.0.0. Each of those fails a consumer's query or silently changes its result.

Run the old and new major versions side by side for an agreed notice period, mark the old one deprecated in its status, and retire it once every consumer has moved. dbt follows the same logic: since version 1.6 it treats removing or changing a column's constraints as a breaking change, and since 1.9 it does the same for removing a contracted model.

The producer owns the contract and the promise behind it. Consumers do not write it, but they shape it: the contract lists what they depend on, and a rule nobody reads is dead weight. Without contracts, the consumer's tests detect the producer's changes after the damage. With them, the producer is accountable for the change before it ships.

That ownership is why contracts show up in data mesh designs, where each domain publishes data as a product. They overlap with data quality work, since the rules are quality checks, and with data observability, which watches for the failures nobody wrote a rule for. A contract covers what you can predict, and observability covers what you cannot.

Interviewers rarely ask for the definition. They ask what happens when an upstream team renames a column, how you would stop a bad batch reaching a dashboard, or how you would version a shared table. A contract answers all 3, because it puts the check at the producer and makes every change a versioned event with a named owner.

Practise saying where each check would sit in a pipeline you design. The data pipeline interview questions and data pipeline practice problems cover the design side, the system design round guide shows how the loop frames it, and dbt interview questions cover the model contracts and tests described here.