A postcode directory and an address register answer different questions. The directory says whether a code is in use, roughly where it is, and which towns it is written with; the register says whether a particular building stands on a particular street. They are compiled from different publishers on different days, and on 17 September 2026 the two started talking to each other: a register of buildings now contributes, as it compiles, the towns its buildings are written with and the mean of their positions to the country's postcode directory. This guide is about what that adds, what it deliberately does not do, and why the United States gets its extra place names from somewhere else.
What the register adds
Ten registers declare it: Switzerland, Austria, Czechia, Norway, the three Belgian regional files, Luxembourg, Australia and Latvia. As each compiles, every postcode its rows carry is aggregated once — the distinct towns written under it, capped at two hundred and deduplicated by their folded form, and a centroid averaged over the buildings that carry a position — and after the register's indexes are installed the country's directory is augmented: a code the directory lacks is inserted under the register's own dataset name with a -postcodes suffix, and a code the directory holds gains the register's towns after its own and a centroid only where it had none. The directory's dataset name, version, coverage claim and prefix length stay what they were.
Two things improve for a lookup. locality_matches_postcode now knows every town a register writes under a code, not only the operator's default one — a Czech code that the postal-code dump lists with one obec now lists every settlement the state register files under it — and postcode_status: live answers for codes the dump never carried at all. Measured on the Czech register on 17 September: 38 codes added to the dump's 2,694, and 2,639 codes given the register's places, for 2,732 in the directory.
The Saturday places sync, which already re-applies Open Names' places to the British directory after the weekly dump replaces its rows, re-applies the registers' contributions the same way, so a fresh copy of the dump never loses them.
Why augment, and not replace
The obvious design was to let a complete register replace the directory outright: if the register lists every building in the country, its postcodes are the country's postcodes, the directory could be recorded complete, and a code the register lacks could answer postcode_not_found. It would have been wrong, and the reason is worth stating because it recurs everywhere in this product.
A register of buildings never lists the postcodes that have no buildings. Swiss and Austrian Postfach codes, Australian GPO box codes, the Czech special codes for large recipients, the Norwegian codes reserved for box customers — these are real codes that real post is addressed to, and none of them stands at a building. A directory rebuilt from a register would have turned every one of those addresses into postcode_not_found, which is not a mismatch but a refusal: the address is invalid and free, and the customer behind it is real. So the register adds and never subtracts, and coverage does not move to complete by itself. It moves only when the operator's published total of codes is configured for the country and the union of the dump and the registers reaches it, and on 17 September no country's total is configured, because the totals the operators publish were not ones anyone in the session could state with confidence. A directory that is partial denies nothing; that is the honest state until the number is known.
The three Belgian registers illustrate the other half of the design. They are three files for one country, and each augments the same Belgian directory in turn; nothing is overwritten, so the last file to compile does not decide what the first two contributed.
The United States, and why it stays unscored
The American directory has the opposite problem. The postal-code dump carries exactly one place per ZIP — the postal service's default city — while the postal service accepts several names for many codes, and no open source publishes that list. A customer who writes "Moffett Field, CA 94043" or "Hollywood, CA 90028" is writing what their mail is delivered to, and the directory used to answer locality_matches_postcode: false.
The United States has no complete open register to augment from, so the directory learns from a different publisher: the Census Bureau's ZCTA-to-place relationship file, public domain, which lists for every ZIP code tabulation area the incorporated places and census-designated places whose land it touches. Applied on 17 September to the 41,488 installed ZIPs — a 9.8-megabyte file last modified in December 2021 — it gave 28,668 of them additional places in 3.5 seconds. ZIP 94043 now lists Mountain View, Palo Alto and Sunnyvale, and "1 Main Street, Palo Alto, CA 94043" answers locality_matches_postcode: true.
It does not list Moffett Field, and it does not list Hollywood. The file describes the places whose land a ZIP touches, and a neighbourhood of Los Angeles is not a place in the census sense, while a postal name for a military field is not one either. The Census list is therefore a better approximation of the postal service's acceptable names than the default city alone, and still not that list, which is why the American directory keeps its primary places declaration and a town mismatch there is still reported in the field and never scored. That is a deliberate asymmetry: a false locality_mismatch on a legitimate American address would put thirty points on the most common address in the product for a reason the customer cannot see, and a missing thirty points on a wrong town is the cheaper mistake.
Reading the answer
Nothing new appears in the fields; what changes is how often the existing ones say true. confirmation.locality answers postcode_directory when the town is one the directory lists under the code — including the towns a register added — and postcode_area when it is one listed somewhere in the code's area, and unconfirmed otherwise; locality_mismatch fires only in the last case and only in a country whose directory lists every place, which the United States does not. sources names the directory dataset and, for a code a register contributed, the register's -postcodes dataset with the register's version, so a customer can see which publisher the town came from.
For Australia the contribution lands on the register's next sync — the G-NAF compile takes the better part of an hour and was not re-run for this — and Denmark's and New Zealand's registers are not compiled on the reference machine at all. Each register's status row on the data page says whether its postcodes have been applied.