# ODCS puts pricing, roles and SLAs in the same document as the schema

> The Open Data Contract Standard defines the structure of a data contract document, with thirteen defined sections covering schema, data quality, support channels, pricing, roles and service levels. Version 3.2.0 is the current release, the specification is Apache 2.0 licensed, and a JSON Schema lets you validate contract files in your editor as you write them.

**bitol-io/open-data-contract-standard** — Home of the Open Data Contract Standard (ODCS).

- Repository: https://github.com/bitol-io/open-data-contract-standard
- Website: https://bitol-io.github.io/open-data-contract-standard/
- Stars: 1,189 · Forks: 101
- Language: Shell
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/bitol-io-open-data-contract-standard

## A contract is a document, and the document has fourteen named sections

The standard starts with a plain definition. A data contract defines the agreement between a data producer and consumers, and it is a structured document rather than a tool. The sections are named in the specification and each has its own page under docs/: Fundamentals, Schema, References, Data quality, Support and communication channels, Pricing, Team, Roles, Service-level agreement, Infrastructures and servers, Authoritative definitions, Tags, and a section for custom and other properties. That list is the interesting part of the project, because it says what a data contract is expected to settle. Schema is the part everyone agrees on. The rest, who to contact when the feed breaks, what the data is worth, who owns it, what the service commitment is, is what a contract is for. The reader-friendly rendering of the whole standard lives on a dedicated documentation site, while docs/README.md holds the explanations and several examples, with more examples under docs/examples/.

## Why pricing and support channels belong in a schema document

Two of the sections are unusual for a data specification and they are the ones that make this a contract rather than a schema. Pricing is a defined section, as is Support and communication channels, and there is a further section for Team and for Roles, plus one for the service-level agreement. A schema answers what the fields are. A contract also answers what happens when the data is late, who to email, what the data costs, and who is accountable. Whether every team wants that in the same artefact is a fair question, and the standard does not pretend otherwise, since the existence of a section for custom and other properties means extra material can be carried without leaving the document. The cost is that the document has more required thinking in it than a column list, and that a team with nothing to say about pricing still has to decide what to put there.

## Authoritative definitions and custom properties are the extension points

Two sections decide how far the standard reaches. Authoritative definitions is where a term is defined once and referenced elsewhere, which is the mechanism that keeps a contract internally consistent when the same concept appears in the schema, the quality rules and the support commitments. The section for custom and other properties is the escape hatch, allowing a contract to carry information the standard does not model, including properties specific to one organisation. The section for Tags supports classification across a portfolio of contracts. Together these three are what make the standard usable in practice: a core that is comparable between teams, plus a defined way to hold what is not comparable. The repository also carries a vendors.md file, which suggests the project tracks the ecosystem of parties involved in data contracts, and a resources.md page for articles and other material.

## Validating contract files in the editor with the JSON Schema

There is no install step, because there is nothing to install. The standard is a set of documents, and the practical tooling is the JSON Schema published alongside it, which you import into your editor to get validation of your YAML files as you type. The schema file lives at schema/odcs-json-schema-latest.json in the repository, and the documentation links to instructions for importing a custom JSON Schema into IntelliJ and into VS Code. The flow is therefore short. You point your editor at the schema, and from that point a contract file that violates the structure of the standard is flagged while you write it, rather than in a review three days later. The catch is the one that comes with any schema of this kind, that the latest file tracks the latest version of the standard, so an editor set up against it will accept a v3.2.0 shape and reject a v3.1.0 one until you pin the right schema.

## The media type carries the version, so a file states what it follows

ODCS registers a media type, and the version is part of it:

```bash
application/odcs+yaml;version=3.2.0
```

The structured suffix, plus a version parameter, means a contract file can be typed and versioned in the same way a media file is, which is what lets a catalogue or a data platform distinguish a v3.0 contract from a v3.2 one without parsing the content. The standard also provides a citation for academic and documentation use, and the entry is given as BibTeX:

