Release Reference

The Release Schema provides a detailed specification of the fields and data structures to use when publishing contracting data. Supplementary schemas show how to combine releases into release packages and how to compile releases into records.

Releases are immutable – presenting information about a particular event in the lifetime of a contracting process. Publishers must not edit a release after publication; a new release can be created by changing the release's id and date.

Note: If any conflicts are found between this text, and the text within the schema, the schema takes precedence.

Browsing the schema

This page presents the release schema in tables, with additional information in paragraphs. You can also download the canonical version of the release schema as JSON Schema, download it as a CSV spreadsheet, view it in an interactive browser, or access it through the Field-Level Mapping Template.

Release handling

The full OCDS data model is based on the idea of publishing a new release every time information about a contracting process changes. This way, users can gain a full view of change over time, and third-parties can understand what needs to be updated in any system that is tracking the progress of a contracting process.

Publishers will need to choose how to generate new releases, and whether to repeat information in each release, or just to provide changes. This choice ought to be based on an understanding of the merging process that is used to generate a snapshot record of a full contracting process.

In this model, publishers need to to pay careful attention to null values and missing fields.

Empty fields

Fields that are not being used, or that have no value, should be excluded in their entirety (key and value) from a published file.

Only including fields which have values will keep versioned datasets cleaner.

Emptying fields and values

There can be cases where a publisher needs to remove, rather than update, a value which was set in a previous release. In this case, the fields must be set to null. See the merging documentation for more details.

Language

Many publishers need to be able to share key data in multiple languages. All free-text title and description fields in the Open Contracting Data Standard can be given in one or more languages.

Language variations are included by a copy of multi-lingual fields, suffixed with a language code.

E.g. title and title_es

In order to allow users to identify the language used in non-suffixed fields, OCDS release and records should declare the default language in the language field.

Languages must be identified using language tags taken from BCP47. The specification allows BCP47 values in order to accommodate variations in dialect where this is important. However, publishers should use the lowercase two-letter ISO639-1 language tags in the vast majority of circumstances, to avoid users having to distinguish between sub-tag variations (for example, OCDS publishers should use 'en' instead of 'en_US' or 'en_GB').

To include a language variation of a field, the field name must be suffixed with _ and the appropriate language tag. For example: title_es for Spanish.

Worked example

A contract for ‘Software consultancy services’ is published in a release with the default language sent to ‘en’ (the ISO639-1 code for English). The following examples give the description of an item as English, French and Spanish.

json

{
    "language": "en",
    "tender": {
        "item": {
            "description": "Software consultancy services",
            "description_es": "Servicios de consultoria en software",
            "description_fr": "Services de conseil en logiciels"
        }
    }
}

csv

description

description_es

description_fr

Software consultancy services

Servicios de consultoria en software

Services de conseil en logiciels

Release structure

The majority of OCDS data is held within a release structure. One or more releases can be published within a release package. Releases are made up of a number of sections, arranged in the following structure.

Releases are given a tag to indicate the specific stage of a contracting process they represent. However, there are no formal restrictions on when information about a stage of the contracting process can be provided.

For example, a publisher announcing the signing of a contract with a 'contract' tag might also include information in the award and tender blocks in order to provide a comprehensive picture of the contracting process to date which led to that contract being signed.

Package Metadata

Releases must be published within a release package. The release package provides metadata about the release(s) that it contains.

Title

Description

Type

Format

Required

uri

string

uri

Required

Package identifier

The URI of this package that identifies it uniquely in the world. Recommended practice is to use a dereferenceable URI, where a persistent copy of this package is available.

version

string

Required

OCDS schema version

The version of the OCDS schema used in this package, expressed as major.minor For example: 1.0 or 1.1

extensions

array[string]

OCDS extensions

An array of OCDS extensions used in this package, in which each array item is the URL of an extension.json file.

publishedDate

string

date-time

Required

Published date

The date that this package was published. If this package is generated 'on demand', this date should reflect the date of the last change to the underlying contents of the package.

releases

array[object]

Releases

An array of one or more OCDS releases.

See release-schema.json

publisher

object

Required

Publisher

Information to uniquely identify the publisher of this package.

license

[string, null]

uri

License

A link to the license that applies to the data in this package. A Public Domain Dedication or Open Definition Conformant license is recommended. The canonical URI of the license should be used. Documents linked from this file may be under other license conditions.

publicationPolicy

[string, null]

uri

Publication policy

A link to a document describing the publishers publication policy.

See the licensing guidance for more details on selecting a license, and publishing license information.

See the publication policy guidance for more details on what to include in a publication policy.

Release

All new information about a contracting process is described within a release.

Title

Description

Type

Format

Required

ocid

string

Required

Open Contracting ID

A globally unique identifier for this Open Contracting Process. Composed of an ocid prefix and an identifier for the contracting process. For more information see the Open Contracting Identifier guidance

id

string

Required

Release ID

An identifier for this particular release of information. A release identifier must be unique within the scope of its related contracting process (defined by a common ocid). A release identifier must not contain the # character.

date

string

date-time

Required

Release Date

