Data Contracts: What Is a Data Contract, the Open Data Contract Standard, and Examples

The standard itself, not a product

This is now the industry standard, and as of December 2025 it is effectively the only one. ODCS is a YAML format that describes a dataset as an agreement: who owns it, what its schema is, what quality rules hold, what the service level is, and how to reach the team behind it. Version 3.1.0 was released on 8 December 2025, it carries the media type application/odcs+yaml;version=3.1.0, and the project sits under the LF AI and Data Foundation with Apache 2.0 licensing and roughly 1,075 GitHub stars. Eleven top-level areas make up a contract: fundamentals, schema, references, data quality, support and communication channels, pricing, team, roles, service-level agreement, infrastructure and servers, and custom properties. Only the first two are usually filled in on a first attempt, which is fine. The standard is deliberately additive.

The other standard, now deprecated

Read this entry before you follow any tutorial written before 2026. The Data Contract Specification, the OpenAPI-flavoured YAML format from the datacontract.com project, deprecated itself. Its README now opens with a deprecation notice: "With the release of the Open Data Contract Standard v3.1.0, we deprecate the Data Contract Specification in line with our commitment to focus on a single industry standard for data contracts." The same notice recommends migrating within the next few months and says the format will be supported in the Data Contract CLI and Entropy Data only until the end of 2026. The README goes further and calls ODCS "the conceptual successor". Almost every comparison article still frames these two as competing options you have to choose between. That choice was made and announced by one of the two parties, and the category consolidated onto ODCS.

Open-source tool to lint, test and convert contracts

The most practical starting point, because it turns a YAML file into something that fails a build. It lints a contract for validity, connects to a data source and runs the schema and quality tests the contract declares, generates a changelog between two versions so you can see what changed, and exports to more than twenty-five formats including dbt models and sources, JSON Schema, Avro, SodaCL, SQL, Terraform, and ODCS itself. Import works the other way, so you can generate a first draft from an existing BigQuery table, Glue catalog, or SQL DDL rather than writing YAML from a blank file. It is healthy and moving fast: version 1.1.0 landed on PyPI on 4 August 2026, and it natively supports ODCS. Python 3.10 to 3.12, with 3.11 recommended.

Contract enforcement built into dbt

If your transformations already run through dbt, this is the contract enforcement you can turn on this afternoon. Set contract: enforced: true on a model, declare every column name and data type, and dbt runs a preflight check before building: if the query would return a different shape, the build fails rather than shipping the change. dbt-core 1.12.0 shipped on 16 July 2026. Two limits matter and are widely misunderstood. First, it is all or nothing per model, because dbt requires explicit expectations for every column in a contracted model, not just the ones you care about. Second, and more important, most constraints you can declare are not actually enforced by the warehouse. On Snowflake, BigQuery, and Redshift only not_null is enforced; primary_key, foreign_key, and unique are definable and purely informational. Postgres enforces all of them. We wrote up the full matrix in our guide to data contracts in dbt.

Data quality checks that grew into a contracts engine

Soda made the biggest bet of any vendor in this category on contracts being the durable artifact. The soda-core GitHub repository now describes the project as a "Data Contracts engine for the modern data stack", which is a repositioning from data quality testing rather than an addition to it, and Collaborative Data Contracts sit alongside quality checks in the commercial product. Soda Core 4.21.0 was published on 13 August 2026, so this is not a stale rebrand. Check the license before you build on it, though: the v4 release replaced Apache-2.0 with the Elastic License 2.0 in January 2026, and PyPI now declares soda-core Proprietary, which makes it source-available rather than open source. Our Soda alternative page covers what that changes. Checks are written in SodaCL, a YAML language that reads closer to a sentence than to SQL, and the work is pushed down into the warehouse rather than pulling rows out. Soda is also one of very few vendors in the whole data-contract and data-quality space that publishes a price: a free tier, a Team plan at $750 per month, and enterprise quoted separately. The trade is that YAML gets awkward once checks become genuinely complicated.

Shift-left contract enforcement in code review

