# Data contract

> A data contract is an agreement between the producer and consumers of a dataset about its columns, types, keys and meaning, checked automatically.

A data contract is an agreement between the producer and the consumers of a dataset about its shape and meaning: the columns and their types, keys, allowed values, freshness and who owns changes. Written down and checked automatically, it turns surprise breakages into failed checks before deploy. Contracts often live as files next to the code.

For example, a contract for an `orders` table might state that `order_id` is a string, unique and never null; that `amount` is a decimal with two places and never negative; that `status` is one of placed, shipped, delivered or cancelled; that the table is refreshed by 06:00 every day; and that the payments team owns it. When the producer wants to rename `amount` to `total`, the contract makes that a visible change with a version, a notice period and a check that fails until consumers are ready, instead of a broken dashboard the next morning.

Contracts are written as plain files, often YAML, and checked in two places: at build time, where a pull request that changes a table's columns is compared with the contract, and at run time, where each load is tested against the rules before it is published. The rules a contract states map closely to [data quality tests](https://emolysis.com/glossary/data-quality-test), and its column list maps to the table's schema.

A contract is only as useful as its owner. It works best on the tables other teams depend on, such as the [silver](https://emolysis.com/glossary/silver-layer) and [gold](https://emolysis.com/glossary/gold-layer) tables that feed reports and applications, and less well on raw [bronze](https://emolysis.com/glossary/bronze-layer) data, where the source decides the shape. [Lineage](https://emolysis.com/glossary/lineage) shows who would be affected by a change.

In practice, a first contract can be small: the key, the columns that reports use, their types and a freshness target. Adding rules later is easy; agreeing on an owner and a way to announce changes is the part that takes time. See also [schema evolution](https://emolysis.com/glossary/schema-evolution) and [golden test](https://emolysis.com/glossary/golden-test).

Emolysis's [golden tests](https://emolysis.com/glossary/golden-test) and lint rules catch many contract breaks, such as type drift or a changed key, before a pipeline deploys. See also [schema evolution](https://emolysis.com/glossary/schema-evolution) and [data quality tests](https://emolysis.com/glossary/data-quality-test).

---

Page: https://emolysis.com/glossary/data-contract. Emolysis is a product of Bandpey GmbH, Munich, Germany. It is in private development, and nothing is released yet.