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
partiesarray 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
documentsblocks, 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.