Gable attacks the problem from the only place it can genuinely be prevented: the application repository where a producer is about to change a field. Rather than checking data after it lands, it inspects the code change, works out which downstream data assets it affects, and comments on the pull request before the change merges. That is the correct theory of the problem, and it is also the hardest kind of adoption to win, because it requires the software engineering teams who produce the data to accept a gate in their own workflow. The CLI is actively maintained, at version 0.64.3 on PyPI as of 22 July 2026. No pricing is published, so budget from a quote.

Contract enforcement for streaming, predating the term

Worth naming because Kafka teams have been running data contracts for a decade without calling them that. A schema registry stores the schema for each topic and enforces a compatibility rule (backward, forward, full, or none) when a producer registers a new version. Break the rule and registration is rejected, which is genuine enforcement at the point of production rather than a document nobody reads. What it does not cover is everything ODCS added around the schema: no ownership, no service level, no data quality expectations beyond structure, and nothing about the warehouse tables the topic eventually lands in. If your data moves through Kafka, you already have the structural half of a contract, and the contract work left to do is the semantic half.

Catalog with contracts assembled from assertions

DataHub models a data contract as an agreement bound to a single physical asset and owned by its producer, assembled from assertions you have already defined. Its documentation is explicit that a contract is verifiable against real data rather than metadata, and that freshness, schema, and data quality assertions must exist before you can attach them. That is a sound design: the contract becomes a named bundle of checks with an owner and a status, rather than a separate artifact that drifts from what is actually being tested. The practical caveat is that assertion scheduling is documented under DataHub Cloud Observe, so confirm what is available in DataHub Core for your version before assuming the whole workflow is free. DataHub Core itself is Apache 2.0 and healthy. DataHub Cloud publishes no pricing.

Table constraints in the warehouse itself

The trap that catches teams who think they can express a contract in DDL and be done. Snowflake's own constraints documentation states that on standard tables, PRIMARY KEY, UNIQUE, and FOREIGN KEY are optional and not enforced; only NOT NULL is enforced. Hybrid tables are the exception, where primary and foreign keys are both required and enforced. Databricks behaves similarly: NOT NULL and CHECK are enforced, while primary and foreign keys are informational. So a declared primary key on a Snowflake table is documentation that the query optimizer may use, not a guarantee, and duplicate rows will land in it without complaint. Anything you need actually enforced on a warehouse table has to be checked by something outside the DDL.

Detects contract breaches and names what they break

Datatrail is not a contract authoring tool and does not try to be one. It solves the half of the problem that authoring leaves open: knowing that a contract was broken, and knowing immediately who is affected. It connects to Snowflake, BigQuery, Redshift, Databricks, or Postgres with a read-only role, builds a column-level lineage graph from query history and your dbt manifest, learns each table's normal freshness, volume, null rate, and column distributions, and alerts when any of them moves outside that baseline or when a schema changes. Because the alert arrives attached to the lineage graph, it already names the models, exposures, and dashboards reading the affected column. That is the missing piece in most contract programs: a contract states what the consumers were promised, and lineage is what tells you which consumers just stopped getting it. Use it alongside ODCS and the Data Contract CLI, not instead of them.

Assertion framework, often used to back a contract

Not a contract tool, but the engine a lot of contract implementations end up sitting on, because a contract's quality section has to be executed by something. You write Expectations, group them into suites, and run them through Checkpoints against a dataframe, a file, or a warehouse table, which means the same rules can run before data lands and after. GX Core 1.20.0 was published on 7 August 2026. Two things to check before adopting: ownership split in 2026, with FICO acquiring GX Cloud and Fivetran becoming steward of the open-source GX Core, so evaluate the library rather than the hosted product, and GX 1.0 removed the profilers older tutorials still reference.

Governance platforms adding contract features

The established governance vendors have all attached data contract features to existing catalogs, and the shape is consistent: a contract becomes another governed object alongside glossary terms, policies, and ownership, with approval workflow around it. That is genuinely valuable in an organization that already runs governance in one of these platforms, because the contract inherits the stewardship model instead of needing a new one. It is the wrong entry point if you do not, because you are buying a governance platform to get a YAML file. None of the three publishes pricing, all quote per deployment, and the third-party annual figures circulating on review and procurement sites contradict each other badly enough that some are simply wrong. We do not reprint them.

