How PDU works

Every important figure on PDU follows one chain: a claim, its source, the evidence behind it, any analysis PDU performs, and the resulting status. PDU stores claims rather than facts, which is why two sources disagreeing is something the platform can show you instead of something it has to hide.

Government information is an important source, and it is still a source. If a government report states a project is complete, PDU records that a government institution stated it, on a given date, in a named document. It does not convert that statement into “complete” on its own. Where no independent evidence exists, the platform says so plainly: officially reported complete, completion not independently verified.

Six categories, never merged. The category is attached to the statement, not to the institution that made it.

Official claim

What a government institution states happened.

Verified data

Supported by an authoritative dataset or by more than one reliable source.

Field verified

Recorded through physical verification at the location.

Citizen report

Submitted by a member of the public and reviewed before publication.

PDU analysis

Calculated by PDU from the evidence listed, not reported by a source.

Unverified

Stated somewhere, but PDU has not located evidence for it.

Each record carries a level from A to E. The level describes the strength of the evidence, not the importance of the project.

Adirect official data

Taken from an official primary dataset or document.

Bmultiple official sources

Two or more independent official sources report the same thing.

Cofficial plus field evidence

Official documentation supported by physical verification.

Dcitizen or secondary evidence

Public reports that have not been independently verified.

Einsufficient evidence

Not enough evidence to state anything with confidence.

Levels are computed from the claims attached to a record: one official primary source gives A, two independent official sources agreeing gives B, official documentation plus physical verification gives C, citizen evidence alone gives D, and nothing usable gives E.

PDU uses a fixed status vocabulary, deliberately descriptive rather than emotive. “Unknown” is a normal and common answer.

Each project shows two statuses. The officially reported status is what government sources state. The PDU assessment is the platform’s reading of the available evidence, and the reasoning behind it is shown on the project page.

PDU deliberately publishes no single government score. A figure such as “78 per cent successful” would hide the difference between a completion rate, a budget execution rate and an outcome indicator. Instead the platform reports each dimension separately, with its denominator, and lets you inspect the evidence.

Every attribute PDU records a claim about has a published definition. These are read directly from the database, so this table cannot drift from what the platform actually stores.

An allocation is not expenditure. PDU stores each financial stage separately, and never sums across them: allocated, revised, released, committed, spent and audited. A budget line records an allocation only; anything actually released, committed, spent or audited is a separate record with its own source.

Where only an allocation exists, the platform shows the allocation and states that no expenditure figure has been located. It does not present the allocation as spending.

Turnout is votes cast divided by registered voters. Candidate share is candidate votes divided by valid votes. These denominators are enforced in the database rather than computed in the interface, so the wrong one cannot be used by accident. Registered voters, votes cast, valid votes, rejected votes and candidate votes are all stored separately.

Election data is historical context only. PDU does not connect results to subsequent delivery performance, does not rank candidates, does not predict outcomes, and does not store any individual’s political preference. Electoral information is aggregated at county, constituency and ward level only.

The same road can appear in a delivery report, a ministry page, a budget document, a procurement notice and a county plan. PDU aims for one canonical record per project, with every source attached to it.

Candidate matches are proposed from name similarity, shared ward, shared contractor, matching procurement reference, proximity of coordinates and overlapping dates. A proposed match is a suggestion until a human approves it, and the signals behind each suggestion are recorded so the decision can be reviewed later.

When two sources report different figures for the same attribute, PDU flags a contradiction and shows every reported figure in the order it was stated, with its source. The platform does not average them, and does not select the most favourable one.

Resolving a contradiction means recording why the sources differ, for example because they cover different reporting periods or use different definitions. It never means deleting a figure.

AI is used for extraction and explanation, never for generating facts. Specifically: for pulling structured data out of documents, identifying promises, extracting dates and amounts, comparing two versions of a document, spotting contradictory figures, suggesting duplicate records, classifying sectors, summarising long reports in plain language, and raising questions that need human checking.

Every AI output must cite the source version or claim it came from. Where it cannot, it is required to say that the evidence is insufficient rather than produce an answer. AI output is stored with its model, its citations and its review status, and anything asserting a fact is marked as needing human review before it is published.

PDU treats its own ingestion as crawling, so a publisher’s robots.txt applies to it. Before any source is configured for automated retrieval, its robots policy is fetched and recorded against the source, and the database refuses to mark a source as automatically retrievable without it.

