Two golden records appear for the same branch because legacy regional codes differ. How should matching be redesigned?
Select an answer to reveal the explanation.
Short Explanation
Regional keys can put the same branch in different buckets—like filing one person under two zip codes. Match across those legacy segments when the real-world entity is the same.
Full Explanation
Two golden records for the same branch because legacy regional codes differ means matching should add cross-region match rules so legacy segment keys do not hide true duplicates. Civic consolidations often inherit regional silo keys that block obvious matches. Treating every regional code as a permanent separate legal entity forever fails when the branch is truly one organization. Disabling matching entirely inside each region to shrink the queue fails by preserving fragmentation. Overwriting all branch codes with a random UUID at each nightly load destroys stability needed for deterministic matching. Exam caveat: cross-region / cross-segment matching overcomes legacy key partitions that hide duplicates. Operational check: design match rules that ignore or map legacy region codes when other strong attributes align, review samples with stewards, and merge confirmed duplicates with crosswalks retained. Document regional-code handling in the municipal match policy. Keep verification evidence with the municipal runbook so audits can prove the chosen control was applied as designed and that rejected alternatives would have left city services exposed to the failure modes described above.