What is a data contract?

A data contract is a machine-readable agreement between the team that produces a dataset and the teams that consume it, defining the schema, semantics, quality expectations, and service level of that data. It is usually a YAML file kept in version control next to the code that produces the data, which means changes to it are reviewed like code and a breaking change can fail a build. The common analogy is that a data contract does for data what an API specification does for a service.

What is the Open Data Contract Standard?

The Open Data Contract Standard, usually shortened to ODCS, is the open YAML specification for data contracts maintained under the LF AI and Data Foundation as part of the Bitol project. Version 3.1.0 was released on 8 December 2025 under Apache 2.0. It defines eleven top-level areas including fundamentals, schema, data quality, service-level agreement, team, roles, and servers. As of that release it is the de facto single industry standard, because the competing Data Contract Specification deprecated itself in favour of it.

What does a data contract look like?

It is a YAML file, usually between thirty and a hundred lines for a real table. The top declares the contract version, the dataset name, its owner, and its status. A schema block lists every column with its logical and physical type and flags the required ones. A quality block declares the rules that must hold, such as a null threshold or a freshness window. Optional blocks cover the service level, the support channel, and the team. Our worked example below is a complete ODCS contract for an orders table.

What is the difference between a data contract and a schema?

A schema describes structure: column names and types. A data contract wraps that schema in everything a consumer actually needs to depend on it, which is ownership, semantics, quality guarantees, a service level, a support channel, and a versioning policy. The distinction matters because most production incidents are not schema breaks. A column that keeps its name and type but starts arriving twelve hours late, or silently switches units, passes every schema check and breaks every dashboard.

Are data contracts worth it?

They pay off when data crosses a team boundary and the producer has no idea who depends on them. That is the specific condition. If one team owns the pipeline end to end, a contract adds ceremony without adding information, and dbt tests will serve you better. If a software engineering team ships a schema change on Tuesday and the finance dashboard breaks on Wednesday, a contract is the artifact that makes that failure preventable rather than merely detectable.

How do you enforce a data contract?

At one of five points, and most programs use two or three. In the producer's pull request, which prevents the breakage. At produce time via a schema registry, for streaming data. In CI or the pipeline, where the Data Contract CLI, Soda, or Great Expectations can fail a build against a real data source. At dbt build time, using enforced model contracts. And continuously after the data lands, with monitoring that catches what no rule anticipated. Warehouse DDL is not a fifth option, because most constraints on cloud warehouses are informational.

What is a data SLA?

A data SLA is the part of a data contract that promises timing and availability rather than structure: how often the dataset updates, the latest time it will be ready, how long history is retained, and what availability the producer commits to. In ODCS it is a first-class section of the contract. It is the clause consumers care about most and producers write last, because freshness misses cause more visible pain than schema changes do.

What is the difference between the Open Data Contract Standard and the Data Contract Specification?

They were the two competing YAML formats, and that competition ended. The Data Contract Specification, at version 1.2.1, carries a deprecation notice in its own README stating that with the release of ODCS v3.1.0 it is deprecated "in line with our commitment to focus on a single industry standard for data contracts", calls ODCS the conceptual successor, and says support in the Data Contract CLI and Entropy Data continues only until the end of 2026. If you are starting now, start with ODCS. If you have existing contracts in the older format, the Data Contract CLI exports to ODCS.

Do data contracts replace data quality tests?

No. A contract declares what must be true; tests are one of the mechanisms that check it. In practice the quality section of a contract is executed by a test engine such as the Data Contract CLI, Soda, or Great Expectations, so adopting contracts usually means keeping the tests you have and moving the declaration of them into a versioned, owned artifact. What contracts add is the ownership, the service level, and the review gate, none of which a test suite provides.

How do you start with data contracts?

Pick the one dataset that has broken most often across a team boundary and write a contract for only that. Generate a first draft with the Data Contract CLI import command against the existing table rather than starting from an empty file, fill in the owner and the support channel, and add three quality rules rather than thirty. Wire the lint and test commands into CI so a breaking change fails. Then stop and let it run for a month before expanding, because the failure mode of contract programs is a hundred unowned YAML files, not too few.