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, 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 and gold tables that feed reports and applications, and less well on raw bronze data, where the source decides the shape. 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 and golden test.
Emolysis's golden tests and lint rules catch many contract breaks, such as type drift or a changed key, before a pipeline deploys. See also schema evolution and data quality tests.