Data contracts: the new standard for quality agreements between teams

Your data pipelines are breaking. Not because of bugs. Because nobody agreed on what the data should look like before it was built.

A data contract is the solution, and it's one of the most practical governance innovations of the last five years.

The problem data contracts solve

In a typical data organization, the journey of data from source to consumer looks like this:

1. A production engineer adds a new field to the checkout APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète → response

2. They forget (or don't know) that a downstream data pipelinedata pipelineETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → depends on the existing schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Voir la définition complète →

3. The pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → breaks silently, it processes the data but produces incorrect results

4. Three weeks later, a business analyst notices revenue numbers look wrong

5. The data team spends two days debugging across six systems to find the source

This happens everywhere, every week, at every organization with a non-trivial data infrastructure. It's not a people problem. It's an architecture problem: there is no formal agreement between data producers (engineering teams that build source systems) and data consumers (data teams that build pipelines and analytics).

A data contract is that agreement. It specifies:

• Schema: The structure of the data, field names, types, nullable status
• Semantics: What each field means, business definitions, not just technical names
• Quality SLAs: Minimum quality thresholds, completeness, freshness, validity
• Ownership: Who is responsible for the data (producer) and who is consuming it
• Change management: How and when schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Voir la définition complète → changes will be communicated

When the production engineer adds that new field, the data contract is updated. The change triggers automated tests. The pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → is updated before it breaks. The analyst's dashboard never sees the problem.

Anatomy of a data contract

A data contract is typically a YAML or JSON file stored in version control (Git), alongside the code that produces the data. A simplified example would specify:

• contract.name: checkout_events
• contract.owner: ecommerce-platform-team
• contract.consumers: data-analytics-team, marketing-team
• contract.schema: order_id (string, required), order_amount_eur (decimal, required, "Total in EUR incl. VAT excl. shipping")
• contract.quality_sla: completeness 99.5%, freshness ≤15 min, no null order_id values
• contract.change_policy: 14-day notice, breaking changes require consumer_approval

When this contract is violated, order_amount_eur has null values, or freshness exceeds 15 minutes, an alert fires. The producer team is notified. Consumers aren't surprised by degraded data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.Voir la définition complète →; they're notified of the violation.