Data contracts prevent known data quality problems before a change reaches a data asset.
2
Data observability detects problems after they occur across the wider data system.
3
Teams should use observability to find important problem areas, then apply contracts to critical workflows.
Summary
Mark Freeman explains why data contracts and data observability address different parts of data quality. Observability gives teams broad visibility across pipelines, infrastructure, dependencies, and data changes. It can reveal problems as they occur, such as predictions moving outside an expected range. Data contracts work earlier in the process. They record expectations about a data asset, including its schema and business rules, then check proposed changes through code review and CI/CD. A contract can block a high-impact change or allow a lower-risk change while prompting a discussion. Freeman compares observability to a flashlight that scans the data system and contracts to a laser pointer aimed at selected workflows. He recommends starting with broad monitoring to find trouble, then using contracts where the consequences of change matter most. He also describes an emerging implementation pattern based on a contract specification, JSON Schema, version control, CI/CD, and a data catalog.
Data quality problems often begin with a communication gap between producers and consumers
Mark Freeman describes moving from data science into data engineering after finding that startup data was difficult to use and lacked supporting infrastructure. Working between software engineering and data science exposed a large gap in how the groups thought about data. He joined Gable to work on this problem with Chad Sørenston, focusing on how teams could agree on expectations for data before changes caused downstream problems. The talk is based on their upcoming O'Reilly book about data contracts.
Data contracts and observability can be placed at many points in a data system
Freeman sketches a data stack that includes a transactional database, an analytical database, and systems used for analytics or machine learning. Each connection between a source and a target can be a place for a data contract or observability. He says teams often ask where each approach belongs and whether they should apply both everywhere. His practical distinction is that contracts tend to work upstream, while observability tends to watch downstream effects.
Observability finds data problems across the system after changes happen
Freeman defines data observability as broad visibility into data, pipelines, infrastructure, and dependencies, with the aim of identifying and addressing data issues within acceptable service levels. It can alert a team when predictions move outside an expected range or when data changes appear. The important timing difference is that observability reports what has happened or is happening. It does not normally prevent a change before the data is written.
A data contract records expectations and checks them before a change is accepted
A data contract extends software engineering collaboration practices to data teams. A contract can describe the expected schema and business rules for an analytical table, transactional database, event stream, or external source such as Salesforce. Freeman describes a contract specification, often written in YAML, being checked against a schema registry or data catalog. Detection can use change data capture, stream processing, lineage, static analysis, or live monitoring. The result feeds into CI/CD, version control, and alerts.
Contracts preserve agreements when people and responsibilities change
Freeman gives an example in which a data scientist needs a particular format for a machine learning model and asks an upstream producer to agree to it. The producer may leave the company, and the replacement may not know about the original agreement. If the contract is stored as code in version control, future changes still pass through the same checks. A failed check can block a high-impact change or allow a lower-impact change while creating a prompt for people to discuss it.
Contracts prevent targeted problems while observability reveals wider patterns
Freeman separates the two approaches by timing, scope, and workflow. Data contracts prevent specific quality problems and fit inside CI/CD. Data observability complements CI/CD by showing quality trends across the full data system. Contracts are informed by business logic and provide targeted visibility. Observability shows how the system is behaving more broadly. The simplest timing distinction is that contracts alert before a change, while observability alerts after a change.
Teams should use observability to find where contracts deserve attention
Freeman compares observability to a flashlight and contracts to a laser pointer. Applying contracts to every data asset would require too much effort because systems contain many assets and rules. Observability can first scan the system and show what is working and what is failing. Once a team understands which parts matter most, it can apply contracts to a critical workflow and get the relevant producers and consumers aligned.
The implementation pattern is still emerging and requires several components
In the question period, Freeman says there is no single all-encompassing open-source tool for data contracts. Teams may combine a contract specification with JSON Schema, GitHub Actions or another CI/CD system, their existing data assets, and a data catalog. He describes JSON Schema as flexible and supported by plugins for different languages. He also says standardization is relatively new, so teams currently need to assemble the pieces around an architectural pattern.
"You have the flashlight, you can shine over the entire different data system and understand what is wrong, what is working, and then once you have an idea of, okay, these are the most important pieces, take the laser pointer with data contract."10:19
Who should watch
You are deciding whether data contracts, data observability, or both belong in your data quality work.
Your team has recurring disagreements between data producers and consumers about schemas, business rules, or downstream use.
You need a starting architecture and want to understand how contracts could fit with CI/CD, JSON Schema, and a data catalog.
