Most infrastructure transparency portals fail before they deliver value. Not because the data standard is wrong, but because the integration pattern chosen at the start does not match what government source systems can actually provide. If you are implementing OC4IDS, the Open Contracting for Infrastructure Data Standard, in a CoST member country, this is the decision that determines whether your portal survives past its launch event.
I have worked on OC4IDS integrations across multiple CoST member countries. The pattern that works in one context breaks in another. Here is a grounded account of what those patterns look like, what drives each choice, and where each one fails.
Why the integration pattern matters more than the standard itself
OC4IDS provides a structured framework for disclosing data across the full infrastructure project cycle, from identification and preparation through procurement, implementation, and completion. CoST member countries, including Kenya and Thailand, use this standard to disclose data on public infrastructure projects through national portals and assurance processes.
The standard itself is stable. The problem is always the source. Infrastructure projects span years. They generate variation orders, environmental assessments, physical progress updates, and financial disbursements, each produced by a different system, team, or process. When your integration architecture assumes data that the source system does not produce in a usable form, the portal starves.
Pattern one: manual disclosure against the CoST IDS fields
The simplest pattern requires officials to manually enter project data against OC4IDS fields through a web interface. CoST member countries frequently start here because it requires no system integration. You define the fields, build the form, and ask procurement or project officers to populate it.
The failure mode is predictable. Officers complete the initial data load for a launch event. The portal impresses decision-makers at the opening. Then routine operations resume and nobody updates it. Infrastructure disclosure requires constant updating, when a contractor pours concrete, when a variation order is approved, when a contract payment is released. Manual entry doubles the workload of officers who already maintain internal management systems. The portal dies of starvation.
Use this pattern only where a time-limited, supervised disclosure exercise is the goal, such as a CoST assurance cycle applied to a defined project sample, and where a dedicated data entry function is resourced explicitly for that purpose.
Pattern two: structured extraction from procurement systems
Where a government operates a functional e-procurement system, structured extraction is the most reliable integration pattern. The procurement system already holds contract award data, tender information, and supplier records. You map those fields to OC4IDS and build an extraction pipeline that runs on a defined schedule.
CoST Kenya's implementation experience illustrates the opportunity and the limit of this pattern. Kenya operates as a CoST founding member and discloses infrastructure project data through its national affiliate. Procurement system data covers the contracting process well. It covers implementation poorly. Variation orders, physical progress, and environmental compliance data rarely live in the same system as the original contract award. Your pipeline extracts clean contracting data and then hits a wall at the implementation stage.
The counterargument to building beyond this point deserves honest consideration. Some practitioners argue that disclosing procurement-stage data alone, tender documents, contract awards, contractor identity, contract value, already represents a substantial transparency gain in contexts where none of that was previously public. They are right. The CoST IDS covers both contracting and project-level data, but a partial disclosure that is sustained is more valuable than a complete disclosure framework that collapses under its own integration complexity.
That argument is valid as a starting point. It becomes dangerous when it is used to avoid ever building toward implementation-stage disclosure, which is where infrastructure projects actually fail.
Pattern three: the CoST Independent Review as a structured data source
CoST's Independent Review mechanism, in which technically qualified reviewers assess disclosed project data and produce findings, is underused as an integration anchor. The review process generates structured assessments of infrastructure projects against CoST IDS fields. Those assessments are themselves data.
In member countries where the Independent Review is embedded in the programme cycle, the review outputs can be mapped directly to OC4IDS project records, providing a verified implementation-stage layer that no automated pipeline produces. Thailand's CoST participation, focused on enhancing transparency in public infrastructure through structured disclosure and assurance, demonstrates how the assurance process creates a data layer that sits above raw system outputs.
This pattern requires investment in the assurance function itself, not just the portal. But it produces disclosed data that has been reviewed for completeness and accuracy, a quality standard that automated extraction alone cannot guarantee.
Choosing before the architecture is locked
Before writing a single line of integration code, answer three questions about your source systems:
- What data does the source system actually produce today, not what it is supposed to produce, but what is consistently entered and maintained?
- Who owns the update obligation for implementation-stage data, physical progress, variation orders, environmental assessments, and what system do they already use?
- Is the CoST Independent Review mechanism resourced to generate structured assurance outputs that can be mapped to OC4IDS project records?
Your integration pattern follows from those answers, not from what the standard makes possible in theory.
The specific next step
If you are scoping an OC4IDS integration for a CoST member country right now, conduct a source system audit before the technical specification is written. Map each OC4IDS field category, project details, documents, contracting process, implementation, to the government system that currently holds that data. Where no system holds it, decide explicitly whether manual disclosure with dedicated resourcing, an Independent Review process, or a phased build is the right response. Do not let that gap be discovered after the architecture is locked.
Found this useful?
I write about open data systems, transparency, and implementation.
Read more articles →