What is OCDS, the Open Contracting Data Standard?

What is OCDS?

OCDS, the Open Contracting Data Standard, is a free, non-proprietary open data standard for public contracting. It defines how a government publishes structured data and documents about buying goods, works and services, so that one contracting process can be followed from planning through tender, award and contract to implementation.

OCDS is not software. The OCDS documentation is explicit that it is neither an electronic procurement system nor a database. It is a shared data model, expressed as a JSON schema with code lists and guidance, that an e-procurement system, a publication portal or a data warehouse can follow. The current version at the time of writing is 1.1.5, and the standard is published under the Apache License 2.0.

In procurement vocabulary, OCDS belongs to the transparency side of public tendering: it does not change how a tender is run, it changes what the public, auditors, suppliers and the buyer’s own analysts can see and reuse afterwards.

Who maintains the Open Contracting Data Standard?

The Open Contracting Partnership develops and maintains OCDS. It describes itself as an independent non-profit public charity, registered under section 501(c)(3) in the United States. The partnership publishes the standard’s documentation, decides on changes to it and registers the ocid prefixes that publishers need.

Version 1.0 was launched in 2014 and version 1.1 was released in May 2017, according to the partnership’s own upgrade note; later 1.1.x releases have refined the schema without breaking it. The schema’s source is public on GitHub, and needs that the core schema does not cover are met through extensions.

Which stages of the contracting process does OCDS model?

OCDS follows one contracting process through five stages. Each stage maps to a section of the schema, and each publication is labelled with a release tag that says which stage it concerns. The table below combines the schema sections from the release reference with the tags of the release tag code list.

Around these stages sit cross-cutting blocks. The parties section describes every organisation once, with its roles; the buyer field names the entity whose budget will pay; and release metadata records who published what and when. The procurement method uses a short code list: open, selective, limited and direct. The guidance notes that there is no formal restriction on when information about a stage may be published, which matters for countries where planning data is released late or not at all.

What is the difference between an OCDS release and a record?

An OCDS release is a snapshot published each time something changes in a contracting process; it cannot be edited once published. An OCDS record is an index of all the releases for one process, updated as new releases arrive, and it can include a compiled release showing the latest value of every field.

Every release and record carries an Open Contracting ID, the ocid. According to the identifier guidance, it combines a prefix registered with the Open Contracting Partnership, made of “ocds-” and six lowercase letters or digits, with the publisher’s own identifier for the process. The ocid is what allows a tender notice, its award and its contract to be joined, even when they are published by different systems.

How does a government implement OCDS?

The OCDS implementation guidance organises the work in four phases: design, map, build and publish. A fifth concern runs through all of them: the data is only worth publishing if someone uses it, so users are identified in the first phase, not after launch.

1. Design: understand the context, set goals and priorities with the people who will use the data, build the team, and write requirements for the developers of the e-procurement system.
2. Map: identify every source of contracting data, including spreadsheets and paper, then map each data element to an OCDS field with the field-level mapping template and to OCDS codes with the codelist mapping template; add extensions only where no existing field fits.
3. Build: register an ocid prefix, choose the architecture, build the pipeline that produces JSON and tabular CSV or spreadsheet data, offer bulk downloads and, where possible, an API, and check the output with the OCDS Data Review Tool.
4. Publish: run final checks, adopt a publication policy that states scope, frequency, formats and licence, apply an open licence (a public domain dedication is preferred, CC BY 4.0 is the attribution-only alternative), then announce the data.
5. Use: follow up with the users identified at the design phase and fix the gaps they find, which feeds the next round of mapping.

Mapping is where most of the effort goes. The guidance asks that the OCDS publication contain at least as much information as the publisher’s other public contracting datasets, and it provides worked guidance for hard cases such as framework agreements, amendments and beneficial ownership. In practice, the hard part is rarely the JSON: it is agreeing which internal identifier is stable enough to become the ocid, and which system is the authority for an amended contract value.

Why does OCDS matter for e-procurement?

OCDS matters for e-procurement because it turns a tendering platform’s internal records into data that can be compared across buyers, systems and years. The same field names and code lists mean that one analysis tool can read the data of any publisher that follows the standard.

• Monitoring competition: tender, award and party data together show how many bidders took part and who won, process by process.
• Following the money: linking the contract and implementation stages shows amendments and payments against the original award value.
• Planning sourcing: buyers can study past prices and supplier markets before writing a new tender, which is ordinary strategic sourcing practice applied to public data.
• Specifying systems: a government that adopts OCDS can write it into the requirements of its next e-procurement system, so that publication is built in rather than bolted on.

The standard does not make procurement better on its own. Published data can be incomplete, late or inconsistent, which is why the guidance insists on a publication policy and regular quality checks, and why the Open Contracting Partnership offers data quality feedback to publishers.