CoST IDS & OCDS Mapping

CoST – the Infrastructure Transparency Initiative (CoST) is the leading global initiative improving transparency and accountability in public infrastructure.

The CoST approach is based on four core features:

  • Disclosure - where procuring entities are asked to follow the CoST Infrastructure Data Standard. This describes 40 items of data that should be disclosed at key stages of an infrastructure project cycle.
  • Assurance - an independent review of the disclosed data by assurance teams based within CoST national programmes. Teams may identify key issues of concern from the data that has been disclosed, and will put technical terms into plain language to allow stakeholders to understand the issues, and hold decision makers to account.
  • Multi-stakeholder working - each CoST national programme is managed by a stakeholder group including government, private sector and civil society.
  • Social accountability - raising awareness of key issues arising from the assurance process, and engaging civil society and media to hold decision makers to account.

The ‘Infrastructure Data Standard’ is a framework for disclosure which has been adapted by a range of CoST national programmes, who have variously prioritised different elements based on their local needs, or who have included additional elements that they wish to monitor: particularly additional kinds of documentation that should be provided for each infrastructure project.

You can read more about the Infrastructure Data Standard in CoST Guidance Note 6.

Frameworks and standards

There is an important distinction between the Infrastructure Data Standard (IDS) and the Open Contracting Data Standard (OCDS). IDS provides a framework to identify categories of information that should be disclosed. OCDS describes specific fields and how they should be structured as data.

The Open Contracting for Infrastructure Data Standard (OC4IDS) documented on this site acts as a bridge between the IDS framework, and the idea of a more structured technical data standard.

Mapping to IDS and from OCDS

The following mapping tables describe:

  • How each element of the CoST Infrastructure Data Standard can be represented as structured data using the Open Contracting for Infrastructure Data Standard, in the ‘Mapping to OC4IDS’ column.
  • How existing OCDS data can be used to populate project-level and contracting process summary data, in the ‘Mapping from OCDS’ column.

Mapping from OCDS

Some mappings use fields from OCDS extensions. In these cases, the names of extensions are noted in parentheses; where possible, alternative mappings are provided that use only fields from the core OCDS schema.

Project level

Project identification

CoST IDS element CoST IDS draft definition Mapping to OC for Infrastructure Mapping from OCDS
Project owner Name of the sponsoring Government department Project Level: Add an entry to parties with ‘owner’ included in its .roles OCDS: Check for parties with ‘buyer’ or ‘publicAuthority’ in .roles and infer from .name
Sector Develop a list of sectors relevant to country e.g. housing, transport, energy, water etc. Project Level: Publish in sector, with any additional sectors in additionalClassifications OCDS: Map from planning.project.sector (Budget and projects extension, PPP profile)
Subsector Develop a subset for each sector e.g. Transport could be subdivided into national highway, local road, railway, port, airport etc. Project Level: Publish in additionalClassifications OCDS: Copy from planning.project.additionalClassifications (Budget and projects extension, PPP profile)
Project name Specify the project name Project Level: Publish in title OCDS: Copy from planning.project.title (Budget and projects extension, PPP profile); if not available, infer from tender.title
Project Location Briefly specify location of the project Project Level: Publish using the locations fields as an address, geometry (point/line/polygon) or gazetteer entry OCDS: Copy from planning.project.locations (Budget and projects extension, PPP profile); if not available, infer from tender.items.deliveryLocation or tender.items.deliveryAddress (Location extension)
Purpose Specify the socio economic purpose of the project Project Level: Publish in purpose; if classified against a codelist, also publish in additionalClassifications. OCDS: Infer from planning.rationale and check planning.documents for documents with .type set to ‘needsAssessment’
Project description Concise description and details of the project Project Level: Publish in description OCDS: Copy from planning.project.description (Budgets and projects extension, PPP proflie); if not available, infer from tender.description

Project preparation

