Match rules are so strict that true duplicate customer rows never merge, leaving fragmented service history across systems. What does this situation represent?
Select an answer to reveal the explanation.
Short Explanation
If the twins never get introduced, you still have two half-stories about one customer—that miss is a false negative. Strict rules feel safe until service desks cannot see the whole history. Tune precision and recall to the risk you can live with.
Full Explanation
Match rules so strict that true duplicate customer rows never merge, leaving fragmented service history, represent false negatives that miss true duplicates; teams should tune match rules and thresholds to the organization’s risk tolerance. Civic service continuity suffers when one resident appears as many. Calling fragmented history successful survivorship fails; survivorship assumes correct matching first. Treating it as only a false-positive problem fixed by deleting unmatched rows fails the error-type diagnosis and destroys data. Claiming MDM cannot help operations and should remain analytics-only fails when operational fragmentation is the symptom being observed. Exam caveat: false negative = missed true duplicate; tune toward recall without ignoring false-positive risk. Operational check: measure known-duplicate recall on a steward-labeled sample, relax overly strict exact rules with standardized attributes, and re-check fragmentation in service history. Balance municipal risk appetite in a written match policy so tuning is not ad hoc per developer. 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.