The date on which the information contained in the release was first recorded in, or published by, any system.

tag

array[string]

Release Tag

One or more values from the closed releaseTag codelist. Tags can be used to filter releases and to understand the kind of information that releases might contain.

initiationType

string

Required

Initiation type

The type of initiation process used for this contract, from the closed initiationType codelist.

parties

array[Organization]

Parties

Information on the parties (organizations, economic operators and other participants) who are involved in the contracting process and their roles, e.g. buyer, procuring entity, supplier etc. Organization references elsewhere in the schema are used to refer back to this entries in this list.

See Organization

buyer

object

Buyer

A buyer is an entity whose budget will be used to pay for goods, works or services related to a contract. This may be different from the procuring entity who may be specified in the tender data.

See OrganizationReference

planning

object

Planning

Information from the planning phase of the contracting process. This includes information related to the process of deciding what to contract, when and how.

See Planning

tender

object

Tender

The activities undertaken in order to enter into a contract.

See Tender

awards

array[Award]

Awards

Information from the award phase of the contracting process. There can be more than one award per contracting process e.g. because the contract is split among different providers, or because it is a standing offer.

See Award

contracts

array[Contract]

Contracts

Information from the contract creation phase of the procurement process.

See Contract

language

[string, null]

Release language

The default language of the data using either two-letter ISO639-1, or extended BCP47 language tags. The use of lowercase two-letter codes from ISO639-1 is recommended.

relatedProcesses

array[Related Process]

Related processes

The details of related processes: for example, if this process follows on from one or more other processes, represented under a separate open contracting identifier (ocid). This is commonly used to relate mini-competitions to their parent frameworks or individual tenders to a broader planning process.

See RelatedProcess

The following extensions are available for release

Process level title and description

For providing overall process titles and descriptions, often to give a free-text summary of the contracting process as a whole.

The following are community extensions and are not maintained by Open Contracting Partnership.

Parties

Each of the parties (organizations or other participants) referenced in a release must be included in the parties section.

Parties

Version 1.1 of OCDS introduces a new approach to describing the buyers, suppliers, economic operators, and other participants in a contracting process. Instead of embedding organization information at various points within an OCDS release, information on all the parties involved in a contracting process is collected together in a top-level section, and the parties indicated by a cross-reference to their id at other points.

This reduces repetition of information on parties who appear at multiple points in the contracting process, and supports publication of information about additional parties to the contracting process, including auditors, multiple buyers, and consortia partners of a winning bidder.

The old, embedded data, approach to organization data is deprecated in OCDS 1.1, and will be removed in version 2.0.

The following details can be provided for each party.

Title

Description

Type

Format

Required

name

[string, null]

Common name

A common name for this organization or other participant in the contracting process. The identifier object provides a space for the formal legal name, and so this may either repeat that value, or may provide the common name by which this organization or entity is known. This field may also include details of the department or sub-unit involved in this contracting process.

id

string

Entity ID

The ID used for cross-referencing to this party from other sections of the release. This field may be built with the following structure {identifier.scheme}-{identifier.id}(-{department-identifier}).

identifier

object

Primary identifier

The primary identifier for this organization or participant. Identifiers that uniquely pick out a legal entity should be preferred. Consult the organization identifier guidance for the preferred scheme and identifier to use.

See Identifier

additionalIdentifiers

array[Identifier]

Additional identifiers

A list of additional / supplemental identifiers for the organization or participant, using the organization identifier guidance. This can be used to provide an internally used identifier for this organization in addition to the primary legal entity identifier.

See Identifier

address

object

Address

An address. This may be the legally registered address of the organization, or may be a correspondence address for this particular contracting process.

See Address

contactPoint

object

Contact point

Contact details that can be used for this party.

See ContactPoint

roles

array[string]

Party roles

The party's role(s) in the contracting process, using the open partyRole codelist.

details

[object, null]

Details

Additional classification information about parties can be provided using partyDetail extensions that define particular fields and classification schemes.

The following extensions are available for parties

The following are community extensions and are not maintained by Open Contracting Partnership.

Each party has a details object. Through extensions, this can be used to provide detailed classification of parties.

The following extensions are available for party details

The following are community extensions and are not maintained by Open Contracting Partnership.

Planning

The planning section can be used to describe the background to a contracting process. This can include details of the budget from which funds are drawn, or related projects for this contracting process. Background documents such as a needs assessment, feasibility study and project plan can also be included in this section.

Title

Description

Type

Format

Required

rationale

[string, null]

Rationale

The rationale for the procurement provided in free text. More detail can be provided in an attached document.

budget

object

Budget

Details of the budget that funds this contracting process.

See Budget

documents

array[Document]

Documents

A list of documents related to the planning process.

See Document

milestones

array[Milestone]

Planning milestones

A list of milestones associated with the planning stage.

See Milestone

The following extensions are available for planning

The following are community extensions and are not maintained by Open Contracting Partnership.

Budget

Apart from documents, the majority of planning information is held within the budget block. This is designed to allow both machine-readable linkable data about budgets, cross-referencing to data held in other standards such as the Fiscal Data Package or International Aid Transparency Initiative Standard, and human readable description of the related budgets and projects, supporting users to understand the relationship of the contracting process to existing projects and budgets even where linked data is not available.

