Authority Is Not a Property of Rows

There is a town council in Uganda called MASAKA TOWN COUNCIL. It has 5,731 residents and it sits in Manafwa District, in the far east of the country, against the Kenyan border.

There is also a place called Masaka. It is a city of 294,166 people in the south-west, about 400 km away. The two have nothing to do with each other beyond a shared name.

Both rows come from the same file: the Uganda Bureau of Statistics census. Both are correct. A pipeline that joins geographic data on the string MASAKA will merge them anyway, and nothing in either source will complain.

This article is about defects of that shape — where every individual number published by an authoritative body is right, and the dataset built from them is still wrong. We have written separately about outright corrupted rows in official statistics, including a US Census character-substitution defect that invented four surnames. This one is the harder case, because there is nothing to correct. The source is fine. The assumption is wrong.

The assumption: a name identifies a place

It does not. In the parsed Uganda census — 2,669 administrative rows, of which 577 are town councils — five town council names are carried by two different councils each:

The MAYUGE pair is the instructive one, because one of the two is in Mayuge District and the other is not. A deduplication step that keeps "the row whose district matches its own name" would get this pair right by luck and get KINONI — where neither council is in a district of that name — silently wrong.

And MASAKA is worse than a duplicate, because the two rows are not even the same kind of thing: a 5,731-person town council in one district, and a 294,166-person city that is its own district. Join on the name and you either lose 98% of Masaka or gain 5,731 people in the wrong province, depending on which row your GROUP BY happens to keep.

The check that catches this is not a check on values at all. It is: is the field you are joining on actually unique in the source? One COUNT() ... GROUP BY name HAVING COUNT() > 1 over the 577 rows returns five, and five is not zero.

The same failure with a different authority: Wikidata

We hit the identical problem from the other direction while assembling city population weights. The method was to resolve each city name to a Wikidata entity and read the population claim off it. Wikidata is a curated, structured, machine-readable knowledge base — about as authoritative as an automated join can hope for.

The names that broke it were ordinary words:

None of these is an error in Wikidata. Every target entity is correctly described. The error is entirely ours, in believing that a name plus a country was enough to identify a settlement.

The residue is a file of 60-plus manual corrections spanning 17 locales — Bulgarian, Czech, Austrian German, Greek, Spanish, Finnish, Belgian and Canadian French, French, Croatian, Hungarian, Italian, Norwegian, Polish, Romanian, Moldovan Romanian, Russian, Slovak. That file is not derivable from any source. It is the accumulated record of every place where the automatic method was wrong, and if it were deleted, the only way to rebuild it would be to make all 60 mistakes again.

The one automated guard that does work is cheap and worth copying: when the resolved entity's country property does not match the locale's country, print a warning. Wrong-country hits are the loudest subset of homonym errors and they cost one comparison to find.

A number that appears twice is a transcription

The narrow version of the uniqueness check applies to values, not just keys. Wikipedia has carried a population of 195,531 for the Ugandan city of Mbarara. In the UBOS census file, 195,531 is the population of Kyengera Town Council, a Kampala suburb roughly 260 km away. Mbarara District's own total is 472,629.

Someone reading a long tabulated PDF took the value from the wrong line. It is the most ordinary error imaginable and probably the most widely propagated one in this article, because a Wikipedia population figure is copied onward far more often than a census PDF is opened. The rule is: a figure should appear in exactly one place. If city A's number is byte-identical to city B's number in the source document, one of them is a transcription, not a coincidence.

When the source will not tell you anything

A different failure mode is a source that is authoritative-sounding and simply not checkable.

forebears.io is the canonical example. It is a proprietary aggregator: it publishes no methodology per country, no source registry and no collection date. ridni.org and stats.ridni.org are the same kind of source: a number appears, and nothing behind it does.

We want to be precise about what we can and cannot claim here. We can say the data is unverifiable: there is no methodology to read and no way to re-derive a figure. We cannot say, and have seen no evidence for, the stronger claim that the site deliberately serves distorted figures to automated clients — that has been asserted in working notes we inherited and it is not supported by anything we can reproduce. An unpublished method is not evidence of a dishonest one.

The defensible position is narrower and still sufficient: a figure you cannot trace to a registry and cannot re-derive is at best a hint about ordering, never a weight, and any row that rests on one should be labelled in the dataset so a future reader knows which rows they are.

The part where this is about us

It would be comfortable to end here, with a list of other people's mistakes. The most expensive defect of this kind in the project was our own, and it survived precisely because it looked like a confirmation.

Ukrainian surname weights (uk_UA) once produced a top-10 share of 5.45% within the corpus. We had a figure of 5.45% recorded as Ukraine's real population-level top-10 share. The two matched exactly, and the match was read as validation.

