What a Data Contract Should Specify Before Two Teams Share a Dataset

A schema tells a receiving team which fields exist and how they are formatted. A data contract should answer the harder questions: what the dataset represents, what it may safely be used for, how it behaves over time, and who is responsible when something changes or fails.

Before sharing data, the producer and consumer should be able to answer five questions:

1. What does each row represent? 2. What do the important fields mean? 3. How complete and current must the data be? 4. What uses are permitted? 5. Who responds when the dataset changes or fails?

The contract does not need to follow one universal template. It does need to replace assumptions with explicit, reviewable commitments.

State the purpose, scope, and limits

Start with the decision the dataset is intended to support. A description such as “orders data” is too broad. A useful statement would be: “Supports next-day sales and fulfillment reporting; not a source for statutory revenue recognition.”

The contract should also define the population covered and any material exclusions. Does the dataset exclude test orders, particular regions, canceled accounts, or records before a certain date? These limits can determine whether the data is fit for a report or decision.

Explicit non-uses matter too. If the data should not be used for downstream sharing, record matching, or automated decisions, say so rather than relying on institutional memory.

Define what one row represents

“One row represents…” may be the most important sentence in the contract.

A row might represent an order, an order line, a person, an account-month, or a daily account snapshot. Those datasets can contain similar-looking identifiers while supporting very different counts and joins.

The grain statement should explain whether the dataset includes repeated snapshots, revisions, cancellations, or deletions. It should also identify the primary key or intended uniqueness rule, whether identifiers can be reused, whether records can arrive before related records, and whether an existing record may change after delivery.

Without this information, a consumer can follow the schema perfectly and still produce the wrong result.

Define consequential fields in business terms

Column labels and data types do not establish meaning. A schema can tell Finance that revenue is a decimal. A contract should explain whether it is gross or net, which currency it uses, whether tax is included, and whether refunds revise prior periods.

For fields that materially affect a decision, define the business meaning, unit, calculation basis, time zone, allowed values, and treatment of missing data. For example, “A null ship_date means the order has not yet shipped” is different from “The source did not provide a shipping date.”

Where an authoritative definition already exists, the contract can link to it. The important point is that terms such as “active account” or “net amount” should not be left to each team to interpret independently.

Separate quality expectations from delivery timing

“Clean data” is not a measurable promise. Quality clauses should describe what matters for the consumer’s use case. They might specify required fields, unique identifiers, allowed statuses, acceptable value ranges, expected population coverage, or reconciliation rules.

Delivery reliability needs separate treatment. The contract should state:

• How often the dataset is produced
• When each delivery is expected
• The business period covered by that delivery
• The maximum acceptable processing lag
• How late-arriving records are handled
• How far back corrections may reach
• How long historical data remains available

A dataset can arrive on schedule while containing older-than-expected events. For that reason, delivery time and data-as-of time should be stated separately.

Restatements deserve an explicit clause. Consumers need to know whether yesterday’s totals are final, preliminary, or subject to revision—and how corrections will be identified or communicated.

Record access, permitted use, and accountability

The contract should identify who is eligible to access the data, whether it contains sensitive or restricted fields, and any limits on retention, downstream sharing, matching, or automated decision use. These clauses should remain at the policy level rather than exposing credentials, internal endpoints, or security-control details.

A data contract is generally an operational and technical agreement, not necessarily a legally binding contract. It does not replace any legal, privacy, procurement, or regulatory review that may be required.

The operating model also needs names or roles. Identify the accountable producing owner, a business steward where relevant, an approved support channel, and the process for reporting defects. State how consumers will be notified of incidents and what they can expect during investigation and repair.

Agree on changes before the first release

Teams should define what counts as a breaking change. Adding an optional field may be nonbreaking. Removing or renaming a field, changing an identifier’s format, redefining a metric, altering historical values, or changing the row grain will often be breaking.

For breaking changes, agree on versioning, advance notice, migration support, and retirement of the old version. There is no universal notice period: it should reflect the consumer’s dependency and the consequences of disruption.

The contract should also maintain a change record. Otherwise, a consumer investigating an unexpected result may have no reliable way to distinguish a data issue from an intentional revision.

Make the agreement proportionate

A one-time, low-risk spreadsheet exchange may need only a page covering purpose, grain, critical fields, snapshot date, owner, and permitted use. A recurring feed supporting forecasts, dashboards, or operational decisions warrants delivery commitments, correction rules, incident communication, versioning, and maintained quality checks.

Some provisions can be tested automatically, including field presence, types, required values, uniqueness, enumerated values, bounds, and selected quality or timing rules. Other provisions—purpose, limitations, ownership, and business meaning—still require clear prose and a working process.

One practical publication gate is simple: the producer drafts the contract, the consumer tests it against a real use case and sample records, and both accountable owners approve it. The contract should then travel with the dataset or its catalog entry.

The goal is not paperwork for its own sake. It is to replace “we assumed” with a small set of commitments that both teams can review, test, and revise.