How to Implement Data Contracts Between Producers and Consumers
A data contract is a written agreement about a data set between the team that produces it and the teams that use it. Implementing one means choosing the right interface, agreeing a small number of terms, enforcing them where the data is produced and settling in advance how change will be handled.
A product team renames a column in its application database. The change is sensible, reviewed and deployed. That night four pipelines owned by another team fail, and a finance report is wrong in the morning. Nobody acted carelessly. The producing team did not know anyone depended on the column, and the consuming team had no way to tell them.
A data contract closes that gap by writing the dependency down and giving both sides obligations. This guide covers what a contract contains, how to choose where to start, the steps of putting one in place, enforcement and the handling of change. It assumes the organisation has data moving between teams and has felt the cost of unannounced change. It does not assume any particular tool.
What a data contract is
The open specifications in this field offer clear definitions. The Data Contract Specification, an open-source project, describes it as follows: “A data contract is a document that defines the structure, format, semantics, quality, and terms of use for exchanging data between a data provider and their consumers”1. The Open Data Contract Standard, maintained by the open-source Bitol project, is briefer: “A data contract defines the agreement between a data producer and consumers”2.
Two points in the first source deserve emphasis because they set expectations for implementation. The first is about purpose: “First, and foremost, data contracts are a communication tool to express a common understanding of how data should be structured and interpreted”1. The second is about what follows once that understanding exists: “Later in development and production, they also serve as the basis for code generation, testing, schema validations, quality checks, monitoring, access control, and computational governance policies”1.
The order matters. A contract is an agreement first and an automation second. Teams that begin with tooling and skip the conversation produce files that describe data nobody agreed to.
The status of these two documents matters, because one of them is no longer current. The Data Contract Specification is deprecated. Its own documentation says so, in favour of the Open Data Contract Standard, and says it will be supported in its authors’ tooling until the end of 20261. That notice was still in place when the page was checked on 9 October 2026. This guide therefore takes its structure from the Open Data Contract Standard. The deprecated specification is quoted only for its plain account of what a contract is and what it is for, which does not depend on the file format. Nobody should start new work on the deprecated format, and its authors recommend migrating existing contracts. The surviving standard is itself versioned and still changing, so the current version should be checked before adopting it.
What goes in a contract
The Open Data Contract Standard organises a contract into sections that include fundamentals, schema, data quality, support and communication channels, team, roles, service-level agreement, and infrastructure and servers2. That is a full structure, and a first contract does not need all of it. Six terms carry most of the value.
Six terms of a first data contract
| Term | What it states | Example |
|---|---|---|
| Identity and ownership | What the data set is and which team is accountable for it | Orders, owned by the Order Management team, with a named contact |
| Schema | Fields, types and which are required | order_id, text, required, unique |
| Semantics | What each field means in business terms | order_date is the date the customer placed the order, in UTC |
| Quality | Conditions the data will satisfy | No null customer_id; amount is never negative |
| Service levels | When data will be available and how complete | Each day’s orders available by 06:00 the next day |
| Change terms | How changes are announced and how long old versions last | Breaking changes announced a stated number of days ahead |
The semantics row is the easiest to leave thin, and thin semantics mislead consumers. A schema says a field is a date. Only the semantics say which date. Business definitions should come from the organisation’s glossary where one exists, and not be reinvented in each contract.
Decide where contracts are worth having
Contracts cost effort on both sides, and applying them to every table at once is a reliable way to stall. Choose interfaces by three tests.
- The data crosses a team boundary. Within one team, ordinary engineering practice is enough.
- A failure would matter. The data feeds reporting, a customer-facing product or a regulatory return.
- The interface has broken before. Past incidents are the most persuasive evidence for the producing team.
Start with one interface that passes all three. A single working contract, with an incident it demonstrably prevented, does more to spread the practice than a policy.
Implementing a contract, step by step
- Identify the two parties by name. A contract needs an accountable producer. If nobody owns the source data, that has to be resolved first, and the roles are set out in data owners, stewards and custodians.
- Have the consumers state what they rely on. List the fields actually used, the timing needed and the assumptions built into downstream logic. This may be the first time the producer learns what depends on them.
- Have the producer state what they can commit to. A producer should not promise what their system cannot guarantee. A modest commitment that holds is worth more than an ambitious one that does not.
- Write the contract as a file. Use a structured, machine-readable format, following an open standard if it suits, and keep it in version control beside the producer’s code. A contract kept in a document repository drifts from reality.
- Add checks that enforce it. See the next section.
- Agree the change process and publish the contract where consumers can find it.
- Review it after the first change. The first real change tests whether the process works.
The contract should be owned by the producer. The consumer contributes requirements and holds the producer to the terms. A contract written and maintained by the consuming team is a set of tests on someone else’s data, which is useful and is not an agreement.
Enforcement: where the checks run
A contract that is not checked is documentation. Checks can run in three places, and the earliest is the most valuable.
In the producer’s development process. When a developer proposes a change to the producing system, an automated check compares the new schema with the contract and fails the change if it breaks a term. This prevents the incident. It is the hardest check to establish, because it places a new step in another team’s workflow, and it is the reason the producer has to be a willing party.
At the point of exchange. Where data passes through a platform that can validate it, the contract can be enforced as data is written. Schema registries for event streams work this way. Confluent’s documentation describes its implementation: “Data contracts in Confluent Schema Registry define quality expectations, metadata, and transformation rules for schemas”3. The same page notes a licensing limit on the capability: “Schema rules are only available on Confluent Enterprise (not on the Community edition)”3. It is one vendor’s implementation, cited to show the mechanism, and the limit is a reminder to check what a given edition of any tool includes.
In the consumer’s pipeline. The consuming team validates incoming data against the contract before using it, and stops or quarantines what fails. This detects a breach after it has happened. It protects downstream users and gives the evidence needed to raise the breach with the producer.
A mature arrangement has all three. A realistic first implementation has the third immediately and works towards the first.
Versioning and change
Data changes, and a contract that forbids change will be ignored. The purpose is to make change safe.
Classify changes into two kinds. An additive change, such as a new optional field, does not break existing consumers and can be made with notice. A breaking change, such as removing or renaming a field, changing a type or altering what a field means, needs a process.
A workable process for breaking changes has four parts.
- Notice. The producer announces the change, with a date, to every registered consumer.
- Overlap. Old and new versions are both available for an agreed period.
- Migration. Consumers move within that period, with the producer’s help where needed.
- Retirement. The old version is withdrawn on the announced date.
This requires knowing who the consumers are. A register of consumers per contract is therefore part of the implementation. Changes of meaning deserve particular care, because they break nothing visibly: a field that keeps its name and type and quietly changes its definition passes every schema check.
Why contracts fail, and how to avoid it
Three failure patterns follow from how a contract works. They are DII’s cautions, not measured findings.
The producer gains nothing. Contracts ask producing teams, whose priorities are their own product, to take on obligations for someone else’s benefit. Where they see only cost, compliance is grudging. Show them what they gain: fewer urgent requests when something breaks, a clear list of who uses their data, and the freedom to change everything the contract does not cover.
Too much, too soon. A contract specifying every field and dozens of quality rules is expensive to agree and to keep. Begin with the fields consumers actually use.
No one enforces it. Without checks, the contract and the data diverge within months, and the contract becomes one more stale document.
Contracts also have a place in larger designs. Architectures that treat data as a product, discussed in data mesh vs data fabric, depend on published interfaces with stated guarantees, which is what a contract provides.
Where contracts sit in a reliable pipeline
A contract addresses one class of failure: change at a boundary between teams. It does not make a pipeline idempotent or recoverable, which are matters of design covered in what makes a data pipeline reliable. When a contract is breached in production, the response is an incident like any other, handled as described in handling data incidents, and the checks that detect the breach are among those placed in where to put data quality checks in a pipeline.
The Data Contract Template provides the six terms as a structure to complete with a producer, including the change terms and a consumer register. The Data Pipeline Design Template records where a new pipeline depends on contracted inputs.
Sources
- Data Contract Specification contributors. Data Contract Specification (README).
- Bitol. Open Data Contract Standard (ODCS), version 3.2.0.
- Confluent. Data Contracts for Schema Registry on Confluent Platform.
This article is general professional information. It is not legal or regulatory advice.