Data contracts are not the tests you run. They are the agreement you make.

A team I worked with had dbt tests on every model and Schema Registry configured across their Kafka topics. When I asked about their data contracts, they pointed to the tests.

The tests were good. When a source team changed a field without notice, the tests caught it — downstream, after the data consuming teams were already affected. Two days of investigation followed before anyone traced it back to the upstream change.

There was no data contract. There was tooling that detected what a data contract would have prevented.

A schema test is a monitoring tool. It tells you when something has broken. A data contract is an agreement between a data producing team and the data consuming teams about what the data will look like, when it will arrive, and how changes will be communicated. Those are different things. Conflating them is why data platform instability persists in teams that have invested heavily in data quality tooling.

The cost of this confusion has also grown. When a data contract is broken in a traditional data pipeline, a dashboard breaks and someone notices. When it breaks in an ML feature pipeline, the model keeps running — producing degraded predictions silently, with no error signal, until someone measures output quality and finds it has drifted. The absence of a data contract in an AI context is not a data quality problem. It is a model reliability problem.

The standard

The data industry has recognised this. The Open Data Contract Standard (ODCS), now governed by the Bitol project under the Linux Foundation, defines what a data contract should contain: schema, data quality rules, service-level agreements, ownership, and data classification. It is a comprehensive document standard — and evidence that the idea of formalising agreements between data producers and data consumers has matured beyond theory.

What ODCS does not solve is whether the data producing team and the data consuming team actually negotiated those SLAs, whether the producing team knows it is accountable for maintaining them, or what happens when a contract is broken. The spec defines what to document. The agreement is a different conversation.

The agreement in practice

A data contract that holds has two operational requirements.

The first is on the data producing side. Breaking changes — a column renamed, a type changed, a field removed — should never be applied in place. They should result in a new schema version and a new dataset version, published alongside the existing one. Data consuming teams migrate on their own timeline. The contract with existing consumers remains valid until they choose to move. Tooling like Confluent Schema Registry or AWS Glue Schema Registry enforces this for streaming data; Apache Iceberg provides the same capability for batch.

The second is discoverability. A data contract is only useful if the consuming team can find it. Data consumers should have clear access to all available dataset versions and enough documentation to make an informed decision about which version to consume under which contract terms. That documentation is the data producing team's responsibility — not something data consumers should have to investigate themselves.

The leadership mandate

Data contracts do not get adopted bottom-up. The data producing team bears the cost — the versioning overhead, the change communication, the extra discipline — while the benefit lands with the data consuming teams. Without a mandate, contracts stay optional.

The leadership task is to give data producing teams clear ownership and responsibility for maintaining their contracts and communicating changes through the agreed process. When a team deviates, the first question is not who is at fault but why: whether the process is too burdensome, whether the tooling makes it difficult, or whether the expectation was not clearly set. The goal is a process teams can sustain, not one they work around.

The path forward

Most data platforms have the tooling: schema tests exist, monitoring is in place. What is usually missing is the agreement that makes the tooling meaningful — the explicit conversation between data producing teams and data consuming teams about what the data will look like and what happens when it changes. That conversation is where I usually start.

Let's connect to build your data moat. 🛡️