Data Contracts

Data contracts define the agreement between data producers and consumers. Why they are essential for AI systems and how to implement them.

A data contract is a machine-readable agreement between a data producer and its consumers that specifies schema, semantics, SLAs, and ownership. It is the data engineering equivalent of an API contract. Without it, downstream consumers -- including ML models and RAG pipelines -- break silently when upstream data changes.

AI systems amplify the cost of data contract violations. A schema change that breaks a dashboard is caught in hours. The same change corrupting a training dataset or a feature store may not be detected until a model degrades in production weeks later, after training on the corrupted data. The feedback loop is long and the damage compounds.

The minimum viable data contract specifies: schema (field names, types, nullability), semantics (what each field means, units, encoding), SLA (freshness, availability), and owner (who to page when the contract is violated). Start with YAML or JSON in your repository. Tools like Great Expectations, Soda, or dbt tests enforce it at runtime.

Contracts between features and model training are the most critical and least documented contracts in most organizations. Which features were used to train the model? What were their expected distributions? What happens if a feature's distribution shifts? These are data contract questions. Document them. Version them. Monitor for drift.

The organizational challenge of data contracts is harder than the technical challenge. A contract requires two parties: a producer who commits to it and a consumer who relies on it. In most data teams, producers and consumers are different teams with different incentives. The contract is the mechanism for making that cross-team dependency explicit and enforceable.

Contract-first development flips the usual workflow: consumers define what they need, producers commit to providing it, and the contract is checked into version control before any data flows. This works especially well for ML feature stores and RAG knowledge bases, where the consumer (the model) has very specific and stable requirements.