This has a concrete consequence worth stating plainly. The Government Delivery Unit publishes county-level project information through a path that its robots.txt disallows for crawlers. PDU therefore does not fetch it automatically. That data reaches the platform through a recorded administrator import, where the person who supplied the capture, the time they supplied it, and the checksum of the file are all stored alongside the resulting records.

Where a publisher offers an API or a downloadable dataset, PDU uses that in preference to reading pages.

What a recorded import involves

A supplied file is not a weaker kind of evidence than a fetched one, and it is not treated as a stronger one either. It goes through the same machinery: the bytes are hashed with SHA-256, stored so a citation can still be checked if the publisher changes or removes the original, and recorded as a source version that cannot be edited or overwritten.

Three things are added that a fetch does not need:

• The person who supplied it, and when. A staff account is created by an administrator; no role is ever inferred from an email address.
• A stated reason for supplying it by hand, published on the data sources page next to the records it produced. "The publisher disallows automated retrieval of this path" is an acceptable reason. Having no reason is not.
• Every line of the file, kept permanently, so any published figure can be traced back to the exact row it came from and compared with the raw text of that row.

Each mapped column becomes a claim carrying the document, the row and the wording that was read. A value PDU cannot read is left empty with the reason recorded; it is never replaced with a guess. A place name that does not match the official register is reported as unmatched rather than attached to the nearest similar name. Status wording is mapped onto the PDU vocabulary using a published list of synonyms, and the original wording is kept on the claim so a reader can judge the mapping. Unrecognised wording becomes "unknown".

Rows where something could not be resolved do not import unless an administrator explicitly includes them, and that decision is recorded on the batch. PDF files are not accepted: a PDF table has to be converted to a table first, so the conversion itself can be checked line by line rather than trusted.

Citizen reports and field verification are different things and are labelled differently. A citizen report is submitted by a member of the public and moves through submitted, under review, and then verified, rejected or insufficient evidence. The full review history is kept, so a rejection can always be explained. A report is never published as a fact on its own.

Field verification is carried out by a PDU verifier who records the location, the observed physical status, photographs and written observations. Because it is physical evidence attached to official documentation, it raises a record to evidence level C.

Photographs are stored with their capture time, upload time, any location metadata and a checksum. Identifying metadata is removed before storage, and personal details of reporters are never exposed publicly.

Every project page carries a correction control. If a location is wrong, a contractor is misnamed, or a project has finished since the last source was published, you can say so. A correction becomes a review ticket rather than an edit: PDU does not change a public record directly on the basis of an anonymous claim.

Every accepted change is written to an append-only audit log with the previous value, the new value, who made the change, when, and the source that justified it. If you challenge a number, an administrator can open the record and tell you where it came from, when it was published, who published it, and what other evidence supports or contradicts it.

Suggest a correction

PDU is populated source by source, and the platform reports what it holds rather than filling gaps with estimates. The order of work is:

1. Loaded. IEBC registered-voter statistics for the 2022 General Election, which also provide the authoritative list of 47 counties, 290 constituencies and 1,450 county assembly wards.
2. In progress. Government Delivery Unit pillars and scorecards from the pages its robots.txt permits, plus the administrator import path for county-level delivery data.
3. Queued. National Treasury budget estimates and implementation reports, for allocations and development expenditure by county.
4. Queued. Office of the Auditor-General reports, recorded as audit observations rather than findings of wrongdoing.
5. Queued. KNBS county statistical abstracts and economic indicators, for the 2022 baseline and the indicator series.
6. Queued. Parliamentary records, procurement information, ministries, agencies and county governments.

See the full source directory and each source’s retrieval history

• Absence of evidence is not evidence of absence. An empty ward page means PDU has not located a sourced record for that ward, not that nothing has been built there.
• Sources rarely state whether a completion percentage refers to physical progress, financial progress or elapsed time. Where a source says, PDU records it; where it does not, the ambiguity remains.
• Counting methods for reported beneficiaries differ between institutions and are usually not published, so those figures are not comparable across sources.
• PDU does not interpolate missing years in an indicator series. A gap is shown as a gap, and any estimated value is labelled as estimated.
• An output is not automatically treated as the cause of an outcome. Unless a source establishes causation, the relationship is presented as a related indicator.
• Place names are published in title case for readability, while official registers publish them in upper case. The exact published string remains in the stored capture of the source version each place record points at.