The visible feature was only the surface
A static historical audit list is inconvenient to search manually, especially on mobile, while submitting a tax identifier to another application server creates avoidable query exposure.
The system also had to respect concrete constraints. The data is historical, not live audit/compliance status. Claimed NBR provenance, accuracy, completeness, and redistribution rights are not established. Shipping the dataset to browsers makes records retrievable even though lookup queries stay client-side.
My role covered data modeling, validation, and release engineering, with responsibility for provenance, transformation, validation, and distribution.
I turned the constraints into boundaries
Next.js lookup UI; session-cached static JSON dataset; client-side normalization and exact matching with no TIN submission API.
Perform lookup entirely in the browser to avoid server receipt of entered TINs.
Normalize formatting characters but require an exact digit match.
Show match state and mapped details without inferring reasons, current status, or broader compliance.
The key decision: Perform lookup entirely in the browser.
The implementation had to prove the model
I delivered the work across the full path: Converted the bundled list into a focused responsive lookup. Implemented one-fetch-per-session in-memory caching and digit normalization. Added privacy/provenance/methodology warnings and official-verification guidance. Documented deployment and the repository's missing test/security/license controls.
The result is concrete: Users can search the historical list quickly. Lookup text is not submitted to an application API. Matches return bounded mapped details. Non-matches and matches are both framed as requiring current official confirmation.
The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.