```bibtex
@manual{ODCS2025,
  title        = {Open Data Contract Standard (ODCS)},
  author       = {{Bitol}},
  organization = {LF AI \& Data Foundation},
  year         = {2025},
  url          = {https://bitol-io.github.io/open-data-contract-standard}
}
```

Note that the citation year is 2025 while the current version is v3.2.0, which is the kind of detail worth catching before you paste a citation into a paper. The organisation named in the entry, LF AI and Data Foundation, is the body behind the standard, and the repository is maintained under the Bitol name with a Slack community linked from the README.

## Version 3.2.0 on a dev branch, with a changelog and a history file

The release cadence is visible in the tags. Version 3.0.2 was published on 2025-03-31, v3.1.0 on 2025-12-08, and v3.2.0 on 2026-09-08, and the last push to the repository was on 2026-09-11, three days after the release. The default branch is dev, which tells you where the work happens between releases, and the repository carries both a CHANGELOG.md and a history.md, the latter presumably recording how the specification reached its current shape. There is also a context7.json file, and a mkdocs.yml with a building-doc.md guide, so the documentation site is generated from the repository rather than maintained separately. The licence is Apache 2.0, with a LICENSE file at the root and a copyright and SPDX header in the README itself, which is what you want for a specification that other people are expected to implement.

## A standard without a runtime leaves the enforcement to you

The honest limitation is that ODCS is a document standard. The repository ships the specification, the JSON Schema and examples, and it does not ship a validator that checks a contract against business rules, a service that watches for contract breaches, or a mechanism that makes a producer fail a pipeline when the data no longer matches what it promised. The data quality section is a section of the document, which means the expectations are written down, but something else has to evaluate them. The alternative approach in most organisations today is a per-team template: a YAML file, a spreadsheet or a wiki page, with a schema check bolted on if anyone bothers. The difference ODCS makes is comparability, since a contract in a fixed structure can be indexed and checked by one tool, and the cost is adopting a standard shape for something every team currently designs for itself. The documented sections for data quality, service level and support are where that investment is supposed to pay back, and they are also the sections a team is most tempted to leave empty.

## Conclusion

ODCS is worth adopting when a data producer and its consumers need a written agreement that covers more than field types, because the sections for support channels, pricing, roles and service levels are the parts a schema cannot express. It is the wrong tool for a team whose only goal is a machine-checked schema, since the standard defines a document and ships a JSON Schema but no runtime enforcement, and you will still have to build the checks that fail a pipeline. Before adopting it, read docs/schema.md and docs/data-quality.md against your current contract templates, import odcs-json-schema-latest.json into your editor to see how much of what you write today already fits, and check the CHANGELOG between v3.1.0 and v3.2.0 before pinning a version in your tooling.

## FAQ

### What is the current version of the Open Data Contract Standard?

Version 3.2.0, published on 2026-09-08, with the last push to the repository on 2026-09-11. The media type registered for the standard is application/odcs+yaml;version=3.2.0.

### How do I validate an ODCS contract file?

Import the published JSON Schema, odcs-json-schema-latest.json, into your editor. The documentation links to instructions for IntelliJ and for VS Code, and the schema validates your YAML contract files as you write them.

### Which sections does an ODCS data contract contain?

The specification defines sections for Fundamentals, Schema, References, Data quality, Support and communication channels, Pricing, Team, Roles, Service-level agreement, Infrastructures and servers, Authoritative definitions, Tags, and custom and other properties. Each one has its own page under docs/.

### What licence is the ODCS specification published under?

Apache 2.0, with a LICENSE file in the repository and an SPDX identifier in the README header. The project states that contributions are welcome.

## Sources

- [bitol-io/open-data-contract-standard on GitHub](https://github.com/bitol-io/open-data-contract-standard)
- [License: Apache-2.0](https://github.com/bitol-io/open-data-contract-standard/blob/dev/LICENSE)
- [Project website](https://bitol-io.github.io/open-data-contract-standard/)
- [README](https://github.com/bitol-io/open-data-contract-standard/blob/dev/README.md)
- [Releases](https://github.com/bitol-io/open-data-contract-standard/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bitol-io-open-data-contract-standard