Why public disclosure portals stop updating

A portal that is online and gone

Uganda's PPP disclosure platform still has a URL. Its project pages carried a "last update" date of 25 October 2021, and the Internet Archive's last successful capture of the site is from 23 February 2024. As of September 2026 the domain does not answer.

Nothing about that is dramatic. There was no shutdown notice, no final report. The pages simply stopped changing, then stopped resolving. A portal that once held the concession terms for the Kampala-Jinja Expressway now exists mainly as an archive snapshot. Online did not mean alive, and going offline was the last step of a decline that had already happened years earlier.

That pattern is documented more than once:

• Uganda PPP disclosure platform: archived captures from May 2020 to February 2024, content frozen from October 2021, unreachable in September 2026.
• CoST Uganda's open-data portal (infra-data.cost.or.ug): archived from April 2020 to October 2023; the domain no longer resolves.
• Tanzania's national open data portal (opendata.go.tz): archived from October 2014 to June 2020; the domain no longer resolves.
• Nigeria's open data portal (data.gov.ng): archived to May 2021; unreachable in September 2026.
• The United States' Recovery.gov: launched with the 2009 recovery act, last archived in January 2016, retired when its oversight board wound up.

And the pattern has counter-cases, which matter more than the failures. Uganda's Government Procurement Portal has been continuously archived since 2019 and was relaunched in June 2026. CoST Malawi's Information Platform for Public Infrastructure has been live since 2017 and was rebuilt on OC4IDS in 2022. Portals can survive. The question is what makes the difference.

What a dying portal actually looks like

I have worked on disclosure portals in Africa and South Asia. The failure rarely announces itself. The homepage keeps its clean cards, a contract value, a progress bar. What changes is underneath: the field that was never populated, the project page that stopped updating when a grant line closed, the number that no one has checked against the site.

Manual data entry is one real failure mode, and a common one: when officials must log in and upload spreadsheets by hand, the portal is only as fresh as the busiest person's spare time. But it is not the only failure mode, and treating it as the whole story is a mistake. I am not going to claim that automated portals never die, or that any portal's compliance ever reached zero. What the cases above support is narrower and more useful: portals that launch as visibility projects, rather than as byproducts of an existing workflow, tend not to outlast their launch funding.

Get the standard right: OCDS and OC4IDS

One claim that used to be made about this problem is simply wrong, and it is worth correcting because it misdiagnoses the difficulty.

OCDS, the Open Contracting Data Standard, does not stop at contract award. Its release reference has a first-class Implementation block, nested under the contract, carrying transactions (the spending made against the contract), milestones (their status and dates as they are met) and documents (audit and evaluation reports and the like). The contracting lifecycle it describes runs planning, tender, award, contract, implementation.

OC4IDS, the Open Contracting for Infrastructure Data Standard, sits at a different level. It is the project-level frame: identification, preparation, implementation, completion, maintenance and decommissioning. Where detailed contracting data is published in OCDS, OC4IDS can link to those releases, so one project can point to the contracting processes it contains.

So the ceiling is not in the standards. Both can carry the post-award record the public needs. When disclosure stops at award in practice, that is a publishing and workflow failure, not a schema limitation. That distinction matters, because it moves the diagnosis from "the standard cannot hold this" to "our systems do not feed it".

What actually sustains a useful portal

Five things have to hold, and each one interacts with automation rather than being solved by it.

Access and permissions. Automation begins with the right to read a source system. That is a governance decision, not a technical one. An e-procurement or financial system has an owner, an access policy and a data-sharing agreement, and none of that is settled by writing a connector. Where permissions never arrive, the portal falls back to manual uploads, and freshness becomes a matter of individual diligence.

Funding as architecture, not a project. A pipeline has recurring costs: hosting, monitoring, a person who fixes it when a source changes shape. Grant funding has an end date, and the end date is often the moment the pipeline quietly stops. Recurrent budget with a named owner is the difference between a system and an event.

Maintenance and change. Source systems change their fields, add a status, retire a code. A pipeline that is not maintained does not fail loudly; it starts dropping fields, and the portal fills with blanks that look like absence rather than breakage. Someone has to own that, permanently.

Institutional demand. Data is fixed when someone needs it. If no auditor, journalist, oversight body or citizen uses the record to ask a question, nothing creates the pressure to correct it. A portal no one reads has no reason to stay accurate.

A real task. The portal has to let a practitioner finish something: check a variation, compare a bid, follow a project to its site. A carousel of PDFs and a press-release archive is impressive at launch and useless on a Tuesday, and no one returns because no one had a task.

Automation helps with the first of these and depends on the other four. It removes the manual upload, but only once permissions exist, only while the pipeline is funded and maintained, and only if anyone is asking.

Diagnostic questions, not a survival score

I once drafted a checklist that claimed to predict whether a portal would survive. That was overreach. A score built from unvalidated weights is not evidence, and a checklist that predicts survival without measured outcomes is a modelling device dressed as a forecast. What I can offer instead is the set of questions I would now ask before and during a build. Weak answers are the warning, not a number.

1. Where does each required field come from, and who must grant access to that source? A weak answer names a system but not the person who can approve the connection.
2. Is the pipeline funded from a recurrent budget, with a named owner? A weak answer points to a grant with an end date and no successor line.
3. Who checks published claims against the documents and the ground, and how often? A weak answer is an occasional report, arriving too late to challenge a live claim.
4. Which real task can a practitioner finish here? A weak answer lists features, not tasks that someone completed.
5. When a source field changes, what updates the portal, and how fast? A weak answer is "someone uploads the spreadsheet".
6. When a field is missing, who is told, and by when? A weak answer is no one, and no date.

Answer these honestly and the diagnosis is usually visible before the launch.

The verdict

The portal is not the product. The pipeline is the product. Transparency cannot be an extra task bolted onto busy people; it has to be a byproduct of the work itself. The documents above show that the difference between a portal that lives and one that quietly goes dark is not the quality of the launch page. It is whether the thing behind the page is funded, owned, permitted to read its sources, and used.

Evidence note

I have listed the exact archive and reachability evidence for each case above so a reader can re-check it. The specific day a portal goes offline is generally not recorded anywhere; the defensible facts are the last successful archive capture and whether the domain answers today. My own account of working on portals in Africa and South Asia is a first-person observation and is scoped to that experience, not a universal sample. The illustrative figures used in an earlier version of this piece (a "498 days" staleness, a "UGX 2.4B" award, an "82 percent complete" status) have been removed: they were invented illustrations of failure modes, not measured data.