A data contract should keep producers and consumers aligned. When the teams that produce the data were never in the room, the contract is a document that nobody feels. Start with a plain agreement on the three tables that feed revenue and risk reporting. Buy tooling only after that agreement is real.
The schema that nobody signed
You have probably seen this pattern. A data team picks a contract tool. They write schemas for dozens of tables. They publish the rules in a repo.
The first week looks good. Then a producer changes a column type to ship a feature. The contract breaks. The producer did not know the contract existed. The consumer finds out in a report.
The tool did its job. It found the break. The people who write the data were never part of the deal.
Why this is a conversation problem
It is easy to call this a tooling problem. I do not think it is.
A contract that the producer never agreed to is not a contract. It is a wish list written by the consumer. The producer has no reason to treat it as a promise.
So a weak data contract is a conversation problem. The schema comes after the people who make the data and the people who use it sit down and agree on what "good" means.
Three tables beat a catalog of rules
When a contract program stalls, the first reaction is often to cover more tables. That makes the noise worse.
Coverage is not the number of tables under a schema. Coverage is the number of paths where a named producer and a named consumer both treat the rules as real. If nobody owns the promise, the schema does not cover anything.
Start with revenue and risk
In earlier posts, I wrote that nobody owns the metric in a lot of companies, and that data quality is an operating cadence. Contracts have the same starting point.
Do not begin with every table in the warehouse. Begin with the three tables that feed revenue and risk reporting. For each one, ask:
- Who produces this table? One team, with a name.
- Who consumes it for a decision that costs money or creates risk?
- What must stay true for those consumers to trust the number?
Those answers are your first contracts. Write them in plain language first. Column types and null rules come next. The tool comes after both sides say yes.
If you cannot name the producer, do not write the contract yet. Name the producer first.
Put the producers in the room
Then run a short meeting for each of those three tables. Invite the producer and the main consumer. Keep the agenda short:
- What does this table claim to represent?
- Which fields can change without notice, and which cannot?
- Who gets a heads-up before a breaking change, and how?
Write the answers down where both sides can see them. That document is the contract. The schema is the machine form of the same agreement.
A producer who helped write the rules will defend them. A producer who only saw a failing check will work around them.
Buy tooling to enforce, not to invent
Once the three agreements exist, then buy or turn on a contract tool. Use it to enforce what people already agreed to. Do not use it to invent rules the producers never saw.
Add more tables only when a producer and a consumer ask for the next agreement. A short set of contracts that people keep beats a long catalog that people ignore.
Make the weekly review include the contracts
The contract list belongs in the same weekly review as your quality work.
Add two questions to the agenda:
- Which contracts broke this week, and did the producer and consumer fix the deal or the data?
- Which contracts exist on paper but have no named producer? Do we name one, or drop the contract?
A contract with no producer is not governance. It is a file you have not deleted yet.
Start small
You do not need a platform for this. You need three tables, two seats at a table, and a written agreement.
Pick the tables that feed revenue and risk. Put the producers in the room. Write the plain deal first. Then buy the tool that enforces it.
The spirit of the contract
I know that many of these suggestions do not fit real workflows exactly. That is fine. The key is the spirit of the article.
Producers talk about what they make. Consumers talk about what they expect. Together they set how the data is delivered, and that delivery stays the same even when the engineering teams need to make fundamental changes underneath it.
The contract is an agreement.