NorthMock · Sources, process, and limitations
How NorthMock builds safe test data
This methodology explains who maintains NorthMock, how each record is assembled, why the generator exists, and where its source data and safety boundaries come from.
Purpose and scope
NorthMock is maintained as a developer and QA utility for form validation, checkout sandboxes, onboarding demos, CRM testing, and location-aware interface previews. It exists to keep personal contact details out of routine development workflows.
A generated row is not a real identity. Its address, name, phone value, and email are selected or assembled independently. Addresses may describe real places, but NorthMock does not claim that the generated person lives there or has any relationship with that location.
How one generated record is assembled
Region-aware address
The Worker reads only the selected region file from private R2 storage and chooses one address from that pool. Repeated generation keeps the requested state, province, or territory fixed.
Independent fictional name
A first name and surname are combined at runtime from aggregate public frequency lists. Complete identities are never imported from those sources.
Safe and masked phone values
The copy-ready number uses a local area code with the reserved 555-0100 through 555-0199 fictional range. A separate officially assigned prefix is shown only with its final four digits masked.
Disposable email
The original five username formats are preserved on gravityengine.cc. The matching inbox opens at mail.chatgpt.org.uk in a new tab for verification-flow testing.
Address processing and coverage
- Normalize and group. Records must contain a supported two-letter region code and a non-empty full address.
- Deduplicate. Exact full-address duplicates are removed within each region before the files are generated.
- Fill minimum coverage. Regions below 60 unique rows receive openly licensed supplemental civic or building address data.
- Validate postal region. The build rejects malformed fields, US ZIP values absent from the current public USPS AISU list, and ZIP or FSA values that clearly belong outside the selected region.
- Publish aggregate facts. Region pages expose record counts for the most represented locality labels and postal prefixes, but never publish the complete address pool.
Source boundary: the original base pool is a private legacy dataset. The open-data attributions below apply to supplemental records and should not be interpreted as provenance for every base record.
Current quality and safety controls
| Component | Control | Current evidence |
|---|---|---|
| Addresses | Per-region files, deduplication, and a minimum of 60 rows | 103,189 rows across 64 regions |
| Coverage facts | Current USPS ZIP listing plus region-level ZIP/FSA checks | 103,189 validated rows (100.0%) |
| Names | Aggregate first-name and surname indexes combined independently | 400 first names × 1,000 surnames |
| Safe phone | Reserved 555-01XX subscriber lines | No assigned subscriber line is completed |
| Assigned prefix | Official NANPA/CNA prefix with XXXX masking | US updated 2026-07-14; Canada updated 2026-07-13 |
| Search pages | Stable server-rendered content with generated identities loaded later | No random identity is embedded in indexable HTML |
Sources and licenses
NorthMock links to primary or licensing sources so the current indexes can be checked independently:
- US Social Security Administration popular first names
- US Census Bureau 2010 surnames
- NANPA assigned central-office-code data
- Canadian Numbering Administrator assigned-code data
- USPS Publication 28 postal addressing standards
- USPS AISU current ZIP code list
- Canada Post civic-address guidelines
- Canada Post postal-code and FSA guidance
- © OpenStreetMap contributors and licensing
- OpenAddresses project
- Open Government Licence – Yukon
- City of Yellowknife Open Data License v1
Limitations and permitted use
- Coverage counts describe the current generator pool, not population, postal completeness, deliverability, or geographic importance.
- Region-level postal validation does not verify a specific street or guarantee mail delivery; addresses must not be used to establish residency or bypass identity checks.
- Masked assigned phone prefixes may correspond to real active exchanges; the subscriber digits intentionally remain hidden.
- Generated records are intended for legitimate development, education, demonstrations, and sandbox validation only.