After processing 100,000 procurement contracts in Uganda, I learned a harsh truth: disclosure is not transparency. Governments routinely dump thousands of scanned documents onto web portals and declare victory. But publishing a signed document tells citizens nothing about whether a hospital gets built on time or on budget. True transparency requires structuring data so that every procurement award connects directly to physical infrastructure delivery. To achieve this, governments must adopt the Open Contracting for Infrastructure Data Standard (OC4IDS) as their primary framework, using procurement data only as a foundational layer. Here are the three patterns the Uganda dataset revealed and exactly what I build differently today.

1. Procurement Data Stops at the Signature

In our dataset of 100,000 contracts from Uganda, we observed a massive blind spot. The data captured the bidding process and the final award perfectly. Citizens knew exactly which company won a tender and the exact contract value. But the data stopped at the signature. When a contractor abandoned a site six months later, the procurement portal still showed the project as a success.

100,000

procurement contracts processed from Uganda, the dataset that revealed three systemic failures in how governments measure infrastructure delivery.

Definition

OC4IDS

a framework that tracks public works projects across their entire lifecycle, from identification to completion

This failure happens because governments rely entirely on the Open Contracting Data Standard (OCDS) (a data model that tracks the purchasing process from planning to contract award). OCDS serves an important function, but it only provides the procurement data layer. It answers who won the bid. Infrastructure projects require a different lens to answer what actually gets built. As stewards of transparency at CoST (the Infrastructure Transparency Initiative), we use OC4IDS (a framework that tracks public works projects across their entire lifecycle, from identification to completion).

Definition

variation orders

formal approvals to change the scope or cost of a project

OC4IDS connects the initial contract to site visits, variation orders (formal approvals to change the scope or cost of a project), and final completion certificates. Infrastructure delivery involves site preparation, material testing, and structural delays. Without OC4IDS, you only track promises. With OC4IDS, you track physical reality.

2. Document Dumping Hides the Truth

Definition

identify beneficial ownership

the real individuals who ultimately control a company

Our review of the Ugandan contracts revealed that most disclosures existed as scanned PDFs. A scanned document acts as a dead end for accountability. Civil society organizations cannot aggregate data across 100,000 scanned pages to find patterns of corruption. Journalists cannot filter image files to identify beneficial ownership (the real individuals who ultimately control a company). When agencies publish unstructured data, they shift the burden of analysis onto the public.

Crucial details like unit costs, material specifications, and penalty clauses remain trapped in these static files. We must build systems that publish machine-readable data by default. Every contract must exist as a structured record in a database, not a picture of a piece of paper. This structured approach allows automated systems to flag cost overruns instantly.

In our dataset, extracting basic project milestones from PDFs required thousands of hours of manual review. Structured data eliminates this friction entirely. When data lives in the OC4IDS schema, watchdogs write simple queries to find every project running past its deadline. Document dumping creates the illusion of transparency while maintaining absolute opacity.

3. Manual Data Entry Destroys Portals

Every manual-entry portal we observed eventually failed. When transparency portals require government staff to log in and type project updates manually, compliance drops to zero. Staff view this data entry as extra work outside their core duties. They face forgotten passwords, staff turnover, and broken links. In our experience processing the Ugandan contracts, the only reliable data came from automated system integrations.

0

manual-entry portals we observed sustained consistent data quality across project cycles. Every one eventually failed once project funding ended.

We must connect transparency portals directly to the government's IFMIS (Integrated Financial Management Information System, the central software used to process state payments). When a contractor receives a payment in the financial system, the transparency portal must update automatically. Bypassing manual entry sustains compliance.

We also integrate directly with electronic procurement systems. By pulling data automatically from the tools government officials already use daily, we guarantee the transparency portal reflects the actual state of government operations. Human beings should analyze data, not copy and paste it between systems.

Counterargument

The Counterargument: Low Capacity Demands Simplicity

Critics correctly note that low-capacity agencies lack the staff and technical infrastructure to implement complex data standards. These critics argue that demanding full OC4IDS compliance sets developing nations up for failure. They insist that simple, disconnected spreadsheets offer a more realistic starting point for transparency in resource-constrained environments.

This objection ignores the long-term cost of bad data. Simple spreadsheets create permanent data silos. When agencies use disconnected spreadsheets, they spend hundreds of hours manually reconciling conflicting numbers during audits. A procurement officer’s spreadsheet never matches the finance officer’s spreadsheet.

Implementing OC4IDS requires higher upfront technical effort, but it establishes a single source of truth. By structuring the data correctly from day one, agencies eliminate the endless manual reconciliation that drains their limited capacity. The initial technical hurdle prevents systemic failure later. We solve the capacity problem by automating data flows, not by dumbing down the data structure.

What I Build Differently Today

When I build transparency initiatives today, I ban standalone procurement portals. Procurement data possesses zero value without implementation data. I build systems that center the physical infrastructure asset. The architecture uses OC4IDS as the core schema from day one.

The system pulls the contract award data from the OCDS layer. It pulls payment data from the financial system. It pulls physical progress data from engineering reports. This architecture creates a single, unbroken narrative for every school, road, and water plant. We prioritize automated data extraction over manual portal uploads.

We design for the data consumer, ensuring that every field maps to a specific oversight function. Auditors need unit costs. Citizens need completion dates. If a data field does not help a citizen, journalist, or auditor track the physical delivery of an asset, we discard it.

What to Do Next

Stop funding standalone procurement portals that end at the contract signature. This week, audit your current transparency infrastructure to determine if you track promises or reality. First, identify where your procurement data lives and where your project implementation data lives. If these two datasets exist in separate systems, you have a disclosure platform, not a transparency tool.

Second, map your existing data fields against the OC4IDS schema. Identify the exact gaps between your current procurement disclosures and the physical reality of your infrastructure projects. Finally, draft a technical brief requiring all future portal upgrades to integrate the procurement data layer directly into an OC4IDS-compliant infrastructure tracking system. Prioritize automated integration with your financial systems over building new manual upload interfaces.

Playbook

Decision Table
OptionWhen to UseTradeoff
Adopt immediately Low-risk process and clear team ownership Fast progress, limited validation runway
Pilot first Uncertain data quality or mixed institutional capacity Slower scale-up, higher confidence
Defer pending controls Missing governance, QA, or monitoring guardrails Lower short-term output, better long-term durability
Execution Checklist
Failure Modes
  • Skipping the section "1. Procurement Data Stops at the Signature" during implementation.
  • Skipping the section "2. Document Dumping Hides the Truth" during implementation.
  • Skipping the section "3. Manual Data Entry Destroys Portals" during implementation.

Continue Reading

Why Disclosure Portals Die (And How to Build Ones That Don't)

Every infrastructure disclosure portal I have worked with that launched to a press release went dark within three years. The failures follow predictable patterns. Here is what the survivors have in common.

The OC4IDS Implementation Checklist Nobody Gives You

The documentation explains the schema. It doesn't tell you which decisions haunt you eighteen months in. After five implementations across three countries, here's the checklist I wish I'd had.

Five Integration Patterns for OC4IDS Portals (and Their Failure Modes)

Five integration patterns for OC4IDS portals. Three of the ones I've worked on failed, not because the data standards were wrong, but because the pattern didn't match what the source system could deliver. This is how to choose before the architecture is locked.

Found this useful?

I write about open data systems, transparency, and implementation.

Read more articles →