Open Data Contract Standard

Overview

The Open Data Contract Standard is a specification, not a tool. It defines the agreement between a data producer and its consumers as a single YAML file, and leaves execution to others.

It is stewarded by Bitol, a Linux Foundation AI and Data incubation project, under Apache 2.0, which makes it the vendor-neutral layer the rest of this category builds on.

A contract covers fifteen published areas, from fundamentals and schema through context, references, data quality, support channels, pricing, team, roles, service levels, servers, tags and variables.

Its stated design principle is that the contract should be platform agnostic, and that shows in the servers section, which describes where data lives without the contract depending on it.

Data quality is first-class rather than bolted on, with eight comparison operators from must-be through must-be- between, and custom rules that can name engines such as Soda, Great Expectations, dbt tests or Monte Carlo.

Service levels are executable, not documentation. The schema carries a scheduler and a schedule, so latency, retention, availability and time-to-repair can be checked rather than merely promised.

Version 3.2.0, published in September 2026, turned towards AI: its headline is telling agents how to use your data, what is verified and what they must never do.

It also added synonyms with locale and provenance, variable interpolation, logical types for vectors, maps and enums, semantic roles for measures and dimensions, and field-level deprecation that retires a field without breaking consumers.

Compatibility discipline is good. Version 3.1.0 shipped with zero breaking changes, so every contract valid against 3.0.2 stayed valid, and nine new server types arrived in 3.2.0 including Iceberg, SAP HANA and Teradata.

What it deliberately does not do is enforce. There is no consequence model in the specification; that belongs to the tool implementing it, of which the docs list around twenty-one.

Key features and capabilities

The same headings are used for every data contracts entry, so two tools can be read side by side.

What a contract covers

• Fifteen published areas, from fundamentals and schema to pricing, team, roles and service levels
• Schema covers objects and properties, logical and physical types, keys, partitions, enums, maps and vectors
• Semantics through context, authoritative definitions, tags, synonyms with provenance, and relationships
• Service levels covering latency, retention, frequency, availability, error rate and time to repair
• Terms of use and ownership through dedicated pricing, team, roles and support sections

Specification and format

• A single YAML file, with a registered media type carrying the version
• Validated by a published JSON Schema, made strict in 3.1.0 to remove ambiguity
• Required fields are the API version, the kind, a unique identifier and the contract version
• Status values such as proposed, draft, active, deprecated and retired are given as examples rather than a closed set
• Whether the version field must follow semantic versioning is not published, and no breaking change is formally defined

How contracts are enforced

• The specification does not enforce; Bitol describes contracts as enforceable and actionable by tools
• Quality rules carry eight comparison operators, from must-be to must-be-between
• Service levels are schedulable, carrying a scheduler and a schedule expression
• Custom quality rules can name external engines such as Soda, Great Expectations or dbt tests
• What happens on violation is deliberately left to the implementing tool

Authoring and review workflow

• Contracts are authored as YAML and committed to a repository, or built through a tool
• An official Excel template and third-party editors are listed as authoring routes
• Ownership is expressed in the contract itself through team and role sections
• Specification changes run through RFCs discussed in the steering committee
• Version discipline is compatibility-first, with 3.1.0 shipping zero breaking changes

Tooling and validation

• A published JSON Schema as the canonical lint target
• An official Python package for reading and writing contract files
• An official Excel template for authoring
• A worked example library covering Postgres, Kafka with schema registry, and every data type
• Field-level deprecation lets a field be retired without breaking existing consumers

Integrations

• Around twenty-one independent implementations are listed, including the Data Contract CLI and Data Contract Manager
• Also Actian, Collate, Databricks Ontos, IBM watsonx, DQC.ai and Witboost
• Server and platform coverage is in the specification, with nine types added in 3.2.0
• Quality rules integrate named engines rather than shipping one
• Service providers are listed separately from software vendors

Where it runs and what it costs

• Not applicable, since it is a document standard rather than software
• Distributed through GitHub plus versioned documentation, with pinned and latest versions
• Community on GitHub, Slack and LinkedIn
• No managed service or hosted registry is offered by Bitol
• A sibling standard for data products is stewarded alongside it

Pricing

Open sourceFree, Apache 2.0

Free under Apache 2.0, with no paid tier, no commercial licence and no registration. As a Linux Foundation AI and Data incubation project, Bitol sells nothing at all. Any cost comes from the tools you choose to implement the standard with, of which the documentation lists around twenty-one, ranging from free command-line tools to commercial platforms. That separation is the point of adopting a standard rather than a product: the contract file stays yours and portable between them.

Vendor pricing page →

Demos and videos

• Open Data Contract Standard specification Tutorial · bitol.io
• Worked contract examples Product demo · bitol.io

About Bitol

The standard is stewarded by Bitol, described on its own site as a Linux Foundation AI and Data incubation project licensed under Apache 2.0, and governed by a technical steering committee chaired by Jean-Georges Perrin. The committee publishes its eleven members with their constituency, split between users, consultancies and software vendors across Europe and the United States; notably the authors of the Data Contract CLI sit on it, so the tooling and the standard are aligned rather than competing. Election rules, voting thresholds and meeting cadence are not published. The repository has around 45 contributors and was transferred in from the AIDA User Group.

Founded 2023 · bitol.io