Title

Description

Type

Format

Required

id

[string, integer, null]

ID

An identifier for the budget line item which provides funds for this contracting process. This identifier should be possible to cross-reference against the provided data source.

description

[string, null]

Budget Source

A short free text description of the budget source. May be used to provide the title of the budget line, or the programme used to fund this project.

amount

object

Amount

The value reserved in the budget for this contracting process. A negative value indicates anticipated income to the budget as a result of this contracting process, rather than expenditure. Where the budget is drawn from multiple sources, the budget breakdown extension can be used.

See Value

project

[string, null]

Project title

The name of the project through which this contracting process is funded (if applicable). Some organizations maintain a registry of projects, and the data should use the name by which the project is known in that registry. No translation option is offered for this string, as translated values can be provided in third-party data, linked from the data source above.

projectID

[string, integer, null]

Project identifier

An external identifier for the project that this contracting process forms part of, or is funded via (if applicable). Some organizations maintain a registry of projects, and the data should use the identifier from the relevant registry of projects.

uri

[string, null]

uri

Linked budget information

A URI pointing directly to a machine-readable record about the budget line-item or line-items that fund this contracting process. Information can be provided in a range of formats, including using IATI, the Open Fiscal Data Standard or any other standard which provides structured data on budget sources. Human readable documents can be included using the planning.documents block.

source

[string, null]

uri

Data Source

(Deprecated in 1.1) Used to point either to a corresponding Budget Data Package, or to a machine or human-readable source where users can find further information on the budget line item identifiers, or project identifiers, provided here.

This property was deprecated in version 1.1

The budget data source field was intended to link to machine-readable data about the budget for a contracting process, but has been widely mis-used to provide free-text descriptions of budget providers. As a result, it has been removed from version 1.1. budget/uri can be used to provide a link to machine-readable budget information, and budget/description can be used to provide human-readable information on the budget source.

The following extensions are available for budget

The following are community extensions and are not maintained by Open Contracting Partnership.

Tender

The tender section includes details of the announcement that an organization intends to source some particular goods, works or services, and to establish one or more contract(s) for these.

It can contain details of a forthcoming process to receive and evaluate proposals to supply these goods and services, and can also be used to record details of a completed tender process, including details of bids received.

Title

Description

Type

Format

Required

id

[string, integer]

Required

Tender ID

An identifier for this tender process. This may be the same as the ocid, or may be an internal identifier for this tender.

title

[string, null]

Tender title

A title for this tender. This will often be used by applications as a headline to attract interest, and to help analysts understand the nature of this procurement.

description

[string, null]

Tender description

A summary description of the tender. This complements any structured information provided using the items array. Descriptions should be short and easy to read. Avoid using ALL CAPS.

status

[string, null]

Tender status

The current status of the tender, from the closed tenderStatus codelist.

procuringEntity

object

Procuring entity

The entity managing the procurement. This may be different from the buyer who pays for, or uses, the items being procured.

See OrganizationReference

items

array[Item]

Items to be procured

The goods and services to be purchased, broken into line items wherever possible. Items should not be duplicated, but the quantity specified instead.

See Item

value

object

Value

The total upper estimated value of the procurement. A negative value indicates that the contracting process may involve payments from the supplier to the buyer (commonly used in concession contracts).

See Value

minValue

object

Minimum value

The minimum estimated value of the procurement. A negative value indicates that the contracting process may involve payments from the supplier to the buyer (commonly used in concession contracts).

See Value

procurementMethod

[string, null]

Procurement method

The procurement method, from the closed method codelist.

procurementMethodDetails

[string, null]

Procurement method details

Additional detail on the procurement method used. This field can be used to provide the local name of the particular procurement method used.

procurementMethodRationale

[string, null]

Procurement method rationale

Rationale for the chosen procurement method. This is especially important to provide a justification in the case of limited tenders or direct awards.

mainProcurementCategory

[string, null]

Main procurement category

The primary category describing the main object of this contracting process, from the closed procurementCategory codelist.

additionalProcurementCategories

array[string]

Additional procurement categories

Any additional categories describing the objects of this contracting process, using the open extendedProcurementCategory codelist.

awardCriteria

[string, null]

Award criteria

The award criteria for the procurement, using the open awardCriteria codelist.

awardCriteriaDetails

[string, null]

Award criteria details

Any detailed or further information on the award or selection criteria.

submissionMethod

array[string]

Submission method

The methods by which bids are submitted, using the open submissionMethod codelist.

submissionMethodDetails

[string, null]

Submission method details

Any detailed or further information on the submission method. This can include the address, e-mail address or online service to which bids are submitted, and any special requirements to be followed for submissions.

tenderPeriod

object

Tender period

The period when the tender is open for submissions. The end date is the closing date for tender submissions.

See Period

enquiryPeriod

object

Enquiry period

The period during which potential bidders may submit questions and requests for clarification to the entity managing procurement. Details of how to submit enquiries should be provided in attached notices, or in submissionMethodDetails. Structured dates for when responses to questions will be made can be provided using tender milestones.