CoST IDS element CoST IDS draft definition Mapping to OC for Infrastructure Mapping from OCDS
Project Scope (main output) Main outputs from the project that are being taken forward into construction (type, quantity, unit) Project Level: Publish in documents, with .type set to ‘projectScope’ and include a short description and/or a link to a document providing details OCDS: Check planning.documents for documents with .type set to projectScope or infer from tender.items or tender.milestones
Environmental impact Briefly describe the environmental impacts and mitigation measures for this project e.g. impacts on flora, fauna & woodlands, areas of natural beauty, carbon emissions etc. and mitigation measures e.g. pollution control, low carbon solutions, sustainable timber etc. Project Level: Publish in documents, with .type set to ‘environmentalImpact’ and include a short description and/or a link to a document providing details. OCDS: Check planning.documents for documents with .type set to ‘environmentalImpact’
Land and settlement impact State the amount of land and property that was acquired for the project e.g. 25km2 land, and related impacts e.g. archaeological issues (moved saxon burial site), local/indigenous settlements (relocated 5 indigenous villages of 500 villagers each), impacts on local businesses e.g. (30 business properties purchased). Project Level: Publish in documents, with .type set to ‘landAndSettlementImpact’ and include a short description and/or a link to a document providing details. OCDS: Check planning.documents for documents with .type set to ‘landAndSettlementImpact`
Contact details Postal and electronic address of the Project Owner Project Level: Publish in the .address and .contactPoint of the party with ‘publicAuthority’ included in its .roles OCDS: Check for a party with ‘buyer’ or ‘publicAuthority’ in .roles and infer from .address and .contactPoint
Funding sources Name the funding organisation(s)/sources of funding Project Level: If a funding organization is the project owner, add ‘funder’ to the .roles of the existing entry in parties. Otherwise, add a new entry to parties for each funding organization with ‘funder’ included in its .roles. When information on the amount provided by each funder is available, use budget/budgetBreakdown to provide details OCDS: Infer from planning.budgetBreakdown.sourceParty (Budget breakdown extension); if not available, check for parties with ‘funder’ in .roles and infer from .name
Project Budget Specify the projected costs/allocated budget for the project (currency and amount). The budget includes land / property acquisition, environmental mitigation measures, H&S provisions, client, consultant & contractor costs, VAT etc. Project Level: Publish in budget/amount OCDS: Infer from budget/amount
Project budget approval date Date project budget was authorised Project Level: Publish in budget/approvalDate and include additional document with .type of ‘budgetApproval’ if required OCDS: Check planning.documents for a document with .type set to ‘budgetApproval’ or check planning.milestones for a milestone with .type set to ‘approval’ and infer from .dateMet

Project completion

CoST IDS element CoST IDS draft definition Mapping to OC for Infrastructure Mapping from OCDS
Project status (current) The current stage of the project. Select from identification, preparation, construction, completion, completed or cancelled. Project Level: Publish in status OCDS: Infer from tag of most recent release
Project completion cost State projected or actual completion cost (currency and amount) Project Level: Publish in completion/finalValue OCDS: Infer projected cost from contracts.value and infer actual cost from contracts.implementation.finalValue (Contract completion extension); if not available, infer from total of contracts.implementation.transactions.value
Completion date State projected or actual completion date Project Level: Publish in completion/endDate OCDS: Infer from contracts.implementation.endDate (Contract completion extension); if not available, infer from contracts.period.endDate
Project Scope at completion (projected) Indicate projected or actual scope of project. Aim is to show if the completed project scope differs from the original project scope. Specify main outputs (type, quantity, unit) Project Level: Publish free text as completion/finalScopeDetails and/or include document with .type of projectScope and dates and descriptions that show this is final scope at completion OCDS: Check planning.documents for documents with .type set to projectScope or infer from contracts.items or contracts.implementation.milestones
Reasons for project changes Summary of primary reasons for any changes in scope, time and cost Project Level: Publish using completion/endDateDetails, completion/finalValueDetails and completion/finalScopeDetails OCDS: Infer from contracts.implementation.endDateDetails and contracts.implementation.finalValueDetails (Contract completion extension); if not available, infer from contracts.amendments
Reference to audit and evaluation reports Reference to publicly available technical and financial audits Project Level: Publish in documents, with .type set to ‘finalAudit’ and include a short description and/or a link to a document providing details OCDS: Check contracts.implementation.documents for documents with .type set to ‘finalAudit’

Process level

Procurement

CoST IDS element CoST IDS draft definition Mapping to OC for Infrastructure Mapping from OCDS
Procuring entity Enter name of the organisation carrying out the procurement Project Level: Add an entry to parties with ‘procuringEntity’ included in its .roles | Contracting process: Record the name and identifier in .summary.tender.procuringEntity OCDS: Copy from tender.procuringEntity.name and tender.procuringEntity.id
Procuring entity contact details Postal and Electronic address Project Level: Publish the postal address in parties.address and the electronic address in parties.contactPoint OCDS: Check for a party with ‘procuringEntity’ in .roles and copy from .address and .contactPoint
Contract administrative entity Enter name of the organisation carrying out the contract administrative entity if different from the Procuring Entity Project Level: Add an entry to parties with ‘administativeEntity’ included in its .roles | Contracting process: Record the name and identifier in .summary.tender.administrativeEntity OCDS: Check for a party with ‘administrativeEntity’ in .roles and copy from .name and .identifier
Contract status Select from pre-award, active or closed Contracting process: Publish in .summary.status using the contractingProcessStatus codelist OCDS: Map following the business logic in the contractingProcessStatus codelist
Procurement process Develop a list such as International Competitive Bidding, National Competitive Bidding, Donor Procurement Rules, Framework, Direct Award Contracting process: Publish in .summary.tender.procurementMethodDetails and map to .summary.tender.procurementMethod OCDS: Copy from tender.procurementMethod; if the OCDS data uses the list developed for infrastructure monitoring, copy from tender.procurementMethodDetails; otherwise, map from tender.procurementMethodDetails to this list where possible
Contract type Develop a list such as Design, Supervision, Design & Supervision, Design & Build, Construction Contracting process: Add one or more values to the .summary.nature array. (e.g. [“design”, “build”] for a design and build contract) OCDS: Map from tender.items.classification or tender.items.additionalClassifications or infer from tender.description
Number of firms tendering Number of firms who submit a tender Contracting process: Publish in .summary.tender.numberOfTenderers OCDS: Copy from tender.numberOfTenderers
Cost estimate Currency and amount of the original pre-tender estimate of the contract Contracting process: Publish in .summary.tender.costEstimate OCDS: Copy from tender.value of the last release in which tender.status is ‘planning’
Contract title The formal name of the contract Contracting process: Publish in .summary.title OCDS: Copy from contracts.title, awards.title or tender.title; for contracting processes with multiple awards or contracts, copy from tender.title
Contract firm(s) Legal name of supplier Project Level: Add an entries to parties with ‘supplier’ included in their .roles | Contracting process: Add the names and identifiers to the .summary.suppliers array OCDS: Check for parties with ‘supplier’ in .roles and copy from .name and .identifier, or copy from awards.suppliers
Contract price Currency and price at contract award Contracting process: Publish in .summary.contractValue OCDS: Copy from awards.value; for contracting processes with multiple awards, use the sum of awards.value
Contract scope of work Main outputs from the contract e.g. detailed design, supervision, project management and or type, quantity, unit for construction Contracting process: Publish in .summary.description. Additionally detailed documentation may be provided as documents within linked releases OCDS: Copy from contracts.description, contracts.items.description` or contracts.implementation.milestones; if not available, copy from awards.description, awards.items.description, tender.description or tender.items.description; for contracting processes with multiple contracts or awards, copy from tender.description or tender.items.description.
Contract start date and contract period (duration) Enter dates and Number of weeks from contract start date to (anticipated) completion date Contracting process: Publish in .summary.contractPeriod OCDS: Copy from awards.contractPeriod; if not available, copy from tender.contractPeriod; for contracting processes with multiple awards, set .startDate to the earliest of awards.contractPeriod.startDate and .endDate to the latest of awards.contractPeriod.endDate.

