Collision Detection Review¶
Review — instantiates Durable Identifier Binding
Scans existing bindings for identifiers that point at the same entity twice — or one identifier stretched across two entities — and routes each conflict to a steward for a merge-or-split decision.
Mint-time checks catch handles that are syntactically wrong or already taken; they cannot catch two perfectly valid, perfectly unique handles that have quietly ended up naming the same real thing — or the reverse, one handle stretched to cover two different things. Collision Detection Review is the retrospective, referent-level pass that hunts exactly these: it applies the archetype's identity criteria across the existing bindings, surfaces candidate duplicates and overlays, and routes the ambiguous ones to a human for adjudication. Its distinguishing concern is semantic collision after the fact, not the token's form — the collision it looks for is invisible to any per-item validator because every handle involved is individually legal.
Example¶
Two clinics merge, and their patient records flow into a combined master patient index. The review runs a match pass over the index and finds two problems. First, "J. Alvarez, DOB ≈1961-03" appears under two different patient IDs — a duplicate: one person, two handles, so half her history hides behind each. Second, a single ID has accidentally accumulated visits from a father and son who share a name and address — an overlay: two people, one handle, the dangerous case, because it can mix one person's allergies into another's chart. The review scores each candidate on name, birth date, address, and identifier fragments, auto-resolves only the unambiguous duplicates, and drops the doubtful pairs — including the overlay — into a data steward's queue for a human merge-or-split ruling.
How it works¶
What sets it apart is that it reasons over pairs and clusters of existing records, not over one handle at a time:
- Operationalize the identity criteria. Turn the archetype's "when are two records the same referent?" rules into concrete match logic and similarity scores.
- Generate and score candidates. Compare records (usually after a blocking step to stay tractable at scale) and rank the pairs most likely to be the same referent — or the single handles most likely to span two.
- Triage by confidence. Auto-merge only the near-certain, leave the clearly-distinct alone, and route the ambiguous middle band to the dispute queue rather than guessing.
Tuning parameters¶
- Match threshold — how similar two records must be before they are flagged; loosen it to catch more duplicates at the cost of more false merges, which fuse two real entities and are far harder to undo.
- Auto-resolve vs. always-review — the confidence bar above which the review merges on its own versus requiring a steward's sign-off; trades throughput for safety.
- Cadence / trigger — a periodic sweep versus an event-triggered run after a migration, acquisition, or bulk import, when collisions spike.
- Asymmetric cost weighting — how much worse a false merge (two entities fused) is treated than a missed duplicate; on people or money the asymmetry should be steep.
When it helps, and when it misleads¶
Its strength is seeing what nothing else can: collisions where the handles are flawless and only the referents clash. It is also the one mechanism that can detect and unwind an overlay, the failure mode that silently corrupts data by attributing one entity's facts to another.
Its danger is the mirror image of its power. Over-eager matching produces false merges, and a merge on weak keys can be worse than the duplicate it was meant to fix — fusing two distinct people is a harm, not a cleanup, and often barely reversible. Everything is capped by match quality, and the tempting misuse is to crank the threshold down to hit a "records deduplicated" target, manufacturing tidy numbers by fusing things that were never the same. The discipline is asymmetric costs (never auto-merge on weak keys), a reversible logged decision for every merge, and human adjudication for the whole ambiguous band. This is the standard practice of record linkage, the discipline of deciding when two records describe one entity.[1]
How it implements the components¶
identity_persistence_criteria— it operationalizes these criteria as concrete match rules and thresholds; deciding "same referent or not?" is the whole engine.collision_or_dispute_queue— it populates and works this queue, routing every conflict it cannot safely auto-resolve to a steward.
It does not validate a handle's form or its mint-time uniqueness — those are Check-Digit or Format Validation and the UUID or Random Token Generator — and it does not record the merge it triggers as a succession link; that is enacted in the Identifier Lifecycle Register.
Related¶
- Instantiates: Durable Identifier Binding — it is the safety net that catches binding failures the assignment step could not see.
- Consumes: Identifier Registry — it reads the authoritative bindings it scans for collisions.
- Sibling mechanisms: Identifier Lifecycle Register · UUID or Random Token Generator · Check-Digit or Format Validation · Identifier Registry · Persistent Identifier Resolver · Alias Redirect Table · Identifier Minting Workflow · Namespace Prefix Registry · Accession Numbering Protocol · Identifier Reservation Queue
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Scans existing bindings for identifiers that point at the same entity twice — or one identifier stretched across two entities — and routes each conflict to a steward for a merge-or-split decision, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Collision Detection Review as 'Scans existing bindings for identifiers that point at the same entity twice — or one identifier stretched across two entities — and routes each conflict to a steward for a merge-or-split decision', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Data Science & Analytics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Record-linkage and entity-resolution practice established retrospective scans that score candidate pairs, separate true matches from nonmatches, and route uncertain cases for clerical adjudication.
Related originating lineages:
- Library & Information Science — Authority control supplies durable referent stewardship, identity differentiation, and reversible merge or split practice.
- Statistics & Experimental Design — The Fellegi-Sunter decision model supplies probabilistic matching weights and explicit uncertain-match regions.
Review resolution: The Census Bureau describes entity resolution as matching records that describe the same entity and documents production use of Fellegi-Sunter scoring; OCLC documents duplicate detection, merging, and authority-file identity control. The full review workflow is closest to data-science entity resolution, with statistics and library stewardship as formative lineages.
Attribution caveat: Library authority control predates modern entity-resolution systems, but data science is primary because the defining operation is a retrospective scored scan over records followed by human adjudication.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- U.S. Census Bureau: Four Cooperative Agreements on Record Linkage and Entity Resolution
- U.S. Census Bureau: Methods for Record Linkage and Bayesian Networks
- OCLC: WorldCat Cooperative Quality
Notes¶
The review only finds and routes; it does not itself enact the fix. The actual merge or split is carried out downstream, in the registry and recorded as succession in the Identifier Lifecycle Register. Keeping detection separate from enactment is what makes every merge auditable and — crucially, given the cost of a wrong one — reversible.
References¶
[1] Fellegi, I. P., and Sunter, A. B. "A Theory for Record Linkage". Journal of the American Statistical Association 64(328), 1183–1210 (1969). Defines record linkage as deciding whether a pair of records represents the same underlying person, object, or event. registry ↩