It was the opposite. The relationship

top-10 share in corpus  ×  coverage  =  top-10 share in population

is an identity, not a hypothesis. If the two shares are equal, the identity says coverage is 100% — that the corpus contains every surname in the country. The corpus held 2,207 surnames. Ukraine has roughly 707,685. Coverage of 100% was impossible, so one of the two numbers had to be wrong.

Both were. The corpus figure was inflated by a flat tail: 1,900 of 2,207 entries (86%) sat at the minimum weight of 2 and together carried 71% of the total mass. And the "real" 5.45% was itself wrong — recomputed from Yu. Pradid's counts, Ukraine's top-10 surnames cover 821,657 bearers out of roughly 45 million, which is 1.83%; Мельник is 0.24%, not the ~1% we had carried.

"After" is the state on 18 July 2026, immediately after the fix. The corpus has been rebuilt again since: as of 22 July 2026 it holds 2,376 surnames on registry head counts, a top-10 share of 9.4% and, against the 1.83% population figure, an implied coverage of roughly 19% — which is the shape a thin corpus of a very flat repertoire should have.

A perfect agreement between two independently-obtained numbers is a fact that needs explaining, not a result that needs celebrating. This one was a double failure wearing the costume of a confirmation.

The related trap is circular verification. If your weights were calibrated from registry X, then checking them against registry X — or against a published paper that took its figures from registry X — measures your arithmetic, not the world. We caught this twice in one day: a Hungarian ethnonym estimate that appeared to confirm our 8.20% but drew on the same registry, and a Spanish check where top-10 share multiplied by coverage reproduced the population share almost tautologically. Our Taiwanese self-check agrees to 0.03 percentage points and we label it in the text as a self-consistency check rather than a verification, because that is what it is. The antidote is to type the comparison list in by hand from an unrelated source, and our top-list checkers do exactly that.

What to actually do

1. Test the join key for uniqueness before joining. Not the values — the key. Five duplicated names among 577 Ugandan town councils is one GROUP BY away.
2. Test whether two rows sharing a name are the same kind of object. MASAKA TOWN COUNCIL and MASAKA CITY differ by a factor of 51 because one is a town council and the other is a district-level city.
3. Test that a value appears once. Identical figures on two entities mean transcription.
4. Warn when a resolved entity leaves the expected country. Cheapest possible guard against homonyms, and it caught Nokia and León.
5. Keep the manual-correction registry in version control and treat it as primary data. Sixty corrections that no source can regenerate are worth more per byte than anything else in the pipeline.
6. Distrust agreement. Where two numbers match exactly, find out whether they are independent. Where they are not, the match means nothing.
7. Label rows that rest on unverifiable sources, so that a future maintainer can find them without re-deriving the provenance.

Authority is a property of institutions. Correctness is a property of rows. The Uganda Bureau of Statistics is authoritative and its file contains two different places called Masaka, because Uganda contains two different places called Masaka. The defect was never in the census. It was in the join.

Data as of 2026-07-18

All figures were recomputed on 18 July 2026 from the primary and staging files listed below. Where our earlier working notes disagreed with the files, the files win, and the disagreement is stated in the text.

Sources:

• Uganda — UBOS, National Population and Housing Census 2014, regional area-specific profiles parsed to an administrative hierarchy (2,669 rows at district / county / sub-county level; 577 town councils). MASAKA TOWN COUNCIL 5,731 in Manafwa District, Bubulo West County; MASAKA CITY 294,166; the two MAYUGE TOWN COUNCIL rows at 12,481 (Bugiri) and 20,197 (Mayuge). <ubos.org/&gt;
• Wikipedia, article on Mbarara, population 195,531 — matching Kyengera Town Council in the same UBOS file. Mbarara District total 472,629.
• Wikidata — used to resolve city names to population claims; homonym failures corrected in a manual patch registry of 60-plus entries across 17 locales.
• Ukraine — corpus of 2,207 surnames (as it then stood) against approximately 707,685 surnames in the country; top-10 population share recomputed from Yu. Pradid's counts at 821,657 bearers, giving 1.83%.
• forebears.io — proprietary aggregator, no published per-country methodology, no source registry, no collection date; figures cannot be traced to a registry or re-derived.

On the forebears.io claim. Working notes we inherited asserted that the site returns deliberately distorted data to automated clients. We could not reproduce or otherwise substantiate that, so it is not claimed in this article; what is claimed is that the data is untraceable, which is verifiable and sufficient.

On the coverage identity. top-10 share in corpus × coverage = top-10 share in population is an algebraic identity given consistent definitions. It is useful because it punishes coincidence, and dangerous because it is trivially satisfied when both sides derive from the same registry. See How to Audit a Name-Frequency Dataset and What We Got Wrong About Name Data.