Data Contracts

What it is

The Open Data Contract Standard puts it in one sentence: a data contract defines the agreement between a data producer and consumers. In practice it is a document that defines the structure, format, meaning, quality and terms of use of data that passes from one team to another.

The standard organises a contract into sections that include fundamentals, schema, data quality, support, team, roles, service-level agreement and infrastructure. A first contract rarely needs all of them; DII advises beginning with the terms consumers actually rely on.

A contract is first a communication tool. Written in a machine-readable form, it can later become the basis for code generation, testing, validation and monitoring.

Why it matters

The two open specifications are converging: the Data Contract Specification is deprecated in favour of the Open Data Contract Standard and supported only to the end of 2026. One standard simplifies tooling and adoption.

For an enterprise the practical value is that a dependency between teams is written down, with obligations on both sides. DII advises that a contract earns its cost where data crosses a team boundary, where a failure would matter, or where the interface has broken before.

One survey, by BARC and sponsored by a vendor, reports that 61% of surveyed organisations use data contracts operationally. It is a sponsored survey with a self-selected sample, reported by its sponsor, so DII holds its adoption assessment with low confidence.

The problem it addresses

DII editorial view

A producing team changes a field and a report elsewhere breaks, because the dependency was never written down. The consumer finds out from the failure. A contract records what the data is and what it promises, so that a change is agreed before it is made.

Business and organisational relevance

DII editorial view

A contract changes a relationship between teams. The producing team takes on an obligation and the consuming team gets something to rely on. Published DII guidance notes that contracts fail where the producer gains nothing, so the case to the producing team matters as much as the document.

Practical use cases

• An interface that crosses a team boundary and has broken before
• Data that feeds reporting, a customer-facing product or a regulatory return
• The agreed terms of a data product

Benefits and opportunities

• A breaking change is caught where it is made, not where it is felt
• Consumers know what they can rely on, and whom to ask

Risks, limitations and dependencies

• A contract specifying every field and many rules is expensive to agree and to keep
• Without checks that enforce it, the contract and the data diverge
• Contracts written to the deprecated specification will need migrating

Prerequisites for adoption

DII editorial view

• An accountable producer and consumers who can state what they rely on
• Version control for the contract, beside the code
• Checks that enforce it, or the contract and the data diverge

Implementation considerations

• Start where breakage hurts most. Introduce contracts on the few interfaces where a failure would matter, not everywhere at once.
• Write new contracts to the open standard. Use the Open Data Contract Standard for new contracts, and plan the migration of any written to the deprecated Data Contract Specification.
• Name both parties and give both obligations. A contract needs an accountable producer and consumers who state what they rely on. A producer should commit only to what its system can guarantee.
• Keep the contract as a file beside the code. Use a structured, machine-readable format under version control. A contract kept in a document store drifts from reality.
• Enforce it in more than one place. Checks can run in the producer's development process, at the point of exchange and in the consumer's pipeline.
• Agree how breaking changes are made. Settle notice, overlap, migration and retirement before the first change, and review the process after it.

The DII Radar assessment

Approved DII Radar assessment

DII assesses Data Contracts as High relevance, with direction Rising. Its strategic impact is assessed as High and its enterprise adoption as Scaling. It is one of the ten entries on the current Radar.

DII relevance is our assessment of current significance and momentum, based on evidence, market development and adoption. Direction is the observed trajectory of relevance and adoption. Strategic impact is the potential or current significance to enterprise data capability, and enterprise adoption is the extent of current real-world enterprise adoption; together they set the position on the Radar. The Radar is not a prediction, vendor comparison or performance ranking.

Evidence basis: Open Data Contract Standard v3.2.0 (Bitol, Linux Foundation); Data Contract Specification deprecation notice; BARC survey 2026, sponsored by Actian (61% operational use).

See Data Contracts on the Radar →

What to consider next

DII editorial view

• Introduce contracts on the few interfaces where breakage hurts most
• Write new contracts to the Open Data Contract Standard
• Plan the migration of any written to the deprecated specification