See Period

hasEnquiries

[boolean, null]

Has enquiries?

A true/false field to indicate whether any enquiries were received during the tender process. Structured information on enquiries that were received, and responses to them, can be provided using the enquiries extension.

eligibilityCriteria

[string, null]

Eligibility criteria

A description of any eligibility criteria for potential suppliers.

awardPeriod

object

Evaluation and award period

The period for decision making regarding the contract award. The end date should be the date on which an award decision is due to be finalized. The start date may be used to indicate the start of an evaluation period.

See Period

contractPeriod

object

Contract period

The period over which the contract is estimated or required to be active. If the tender does not specify explicit dates, the duration field may be used.

See Period

numberOfTenderers

[integer, null]

Number of tenderers

The number of parties who submit a bid.

tenderers

array[Organization reference]

Tenderers

All parties who submit a bid on a tender. More detailed information on bids and the bidding organization can be provided using the bid extension.

See OrganizationReference

documents

array[Document]

Documents

All documents and attachments related to the tender, including any notices. See the documentType codelist for details of potential documents to include. Common documents include official legal notices of tender, technical specifications, evaluation criteria, and, as a tender process progresses, clarifications and replies to queries.

See Document

milestones

array[Milestone]

Milestones

A list of milestones associated with the tender.

See Milestone

amendments

array[Amendment]

Amendments

A tender amendment is a formal change to the tender, and generally involves the publication of a new tender notice/release. The rationale and a description of the changes made can be provided here.

See Amendment

amendment

object

Amendment

The use of individual amendment objects has been deprecated. From OCDS 1.1 information should be provided in the amendments array.

See Amendment

This property was deprecated in version 1.1

The single amendment object has been deprecated in favour of including amendments in an amendments (plural) array.

The following extensions are available for the tender section

Enquiries

The enquiries extension can be used to record questions raised during a contracting process, and the answers provided.

Lots

A tender process can be divided into lots, where bidders can bid on one or more lots. Details of each lot can be provided here. Items, documents and other features may then reference the lot they are related to using relatedLot. Where no relatedLot identifier is given, the values ought to be interpreted as applicable to the whole tender.

Participation Fees

Where a tender process involves payment of fees to access documents, submit a proposal, or be awarded a contract, this extension can be used to provide fee details.

The following are community extensions and are not maintained by Open Contracting Partnership.

Bids

The Bid statistics and details extension can be used to provide bid statistics and detailed information about individual bids.

Award

The award section is used to announce any awards issued for this tender. There can be multiple awards made. Releases can contain all, or a subset, of these awards. A related award block is required for every contract block, as the award contains information on the suppliers.

Title

Description

Type

Format

Required

id

[string, integer]

Required

Award ID

The identifier for this award. It must be unique and must not change within the Open Contracting Process it is part of (defined by a single ocid). See the identifier guidance for further details.

title

[string, null]

Title

Award title

description

[string, null]

Description

Award description

status

[string, null]

Award status

The current status of the award, from the closed awardStatus codelist.

date

[string, null]

date-time

Award date

The date of the contract award. This is usually the date on which a decision to award was made.

value

object

Value

The total value of this award. In the case of a framework contract this may be the total estimated lifetime value, or maximum value, of the agreement. There may be more than one award per procurement. A negative value indicates that the award may involve payments from the supplier to the buyer (commonly used in concession contracts).

See Value

suppliers

array[Organization reference]

Suppliers

The suppliers awarded this award. If different suppliers have been awarded different items or values, these should be split into separate award blocks.

See OrganizationReference

items

array[Item]

Items awarded

The goods and services awarded in this award, broken into line items wherever possible. Items should not be duplicated, but the quantity specified instead.

See Item

contractPeriod

object

Contract period

The period for which the contract has been awarded.

See Period

documents

array[Document]

Documents

All documents and attachments related to the award, including any notices.

See Document

amendments

array[Amendment]

Amendments

An award amendment is a formal change to the details of the award, and generally involves the publication of a new award notice/release. The rationale and a description of the changes made can be provided here.

See Amendment

amendment

object

Amendment

The use of individual amendment objects has been deprecated. From OCDS 1.1 information should be provided in the amendments array.

See Amendment

This property was deprecated in version 1.1

The single amendment object has been deprecated in favour of including amendments in an amendments (plural) array.

The following extensions are available for award

The following are community extensions and are not maintained by Open Contracting Partnership.

Contract

The contract section is used to provide details of contracts that have been entered into. Every contract must have a related award, linked via the awardID field. This is because supplier information is contained within the 'award'. The framework contract details below help illustrate the reasons for this.

Title

Description

Type

Format

Required

id

[string, integer]

Required

Contract ID

The identifier for this contract. It must be unique and must not change within the Open Contracting Process it is part of (defined by a single ocid). See the identifier guidance for further details.

awardID

[string, integer]

Required

Award ID

The award.id against which this contract is being issued.

title

[string, null]

Contract title

Contract title

description

[string, null]

Contract description

Contract description

status

