top of page
Laptop keyboard, coffee, sticky notes, and pencils on wood background

Data Contracts: The Discipline That Stops Bad Data Before It Becomes Your Problem

  • Jul 9
  • 4 min read

Every organization that moves data between systems has experienced the same failure: something breaks downstream, and by the time anyone notices, the problem has already propagated through multiple processes.


You trace it back and find that a source system changed its structure without warning — a column removed, a format altered, a field shifted — and your pipeline absorbed that change silently until the damage was done. Data contracts exist to prevent exactly that, and they are beginning to gain the traction in the industry that they deserve.


What a Data Contract Actually Is

The name is intentionally literal. A data contract is a formal agreement between the sender and receiver of data — the source system and the target system — that defines exactly what the data will look like. The structure, the format, the attributes present, the data types expected. Both parties commit to that specification: the source guarantees it will supply data in the agreed form, and the target confirms it will accept and process data in that form. If the agreement is broken, that is a violation — and it is treated as such.


The critical distinction from a conventional agreement is that a data contract is not a piece of paper that people can quietly ignore. It is electronically enforced. The target system checks incoming data against the contract before loading it. If the data violates the specification, it does not get loaded. The violation is flagged within the governance structure, and the source system owner is alerted to fix it.


The pipeline may pause, but bad data does not propagate.


Preventative vs. Reactive: Why the Distinction Matters

Most data quality management is reactive. Data is loaded, checks are run afterwards, problems are discovered, and teams work backwards to unpick the damage. This approach is expensive and slow, and it means that by the time a quality issue is identified, it has often already influenced reports, decisions, or downstream processes that relied on the data.


Data contracts shift this to a preventative model. The check happens before the data enters the target system. This is a meaningful operational difference. Rather than discovering three days after a load that a column shift has put every field under the wrong name across thousands of records, you catch the violation at the point of entry. The source is notified immediately. Nothing downstream is contaminated.


There is a useful analogy in lean manufacturing. When something goes wrong on a production line, you pull the handle and stop the line immediately. You fix the problem at source rather than allowing defective output to continue accumulating. Data contracts apply exactly that logic to data pipelines.


This Is Not an Entirely New Idea

It is worth being clear that data contracts are not a radical departure from existing practice. Teams have always run schema checks on incoming data. The world of APIs has operated with a version of this concept for years — when you declare an API version, you guarantee that consumers calling that version will receive a specific, predictable response. Call a later version and the contract may differ, but the consumer understands and chooses that. Data contracts extend this discipline more formally and more broadly across the data exchange landscape, applying it not just to API interactions but to system-to-system data flows of all kinds.


What is relatively new is the concrete tooling to implement them. DBT has released an implementation of data contracts that we have been using consistently in our data load patterns, and it works well. The field is still developing — implementations vary, and teams are finding their way to approaches that work reliably at scale — but the direction of travel is clear.


Who Should Be Thinking About This Now

If data contracts sound extreme for where your organization currently sits, that reaction is informative. It likely means you are early in your data governance journey, and the overhead of implementing contracts formally may not yet be justified by the complexity of your data landscape. That is a legitimate position for now.


But if your organization is actively developing data products, dealing with recurring data quality issues, or beginning to take data governance seriously as a discipline, data contracts are the right next step. They give you control over the flow of data in a way that informal agreements and after-the-fact checks simply cannot. And if you are at the point of designing new APIs or new data exchange mechanisms, that is precisely the right moment to establish contract agreements — while the structure is still being defined rather than retrofitted later.


The concept was largely formalized by Andrew Jones, whose work on data contracts is worth reading for any team looking to implement them seriously. Chad Sanderson has also written substantively on the topic. There is a growing body of literature and practical guidance available, and the tooling is maturing quickly.


The Broader Principle

Underneath the technical detail, data contracts represent a governance posture: the belief that it is better to stop bad data at the boundary than to absorb it and deal with the consequences. That posture requires agreement and accountability on both sides of every data exchange, which in turn requires organizational alignment that goes beyond the data engineering team.


For senior leaders, the implication is straightforward. Data contracts are not just an engineering pattern. They are a governance commitment — a decision that data quality is enforced proactively, that source system owners are accountable for what they send, and that the integrity of downstream systems is protected by design rather than by luck.


Ready to take the next step?

If this has raised questions about how your organization manages data quality and governance across your platform, there are three ways we can help.


Talk to us.

If you want a direct conversation about your data architecture and where the pressure points are, get in touch. We work with senior data leaders and C-suite executives to cut through complexity and build platforms that perform.


Download our white papers.

We publish in-depth guidance on Data Vault, Medallion architecture, AI readiness, and modern data platform design — written for practitioners and leaders alike.


Take the Data Transformation Readiness Assessment.

Not sure where your platform stands? Our free diagnostic evaluates your organisation across four critical dimensions — platform foundation, reporting and insight speed, operational agility, and strategic positioning — and gives you a personalised report with a clear picture of where to focus. It takes less than ten minutes.


 
 
bottom of page