Infrastructure transparency · Five implementations, three countries
The portal fails before it launches.
A portal does not fail because the website breaks. It fails when ministries create records that cannot be linked, and when nobody is bound to keep feeding it. Two decisions, made before the first record exists, that you can never take back.
The portal fails before it launches.
Not because the website breaks. Because the records inside it were born apart, and nobody can link them back together.
Three records. Three different keys.
Each ministry opened its own record under its own key. The portal must join them into one story. Tap to watch it try.
One shared key. Now they link.
Agree one key before any record exists, and the same three records join into one story. That is the whole difference.
Two of these you can never undo.
Both have to be agreed before the first record is created. Miss them and there is nothing to fix later.
These you can still fix. At a cost.
Tap each one to see what it costs to fix at month 18.
Code can be changed. Records born under different keys cannot.
Agree the shared key and the politics before the first record exists. Everything else you can still fix later.
One road. Three ministries. Watch the portal try to link them.
A real project on a real portal. Finance opened a record. So did procurement. So did works, each under its own key. This is what the portal must do every day: join them into one story. Watch what happens.
Some mistakes are expensive. Two are permanent.
The two that fixed the link above are the two you can never take back. Every decision below has the same test: skip it, then try to fix it at month 18, and see what happens.
Cannot be undone
These are the two that made the link work. They must happen before the first record exists.
Recoverable, at a cost
Skip these and you bleed time and compliance, but you can still repair them.
The standard tells you what a good portal should publish. It does not decide whether three ministries will use the same key, whether the data keeps flowing, or whether anyone checks it. Those are agreements, not settings, and two of them have to be made before a single record is created.
Methodology and data
Five institutional decisions drawn from five infrastructure disclosure portal implementations across three countries, sorted by reversibility: whether a skipped decision can still be fixed once records exist. Two are permanent, a shared project identifier and the agreements behind it, because records are created under whatever key is agreed at that moment. Three are recoverable at a cost. The standard referenced is OC4IDS, which sits on the OCDS procurement layer; the independent check is the CoST Independent Review; the data is pulled from finance (IFMIS) and e-procurement systems. The eighteen-month figure is the observed pattern for when these decisions resurface, not a fixed deadline.
| decision_before_launch | reversibility | mechanism | if_done | if_skipped | confidence |
|---|---|---|---|---|---|
| Agree one shared project ID across every ministry, before any record is created | Permanent (cannot be fixed later) | Finance, procurement, and the works ministry each open a record the moment they touch the project. If they have not agreed a shared key by then, every record is born under a different one. The link that ties a project together runs on that key, so it has to exist before the records do. You cannot add it afterwards, because the records already exist without it. | Finance, procurement, and works all point at the same project. The records link into one story. | Three datasets that cannot talk to each other. The link was never possible, because the records were already created apart. | Observed across 5 implementations in 3 countries (as reported) |
| Make the data-sharing agreement binding before the build, not after | Permanent (cannot be fixed later) | A shared key and a duty to keep feeding the portal are not settings; they are agreements between ministries that guard their own systems. Those agreements are cheap before anyone has built anything and almost impossible once each ministry has shipped around the gap. Skip them at the start and you are not adding a feature later, you are asking institutions to rebuild what they already run. | The shared key and the feed duty held, because the agreements were made while they were still cheap to make. | The build was fine. The agreement was never secured, so the portal stalled with nobody bound to feed it. | Observed across 5 implementations in 3 countries (as reported) |
| Connect the procurement (tender) data feed before you build the portal | Recoverable, at a cost | The portal describes a project across planning, procurement, and delivery, but the procurement facts come from the contracting system underneath it. Build the portal without that feed connected and you have a display with nothing to show, so people backfill tender data by hand, which no team sustains. You can connect the feed later, but you lose every month spent typing. | The feed was solid, so the team tracked real progress on site instead of retyping tenders. | Months spent hand-entering tender data into an empty shell. The portal never reached the delivery stage that was the point. | Observed across 5 implementations in 3 countries (as reported) |
| Pull the data automatically from day one, instead of relying on manual uploads | Recoverable, at a cost | If publishing depends on a person remembering to log in and upload, it competes with that person's real job and loses. Pull from the finance and procurement systems instead, and disclosure becomes a byproduct of work already happening. You can automate after a manual start, but every month of manual entry is a month of compliance quietly falling toward zero. | Data flowed from the systems officers already use. Nobody had to remember, so the portal stayed current. | Officers were asked to log in and upload. Compliance collapsed inside the first year. | Observed across 5 implementations in 3 countries (as reported) |
| Put the independent check beside the published claim, not outside the portal | Recoverable, at a cost | Published numbers are claims until something checks them. An independent review compares what was promised against what was delivered; wire it into the data and its findings sit beside the claim as evidence. Leave it outside and the portal looks full but proves nothing. You can add the check later, but the unchecked period is already public. | Gaps between promised and delivered surfaced as records, not rumours. The check answered anyone who said publishing was enough. | Raw figures, unchecked. The portal looked full and meant little. | Observed across 5 implementations in 3 countries (as reported) |
Code can be changed. Records already born under different keys cannot.
Agree the shared key and the politics before the first record exists. Everything else you can still fix later. Those two, you cannot.