[string, null]

Contract status

The current status of the contract, from the closed contractStatus codelist.

period

object

Period

The start and end date for the contract.

See Period

value

object

Value

The total value of this contract. A negative value indicates that the contract will involve payments from the supplier to the buyer (commonly used in concession contracts).

See Value

items

array[Item]

Items contracted

The goods, services, and any intangible outcomes in this contract. Note: If the items are the same as the award do not repeat.

See Item

dateSigned

[string, null]

date-time

Date signed

The date the contract was signed. In the case of multiple signatures, the date of the last signature.

documents

array[Document]

Documents

All documents and attachments related to the contract, including any notices.

See Document

implementation

object

Implementation

Information related to the implementation of the contract in accordance with the obligations laid out therein.

See Implementation

relatedProcesses

array[Related Process]

Related processes

The details of related processes: for example, if this process is followed by one or more contracting processes, represented under a separate open contracting identifier (ocid). This is commonly used to refer to subcontracts and to renewal or replacement processes for this contract.

See RelatedProcess

milestones

array[Milestone]

Contract milestones

A list of milestones associated with the finalization of this contract.

See Milestone

amendments

array[Amendment]

Amendments

A contract amendment is a formal change to, or extension of, a contract, and generally involves the publication of a new contract notice/release, or some other documents detailing the change. The rationale and a description of the changes made can be provided here.

See Amendment

amendment

object

Amendment

The use of individual amendment objects has been deprecated. From OCDS 1.1 information should be provided in the amendments array.

See Amendment

This property was deprecated in version 1.1

The single amendment object has been deprecated in favour of including amendments in an amendments (plural) array.

The following extensions are available for contracts

The following are community extensions and are not maintained by Open Contracting Partnership.

Implementation

Implementation information can be updated over the course of a contract. It belongs nested within the contract it relates to. Implementation blocks include the following elements:

Title

Description

Type

Format

Required

transactions

array[Transaction information]

Transactions

A list of the spending transactions made against this contract

See Transaction

milestones

array[Milestone]

Milestones

As milestones are completed, the milestone's status and dates should be updated.

See Milestone

documents

array[Document]

Documents

Documents and reports that are part of the implementation phase e.g. audit and evaluation reports.

See Document

The following extensions are available for implementation

The following are community extensions and are not maintained by Open Contracting Partnership.

Information on subcontracts is not currently included in the core OCDS schema, but might be handled by proposed extensions

Transaction

Title

Description

Type

Format

Required

id

[string, integer]

Required

ID

A unique identifier for this transaction. This identifier should be possible to cross-reference against the provided data source. For IATI this is the transaction reference.

source

[string, null]

uri

Data source

Used to point either to a corresponding Fiscal Data Package, IATI file, or machine or human-readable source where users can find further information on the budget line item identifiers, or project identifiers, provided here.

date

[string, null]

date-time

Date

The date of the transaction

value

object

Value

The value of the transaction.

See Value

payer

object

Payer

An organization reference for the organization from which the funds in this transaction originate.

See OrganizationReference

payee

object

Payee

An organization reference for the organization which receives the funds in this transaction.

See OrganizationReference

uri

[string, null]

uri

Linked spending information

A URI pointing directly to a machine-readable record about this spending transaction.

amount

object

Amount

(Deprecated in 1.1. Use transaction.value instead) The value of the transaction. A negative value indicates a refund or correction.

See Value

This property was deprecated in version 1.1

This field has been replaced by the `transaction.value` field for consistency with the use of value and amount elsewhere in the standard.

providerOrganization

object

Provider organization

(Deprecated in 1.1. Use transaction.payer instead.) The Organization Identifier for the organization from which the funds in this transaction originate. Expressed following the Organizational Identifier standard - consult the documentation and the codelist.

See Identifier

This property was deprecated in version 1.1

This field has been replaced by the `transaction.payer` field to resolve ambiguity arising from 'provider' being interpreted as relating to the goods or services procured rather than the flow of funds between the parties.

receiverOrganization

object

Receiver organization

(Deprecated in 1.1. Use transaction.payee instead). The Organization Identifier for the organization which receives the funds in this transaction. Expressed following the Organizational Identifier standard - consult the documentation and the codelist.

See Identifier

This property was deprecated in version 1.1

This field has been replaced by the `transaction.payee` field to resolve ambiguity arising from 'receiver' being interpreted as relating to the goods or services procured rather than the flow of funds between the parties.

The transaction block is modelled on the International Aid Transparency Initiative (IATI) transaction element, and can be used to represent actual flows of money between organizations in relation to this contract. As with the budget block, this can be used to cross-reference to a third party source of data, and ought to re-use identifiers from that source.

In most circumstances, the payer identifier will match that of the buyer, and the payee identifier will match that of the supplier.

The following extensions are available for transactions

The following are community extensions and are not maintained by Open Contracting Partnership.

Milestones

See milestone reference below.

The implementation milestones should be updated to reflect when they are met.

Documents

Documents related to contract implementation are stored here. This can include subcontracts.

See document reference below.

Amendment

