What is a data contract, in one paragraph?
A data contract is a formal, versioned agreement between the team that produces a dataset and the teams that consume it. It defines the shape of the data (fields and types), what those fields actually mean, who owns the dataset, the quality and freshness levels consumers can rely on, and the rules for how any of that is allowed to change. The point is enforcement: a data contract is checked automatically, so a producer cannot ship a breaking change without the change being caught before it reaches the people and systems depending on it. In short, a schema describes what the data looks like right now. A contract is a promise about what the data will keep looking like, backed by an owner and a consequence when the promise is broken.
Why has everyone started talking about data contracts?
Data contracts became a hot topic because the failure they prevent is so common and so expensive. Modern analytics and machine learning stacks are long chains of dependencies. A source system emits records, a pipeline lands them, a transformation reshapes them, a dashboard reads them, a model trains on them. Every link assumes the link above it will keep behaving. That assumption is almost never written down anywhere, which means it is almost never true for long.
The typical break goes like this. An application engineer renames a column, changes a field from an integer to a string, or starts sending nulls where there used to be values. From their point of view nothing dramatic happened. They own the application, the change passed their tests, they shipped. But three layers downstream a join quietly stops matching, a metric silently drifts, or a nightly load fails at two in the morning. Nobody chose to break anything. The producer never knew consumers existed. This is the "silent break", and it is silent precisely because the dependency was implicit.
Two things made this worse over the last decade. First, teams got more decoupled: the people generating data and the people using it rarely sit together or even know each other. Second, the number of consumers per dataset exploded. One well used table can feed dozens of dashboards, reverse ETL syncs, and now retrieval systems feeding large language models. When a single upstream change can fan out to dozens of downstream failures, the cost of not writing the promise down finally exceeds the cost of writing it down. That is the whole reason the idea caught on. It is also closely related to the n by m data integration problem: the more producers and consumers you wire together directly, the more fragile connections you have to keep from snapping.
What is actually inside a data contract?
A data contract is not one thing, it is a small bundle of explicit commitments. The exact format varies by tool and team, but a useful contract covers roughly these areas.
Schema and field definitions. The list of fields, their data types, whether they are nullable, and their allowed values or ranges. This is the part people think of first, and it is the easiest to check automatically.
Semantics and meaning. What each field actually represents, in business terms, not just its type. status being a string tells you nothing. Knowing that status is one of a fixed set of order states, and what each one means, is the difference between a usable field and a trap. Two revenue columns of type decimal can mean gross or net, include tax or not, be in different currencies. Semantics are where most quiet misuse happens.
Ownership. A named owner: a team, and ideally a person accountable, who is responsible for the dataset and can be reached when something is wrong or a change is proposed. A contract without an owner is a wish. If you are unsure how to assign this, who owns a data product walks through the accountability question directly.
Service levels. The promises about quality and timeliness. How fresh the data will be (updated hourly, daily, within fifteen minutes of the event). How complete it will be. What the acceptable error or null rate is. These are the SLAs a consumer can plan around, and the thresholds that should raise an alert when missed.
Change and versioning policy. The rules of the road for evolution. Which changes are safe to make freely (adding a new optional field), which are breaking and require a new version and a migration window (removing a field, changing a type, tightening a constraint), and how much notice consumers get. This is the clause that actually stops the silent break, because it turns "the producer changed something" into "the producer proposed a change and the system evaluated it".
The thread running through all five is that each item is explicit, machine readable where possible, and enforceable. A promise nobody can check is just documentation, and documentation drifts out of date the moment it is written. A contract is enforced on every change. This is the same discipline that makes treating data as a product work in practice rather than as a slogan.
Data contract vs schema: what is the difference?
This is the distinction people most often get wrong, so it is worth being blunt. A schema is a shape. A contract is a promise.
A schema tells you that a table has these columns with these types. It is a fact about the current state of the data. It has no owner, no service level, no notion of who depends on it, and crucially no consequence when it changes. You can alter a schema at will, and nothing in the schema itself objects.
A data contract wraps a schema in accountability. It says: this shape is guaranteed, these are the fields you can build on, this is who is responsible, this is how fresh it will be, and if we need to change it, here is the process and the notice you will get. The schema is a component of the contract, not a substitute for it. The table below lays the two out side by side, and adds where governance sits.
| Aspect | Schema | Data contract | Data governance |
|---|---|---|---|
| What it is | The shape of the data now | A promise about the data over time | The control system across all data |
| Scope | One dataset's structure | One producer to consumer relationship | The whole organisation |
| Has an owner? | No | Yes, named and accountable | Yes, a governing function |
| Covers meaning? | No, types only | Yes, semantics of each field | Yes, at policy level |
| Covers SLAs? | No | Yes, freshness and quality | Sets the standards |
| Consequence on change | None | Breaking changes are caught and gated | Policy enforcement and audit |
| Enforced how | Not enforced by itself | Automated checks per change | Access rules, lineage, audit trail |
Data contract vs data governance: are they the same thing?
No, and conflating them muddies both. A data contract is a specific, local agreement between one producer and its consumers about one dataset. Data governance is the broader control system: the policies, access rules, standards, ownership model, and audit capability that apply across the whole organisation.
The relationship is that governance sets the rules that individual contracts live inside. Governance might say that every dataset serving regulated processes must have a named owner, a defined retention period, field level access control, and a tamper evident audit trail. A data contract is where those rules get instantiated for a particular dataset. Governance is the constitution; contracts are the individual agreements written under it. You need both. Contracts without governance are a scattering of local promises with no consistent standard. Governance without contracts is policy with no teeth at the point where data actually changes hands.
How does a data contract stop the silent break?
The silent break happens because a change is made in ignorance of its consequences. The producer does not know who depends on the field they are altering, so they cannot know what they are about to break, so the breakage only surfaces later as a mystery failure downstream.
A data contract closes that gap in two moves. First, it makes the dependency explicit: the contract records that consumers exist and what they rely on. Second, it makes the change evaluable before it ships: because the contract is enforced automatically, a proposed change is checked against the promise, and a breaking change is flagged, gated, or routed through a versioning and notice process instead of sliding through unnoticed.
The mental shift is from "find out what broke after it breaks" to "know what will break before you ship". That second posture is only possible if two things are true. You have to know the shape of the promise, and you have to know the full set of things that depend on it. The second half is data lineage: the map of what feeds what. A contract without lineage can tell you the promise was broken. A contract with lineage can tell you, in advance, exactly which dashboards, syncs, and models a proposed change will hit, so you can decide with your eyes open.
Where does Integrius fit?
Integrius does not sell you a data contract document to fill in. It makes the contract real by making it enforceable, which is the part that usually gets skipped.
A governed data product in Integrius is, in effect, a data contract that the platform enforces for you. Each data product has a canonical schema: the agreed shape and meaning of the fields, defined once and served consistently no matter which underlying systems the data actually comes from. Each has a named owner. Each carries field level access control that is enforced at the point of serving, so the promise about who can see what is not a policy note but a runtime guarantee. And each product is backed by full dependency lineage, so before you change anything you can see what depends on it. That is the "know what breaks before it breaks" idea made operational rather than aspirational.
Because Integrius is self hosted and keeps a tamper evident, hash chained audit trail, the enforcement is also verifiable after the fact, which matters when you are answering to auditors or regulators rather than just to a downstream analyst. This is where a governed data product and a data contract converge: the product is the reusable, access controlled interface, and the contract is the promise that interface will keep behaving. When the schema, the owner, the access rules, and the lineage all live in one enforced place, the contract stops being a document people forget and becomes the way the data actually behaves.
That is the honest position. Integrius is not a data contract tool in the narrow sense, and it is not a governance suite you bolt on afterwards. It is a governed data product platform, and a well defined data product carries the substance of a data contract inside it: an agreed schema, a responsible owner, guaranteed access rules, and the lineage to see a change coming before it arrives.