Implementation

Disclosures in the implementation section of the CoST IDS relate to changes to a contract’s value, duration or scope that were made after the contract was awarded.

If OCDS data is available, these changes can be determined by comparing the most recent OCDS release to a compiled release created from all prior releases (to better understand these concepts, refer to the OCDS documentation). The specific fields to monitor for changes between releases are described in the mapping table below.

In some cases, OCDS data may include an explanation of changes in the relevant amendments block. In other cases, the reason may need to be manually entered.

CoST IDS element CoST IDS draft definition Mapping to OC for Infrastructure Mapping from OCDS
Variation to contract price Difference between the price at contract award and the current projected price Contracting process: For each variation, publish an entry with a .date and .description in .summary.modifications with .type of ‘value’. Provide the contract value before the variation in .oldContractValue and the contract value after the variation in .newContractValue OCDS: Monitor contracts.value for changes. Copy contracts.amendments.description to .description and release.date to .date
Escalation of contract price Escalation to date of the price of materials, labour, equipment etc. due to fluctuations in inflation, currency etc. Contracting process: For each escalation, publish an entry with a .date and .description in .summary.modifications with .type of ‘value’. Provide the contract value before the escalation in .oldContractValue and the contract value after the escalation in .newContractValue OCDS: Monitor contracts.value for changes. Copy contracts.amendments.description to .description and release.date to .date
Variation to contract duration Difference between original duration at contract award and the current projected duration in weeks. Contracting process: For each variation, publish an entry with a .date and .description in .summary.modifications with .type of ‘duration’. Provide the contract period before the variation in .oldContractPeriod and the contract period after the variation in .newContractPeriod OCDS: Monitor contracts.period for changes. Copy contracts.amendments.description to .description and release.date to .date
Variation to contract scope Any changes between original scope at contract award and the current scope Contracting process: For each variation, publish an entry with a .date and .description in .summary.modifications with .type of ‘scope’ OCDS: Monitor contracts.description, contracts.items and contracts.implementation.milestones for changes. Copy contracts.amendments.description to .description and release.date to .date
Reasons for price changes Summary of reasons for primary changes (e.g. variations) that then lead to changes in contract price, major price fluctuations and accumulative increase or decrease in price. Contracting process: For each variation, provide a .rationale in .summary.modifications. OCDS: Copy contracts.amendments.rationale to .rationale
Reasons for scope and duration changes Summary of reasons for primary changes (e.g. variations) that then lead to changes in the scope and duration. Contracting process: For each variation, provide a .rationale in .summary.modifications. OCDS: Copy contracts.amendments.rationale to .rationale

Reactive disclosures

The CoST IDS also sets out a number of data points under the heading of ‘reactive disclosure’. It is possible to also disclose many of these fields pro-actively either as document entries with free text or linked documents, or using structured OCDS fields and extensions.

Specifically:

  • Details of a individuals involved at the project or contract level can be included in the parties array with a suitable role. Role is an open codelist. As individuals will not have an ‘organization identifier’ a locally defined identifier may be used instead.
  • Plans, reports and assessments may be included in the project or contracting process level documents blocks, or may be published within individual OCDS releases.
  • The budget_breakdown and budget_and_spend extensions can be used to provide guidance on modelling detailed financial information.