A release may amend values from a previous release. Whilst the release & record model of OCDS offers the opportunity to keep a full versioned history of changes, in many cases it is important for changes to a tender, award or contract to be explicitly declared.

The amendment array in a tender, award or contract block provides the ability to detail the amendments that have taken place with dates, rationale and free-text descriptions of the change, as well as to point to the releases that contain information from before and after the amendment.

Title

Description

Type

Format

Required

date

[string, null]

date-time

Amendment date

The date of this amendment.

rationale

[string, null]

Rationale

An explanation for the amendment.

id

[string, null]

ID

An identifier for this amendment: often the amendment number

description

[string, null]

Description

A free text, or semi-structured, description of the changes made in this amendment.

amendsReleaseID

[string, null]

Amended release (identifier)

Provide the identifier (release.id) of the OCDS release (from this contracting process) that provides the values for this contracting process before the amendment was made.

releaseID

[string, null]

Amending release (identifier)

Provide the identifier (release.id) of the OCDS release (from this contracting process) that provides the values for this contracting process after the amendment was made.

changes

array[object]

Amended fields

An array of change objects describing the fields changed, and their former values. (Deprecated in 1.1)

This property was deprecated in version 1.1

A free-text or semi-structured string describing the changes made in each amendment can be provided in the amendment.description field. To provide structured information on the fields that have changed, publishers should provide releases indicating the state of the contracting process before and after the amendment.

Changes

The changes array was deprecated in OCDS 1.1. Structured information on the former value of specific fields may be provided by:

  • Including releases from before and after a change within a release package;

  • Using the amendment array in tender, contract or award to explicitly relate these releases to an amendment.

See the amendment implementation guidance for more details.

Building block reference

The following building blocks are commonly re-used throughout the standard.

OrganizationReference

Organizations

The approach to including organizations information has changed in OCDS 1.1. Instead of embedding all the details of an organization, publishers should use an organization reference to indicate the entry in the parties section that contains full details of this organization.

An organization reference consists of two main components:

  • An id used to cross-reference the entry in the parties section that contains full information on this organization or entity;

  • A name field that repeats the name given in the parties section, provided for the convenience of users viewing the data, and to support detection of mistakes in cross-referencing.

The Organization Reference schema contains deprecated fields to prevent validation failures of OCDS 1.0 data.

Organization

See the parties section

Identifier

The identifier block provides a way to identify the legal entities involved in a contracting process.

If a contracting process represents a contract arranged by the department or branch of a larger organization, the legal entity (usually the registered organization) should be described in the identifier section, with details of the branch or department given in the name, address and contact point as relevant.

Title

Description

Type

Format

Required

scheme

[string, null]

Scheme

Organization identifiers should be taken from an existing organization identifier list. The scheme field is used to indicate the list or register from which the identifier is taken. This value should be taken from the Organization Identifier Scheme codelist.

id

[string, integer, null]

ID

The identifier of the organization in the selected scheme.

legalName

[string, null]

Legal Name

The legally registered name of the organization.

uri

[string, null]

uri

URI

A URI to identify the organization, such as those provided by Open Corporates or some other relevant URI provider. This is not for listing the website of the organization: that can be done through the URL field of the Organization contact point.

Address

Title

Description

Type

Format

Required

streetAddress

[string, null]

Street address

The street address. For example, 1600 Amphitheatre Pkwy.

locality

[string, null]

Locality

The locality. For example, Mountain View.

region

[string, null]

Region

The region. For example, CA.

postalCode

[string, null]

Postal code

The postal code. For example, 94043.

countryName

[string, null]

Country name

The country name. For example, United States.

ContactPoint

Title

Description

Type

Format

Required

name

[string, null]

Name

The name of the contact person, department, or contact point, for correspondence relating to this contracting process.

email

[string, null]

Email

The e-mail address of the contact point/person.

telephone

[string, null]

Telephone

The telephone number of the contact point/person. This should include the international dialing code.

faxNumber

[string, null]

Fax number

The fax number of the contact point/person. This should include the international dialing code.

url

[string, null]

uri

URL

A web address for the contact point/person.

Document

Documents can be attached at a number of points within the standard: to planning, tenders, awards, contracts and implementation. Each document block can consist of multiple documents, classified using the documentType codelist.

Title

Description

Type

Format

Required

id

[string, integer]

Required

ID

A local, unique identifier for this document. This field is used to keep track of multiple revisions of a document through the compilation from release to record mechanism.

documentType

[string, null]

Document type

A classification of the document described, using the open documentType codelist.

title

[string, null]

Title

The document title.

description

[string, null]

Description

A short description of the document. Descriptions are recommended to not exceed 250 words. In the event the document is not accessible online, the description field can be used to describe arrangements for obtaining a copy of the document.

url

[string, null]

uri

URL

A direct link to the document or attachment. The server providing access to this document ought to be configured to correctly report the document mime type.

datePublished

[string, null]

date-time

Date published

The date on which the document was first published. This is particularly important for legally important documents such as notices of a tender.

dateModified

[string, null]

date-time

Date modified

Date that the document was last modified

format

[string, null]

Format

