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.

package
- release
  - parties
  - planning
  - tender
  - award
  - contract
    - implementation

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]		Required
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]		Required
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.

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
`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

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

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
`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

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
`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

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	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.

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

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

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
`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

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 reuse 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

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
`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
`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
`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
`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

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
`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	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.

Classification¶

Title	Description	Type	Format
`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
`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.

Value¶

Financial values should be published with a currency attached.

Title	Description	Type
`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
`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.