Repository navigation
Validate US phone area-code candidates using sources with documented reuse terms #1140
Description
Removing NANPA-derived screening in #1139 restores erroneous Wikidata dialing-code statements to the US phone sampler. We are accepting this data-quality regression for that PR and tracking replacement validation here.
At PR commit 2a6126e0643ad4017ecd5bf78e44077c2b9e31cf:
- ZIP
98933always selects590; before chore: remove NANPA screening from phone sampling data #1139 it selected509. - Indianapolis ZIP
46201can select unassigned486. - California ZIP
95417can select Canadian639.
Reproduce the first example through the public sampler helper:
from data_designer.engine.sampling_gen.entities.phone_number import PhoneNumber
print(PhoneNumber.from_zip_prefix("98933"))
# The area code is always 590.Comparison with the previously pinned screening reference found 19 newly sampleable codes that fail US/geographic/in-service checks. In total, 91 ZIPs contain a non-US, non-geographic, or out-of-service candidate, accounting for approximately 0.253% of the nationwide sampler probability. This is separate from approximate ZIP boundaries or uncertain overlay market shares.
The current 307 sampler/rebuild tests pass because they verify artifact consistency, weights, numeric shape, and selected regional examples; they do not establish numbering validity.
Expected outcome
- Establish replacement validation for country, geographic use, active status, and state association using sources with documented reuse terms and reproducible inputs.
- Regenerate the lookup and update its manifest, NOTICE, build report, and reconciliation.
- Add regression coverage for invalid/foreign codes and wrong-state associations while preserving ZIP identifiers, population weights, and valid overlay candidates.
- Keep NANPA-derived exclusions out of the replacement; copying the old list back would restore the dependency chore: remove NANPA screening from phone sampling data #1139 removes.
Review evidence: #1139 (comment)
Activity
andreatnvidia commentedon Nov 6, 2026
Thanks for tracking this, @nabinchha. Google’s libphonenumber metadata looks like a candidate for the replacement validation.
Dane (@danecor) also highlighted a separate completeness issue in his comparison of the #1134 build: 41 in-service geographic codes were absent:
not_selectedin that build; the current report also includes additional source values, so its raw status count differs.The mechanism Dane pointed to is that alternatives are retained only at the chosen locality point. An overlay recorded on a different, less central locality can therefore consistently lose selection. His suggestion was to expand a selected code with its confirmed overlay partners. That would require a mapping with documented permissive reuse terms and tests that preserve geographic splits. Libphonenumber is a validation candidate; an appropriate overlay-partner source still needs investigation.