The format of the document, using the open IANA Media Types codelist (see the values in the 'Template' column), or using the 'offline/print' code if the described document is published offline. For example, web pages have a format of 'text/html'.

language

[string, null]

Language

The language of the linked document using either two-letter ISO639-1, or extended BCP47 language tags. The use of lowercase two-letter codes from ISO639-1 is recommended unless there is a clear user need for distinguishing the language subtype.

The following extensions are available for document

The following are community extensions and are not maintained by Open Contracting Partnership.

Period

A period has a start date, end date, and/or duration. Start and end dates are represented using date-times. Durations are represented as a number of days.

Periods can also include a maxExtentDate which indicates the latest possible end date of this period, or the latest date up until which the period could be extended without an amendment.

Title

Description

Type

Format

Required

startDate

[string, null]

date-time

Start date

The start date for the period. When known, a precise start date must be provided.

endDate

[string, null]

date-time

End date

The end date for the period. When known, a precise end date must be provided.

maxExtentDate

[string, null]

date-time

Maximum extent

The period cannot be extended beyond this date. This field can be used to express the maximum available date for extension or renewal of this period.

durationInDays

[integer, null]

Duration (days)

The maximum duration of this period in days. A user interface can collect or display this data in months or years as appropriate, and then convert it into days when storing this field. This field can be used when exact dates are not known. If a startDate and endDate are set, this field, if used, should be equal to the difference between startDate and endDate. Otherwise, if a startDate and maxExtentDate are set, this field, if used, should be equal to the difference between startDate and maxExtentDate.

Date

OCDS makes use of ISO8601 date-times, following RFC3339 §5.6.

A time and timezone/offset must be provided in a date-time.

The following are valid date-times:

  • '2014-10-21T09:30:00Z' - 9:30 am on the 21st October 2014, UTC

  • '2014-11-18T18:00:00-06:00' - 6pm on 18th November 2014 CST (Central Standard Time)

The following are not valid:

  • '2014-10-21' - Missing time portion

  • '2014-10-21T18:00' - missing seconds in time portion.

  • '2014-11-18T18:00:00' - Missing timezone/offset portion

  • '11/18/2014 18:00' - Not following the pattern at all!

Accurately including the time and timezone offsets is particular important for tender deadlines and other dates which can have legal significance, and where users of the data might be from different timezones. The character Z on the end of a date-time indicates the UTC (or Zero offset) timezone, whereas other timezones are indicated by their value '+/-hh:mm' UTC on the end of the date-time value.

In the event that the system from which data is drawn only includes dates, and does not include time information, publishers should use sensible defaults for each field. For example, the startDate time of a clarification period can be set to '00:00:00Z' to indicate that clarifications can be requested from any time on the date stated, with the endDate time set to 23:59:59Z to indicate that clarifications can be sent up until the end of the endDate given. Alternatively, if clarification requests are only accepted in standard office hours, these values might be 09:00:00Z and 17:00:00Z respectively.

In the event that a date field is not bound to a specific time at all, publishers should choose a default time value of '23:59:59' and either 'Z' (for UTC) or the timezone of the publisher, indicating that the time refers to the end of the given date.

Item

The items block is used to list the line-items associated with a tender, award or contract.

Title

Description

Type

Format

Required

id

[string, integer]

Required

ID

A local identifier to reference and merge the items by. Must be unique within a given array of items.

description

[string, null]

Description

A description of the goods, services to be provided.

classification

object

Classification

The primary classification for the item.

See Classification

additionalClassifications

array[Classification]

Additional classifications

An array of additional classifications for the item.

See Classification

quantity

[number, null]

Quantity

The number of units to be provided.

unit

object

Unit

A description of the unit in which the supplies, services or works are provided (e.g. hours, kilograms) and the unit-price.

These are extensions related to Items.

Location

Allows the point of delivery or site of works for a given line item to be indicated in tender, award and contract objects.

The following are community extensions and are not maintained by Open Contracting Partnership.

Classification

Title

Description

Type

Format

Required

scheme

[string, null]

Scheme

The scheme or codelist from which the classification code is taken. For line item classifications, this uses the open itemClassificationScheme codelist.

id

[string, integer, null]

ID

The classification code taken from the scheme.

description

[string, null]

Description

A textual description or title for the classification code.

uri

[string, null]

uri

URI

A URI to uniquely identify the classification code.

Unit

The unit block allows detailed specification of the parameters and price of units that make up a line-item.

If the Quantities, Units, Dimensions and Data Types Ontologies unit classification scheme is used, then publishers can use its CamelCase unit names, such as "SquareMile", in the unit.name field.

Other unit classification schemes can be used, including those in the unitClassificationScheme codelist.

Title

Description

Type

Format

Required

scheme

[string, null]

Scheme

The list from which identifiers for units of measure are taken, using the open unitClassificationScheme codelist. 'UNCEFACT' is recommended.

id

[string, null]

ID

The identifier from the codelist referenced in the scheme field. Check the unitClassificationScheme codelist for details of how to find and use identifiers from the scheme in use.

name

[string, null]

Name

Name of the unit.

value

object

Value

