Two resident rows show 'Jon Smith' and 'John Smith' at the same address with the same phone number. What should matching capability primarily accomplish?
Select an answer to reveal the explanation.
Short Explanation
Jon and John at the same porch with the same phone are waving the same flag—matching exists to notice that wave even when the name string wobbles. Exact-only name equality leaves true twins on the floor; reckless last-name merges smash strangers together. Good match rules weigh evidence, not vanity spelling.
Full Explanation
Rows showing 'Jon Smith' and 'John Smith' at the same address with the same phone should be handled by matching capability that identifies candidate duplicates despite string variation using deterministic and/or probabilistic rules—not by naïve exact-only or reckless merge-all tactics. Civic party matching must tolerate real-world name noise. Rejecting both rows because any spelling difference proves different legal persons fails by creating false negatives that fragment resident history. Requiring exact character match on full name before any candidate pair fails the same brittle exact-match trap. Merging every same last name citywide without reviewing supporting attributes fails by generating dangerous false-positive merges. Exam caveat: matching seeks candidates under uncertainty; deterministic and probabilistic methods address variation—exact-only is usually insufficient. Operational check: configure rules on name variants plus address and phone, review a sample candidate queue with stewards, and measure precision/recall before auto-merge thresholds go live. Document municipal risk tolerance for false merges versus missed duplicates in the 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.