The monetary value of a single unit.

See Value

uri

[string, null]

uri

URI

The machine-readable URI for the unit of measure, provided by the scheme.

Milestone

Milestone information can be included in the planning, tender, contract and contract implementation blocks.

Title

Description

Type

Format

Required

id

[string, integer]

Required

ID

A local identifier for this milestone, unique within this block. This field is used to keep track of multiple revisions of a milestone through the compilation from release to record mechanism.

title

[string, null]

Title

Milestone title

type

[string, null]

Milestone type

The nature of the milestone, using the open milestoneType codelist.

description

[string, null]

Description

A description of the milestone.

code

[string, null]

Milestone code

Milestone codes can be used to track specific events that take place for a particular kind of contracting process. For example, a code of 'approvalLetter' can be used to allow applications to understand this milestone represents the date an approvalLetter is due or signed.

dueDate

[string, null]

date-time

Due date

The date the milestone is due.

dateMet

[string, null]

date-time

Date met

The date on which the milestone was met.

dateModified

[string, null]

date-time

Date modified

The date the milestone was last reviewed or modified and the status was altered or confirmed to still be correct.

status

[string, null]

Status

The status that was realized on the date provided in dateModified, from the closed milestoneStatus codelist.

documents

array[Document]

Documents

List of documents associated with this milestone (Deprecated in 1.1).

See Document

This property was deprecated in version 1.1

Inclusion of documents at the milestone level is now deprecated. Documentation should be attached in the tender, award, contract or implementation sections, and titles and descriptions used to highlight the related milestone. Publishers who wish to continue to provide documents at the milestone level should explicitly declare this by using the milestone documents extension.

Notes:

  • The dateModified field should be changed whenever the progress towards a milestone is reviewed, and the status either updated, or re-confirmed.

The following extensions to milestone are available

Milestone documents

Documents at the milestone level were deprecated in OCDS 1.1. This extension re-introduces the ability to attach documents to each individual milestone.

The following are community extensions and are not maintained by Open Contracting Partnership.

Value

Financial values should be published with a currency attached.

Title

Description

Type

Format

Required

amount

[number, null]

Amount

Amount as a number.

currency

[string, null]

Currency

The currency of the amount, from the closed currency codelist.

Support for exchange rates, and tax information, can be provided using extensions.

RelatedProcess

In OCDS each contracting process can have only one planning and tender stage. There are a number of cases where it is important to know about related planning and tendering processes, including:

  • When one planning process results in many tenders;

  • What a contract is awarded following two distinct, but related, tender processes, such as in national frameworks with locally run mini-competitions;

  • When a contract results in the award of sub-contracts - and those sub-contracts are also tracked using OCDS;

  • When a contract is coming up for renewal or replacement, and there is a contracting process to award the renewal/replacement contract;

In all these cases, the relatedProcess block should be used to cross-reference between the relevant open contracting processes using their ocid.

Title

Description

Type

Format

Required

id

string

Relationship ID

A local identifier for this relationship, unique within this array.

relationship

array[string]

Relationship

The type of relationship, using the open relatedProcess codelist.

title

[string, null]

Related process title

The title of the related process, where referencing an open contracting process, this field should match the tender/title field in the related process.

scheme

[string, null]

Scheme

The identification scheme used by this cross-reference, using the open relatedProcessScheme codelist.

identifier

[string, null]

Identifier

The identifier of the related process. If the scheme is 'ocid', this must be an Open Contracting ID (ocid).

uri

[string, null]

uri

Related process URI

A URI pointing to a machine-readable document, release or record package containing the identified related process.

A related process can be declared at two points in an OCDS release.

(1) At the release level - used to point backwards to prior processes, such as planning or framework establishment.

(2) At the contract level - used to point onward to sub-contracts, renewal or replacement processes that relate solely to the particular contract the field appears in.

As well as providing this machine-readable link between processes, publishers may also provide links to human-readable documentation in the relevant documents blocks. For example:

  • When recording a release/relatedProcess pointing to the ocid of the planning process that resulted in a tender, a tender/documents entry with a documentType of 'procurementPlan' and a link to web pages about the procurement plan could be provided;

  • When recording a contract/relatedProcess pointing to the ocid of a sub-contracting process, a contract/documents entry with a documentType of 'subContract' and a title that describes it as the subcontracting process, could be provided;

  • When recording a contract/relatedProcess pointing to the ocid of a tender process to renew a given contract, a contract/documents entry with a documentType of 'tenderNotice' and a title that describes it as the successor process, could be provided;

Location

The Location extension can be used to provide location information.

Publisher

The publisher block is used in release and record packages to identify the source of a dataset.

Title

Description

Type

Format

Required

publisher

object

Required

Publisher

Information to uniquely identify the publisher of this package.

publisher/name

string

Required

Name

The name of the organization or department responsible for publishing this data.

publisher/scheme

[string, null]

Scheme

The scheme that holds the unique identifiers used to identify the item being identified.

publisher/uid

[string, null]

uid

The unique ID for this entity under the given ID scheme.

publisher/uri

[string, null]

uri

URI

A URI to identify the publisher.