Entity Resolution Bridge Records: A Cluster Acceptance Test

Executive Summary

A sparse bridge record is a record with so few populated fields that no attribute contradicts either of two otherwise distinct groups of records. Because it conflicts with nothing, a pairwise matcher can score it above threshold against both groups, and a cluster built by transitive closure then joins two real entities that were never compared with each other. A July 2026 preprint by Pavani et al. demonstrates this with a three-record example in which the bridge connects a Portland record and a Seattle record that share a name ^[1]. The authors state that the matcher never directly scores the two endpoints ^[1], and that this is "not a matcher bug" but "the geometry of the problem" ^[1].

This report converts that observation into an acceptance test that a context engineer or identity steward can run on the observable output of any matching pipeline. The test asks four questions: are the endpoints of each candidate bridge directly supported, are contradictory attributes exposed, does the proposed cluster survive removal of the bridge, and is the past decision reproducible. Answers go on a sign-off worksheet that ends in accept, hold as ambiguous, or reject. The "hold" state mirrors the possible-match region of the classical three-way linkage decision ^[2] and its clerical review region ^[3].

The evidence is uneven. Transitive closure is long known to trade precision for recall: the 2009 duplicate-detection evaluation by Hassanzadeh et al. found that it places many dissimilar records together ^[4], and a 2020 survey describes clusters dominated by non-matching descriptions when false positives are common ^[5]. The Pavani et al. ablation covers six public benchmarks spanning 864 to 5 M records ^[1]. Connected components lowered F1 from 0.889 to 0.771 on one dataset while verified merge reached 0.972 ^[1], yet verified merge fell far below the center-based baseline on another, which the authors link to a matcher precision of 0.509 ^[1]. They call verified merge "a safety net, not a cure" ^[1]. No universal winner emerges.

For measurement, sample clusters from an explicit frame, stratify by bridge risk, adjudicate each sampled cluster for distinct entity labels, and report the false-merge rate with a Wilson interval ^[6] rather than a bare percentage. Naive benchmark precision can sit near 100% while true precision is 52% ^[7], so the frame must be stated. The paper's numbers are dataset-specific, come from one seed without variance estimates ^[1], and should not be generalized. How often sparse bridges occur in any estate is unmeasured in the literature; the test exists to measure it locally.

Introduction and Background

Entity resolution (ER), also called record linkage or deduplication, decides which records describe the same real-world entity. Most evaluation effort goes to the pairwise step, where a matcher scores two records. Approval decisions, however, are made on clusters, because the canonical record that downstream consumers read is the cluster, not the pair. Cluster-based ER builds equivalence classes of entities through clustering ^[8], and the simplest rule takes each connected component of the match graph as one entity ^[2]. That rule enforces transitivity: if A matches B and B matches C, then A, B and C become one entity, even if A and C were never compared.

Transitivity is an assumption, not a property of learned matchers. The Pavani et al. preprint states that "Transitivity is an assumption, not a guarantee" ^[1] and that a single borderline edge can propagate through Union-Find and chain unrelated clusters when the matcher's false-positive rate is non-trivial ^[1]. A vendor's build-versus-buy discussion describes the same chain, in which A and B match, B and C match, and A, B and C are inferred to be one entity even if A and C look different ^[9]. The cost of an error is that a merged cluster is inherited by every consumer, and matching produces pairs while what is usually wanted is clusters ^[9].

This report is a practitioner testing protocol, narrower than a definition of ER, a merge-versus-relate policy, or a choice of F1. It addresses one decision: whether an identity steward should approve a canonical cluster for a downstream decision when a sparse record may be the only link between two of its parts. It evaluates observable cluster outputs and does not assess any vendor's matching internals.

Reliable Context, the publisher, provides a system of record in which one canonical record stands for each real thing, ambiguity is shown rather than hidden, and related organizations relate rather than merge. This report does not describe how any product reaches those outcomes; it treats them as properties a reviewer can check in exported output, and the tests apply equally to an in-house pipeline. A reader who needs a matching engine or a master data management suite should choose a tool built for that.

The Pavani et al. paper is a July 2026 preprint on arXiv, not peer reviewed. Saeedi, Peukert and Rahm's incremental cluster repair appeared at the European Semantic Web Conference (ESWC) in 2020 ^[10]. Observations are as of October 2026.

Defining the Identity Unit, the Pair Match, the Cluster and the Bridge Record

Four terms carry the protocol, and each must be fixed before a cluster can be tested.

• Identity unit. The identity unit is the kind of thing one cluster is supposed to represent. In the Pavani et al. example it is a physical location, and a cluster merging a Portland and a Seattle restaurant is wrong "under the per-location definition" ^[1]. The same records can be right under one unit and wrong under another: a cluster of two branches is a sound "organization" cluster and a false "location" cluster. The worksheet therefore makes the identity unit its first field.

• Pair match. A pair match is a decision, usually a score above a threshold, that two records describe the same unit. In the Fellegi-Sunter model, as summarized by Binette and Steorts, each pair receives one of three actions: link, possibly link, or not link ^[2]. The US Census Bureau's overview says a pair whose ratio falls between the two cutoffs is designated a possible match ^[3] and calls the middle band the no-decision or clerical review region ^[3]. Such pairwise methods treat pairs as independent of one another and so do not account for transitivity ^[2].

• Cluster. A cluster is the set of records the pipeline asserts to be one identity unit. Clustering is commonly a second step after pairwise linkage that resolves intransitivities and gives a coherent output ^[2]. Open-source documentation shows how literal this can be: Splink's clustering function groups pairwise predictions into connected records using the connected components algorithm ^[11], and with no threshold supplied, every compared edge is assumed to be a match ^[11]. Hassanzadeh et al. define the same approach as returning each connected component of the similarity graph as a cluster ^[4].

• Bridge record. A bridge record is, operationally, a record whose presence is the only thing joining two sub-groups of a cluster. The graph-theoretic bridge edge is, in Splink's documentation, an edge whose removal splits a cluster into two smaller clusters ^[12]; Tarjan's algorithm finds such edges, and the Leipzig graph-metrics repair work cites it ^[13]. The sparse bridge studied by Pavani et al. is different: a record with so few populated fields that nothing in it can disagree with either side. In their words, "a record with only one populated field has nothing to disagree with" ^[1].

A graph bridge is not automatically an error. Splink's documentation says bridges "can be signalers of false positives," especially when joining two highly connected sub-clusters ^[12], and that examining them can show problems in the linking process ^[12]. A legitimate sparse record may belong to one entity and bridge nothing wrong. The test therefore treats a graph bridge as a candidate for review and requires direct evidence for the endpoints.

• Why sparsity is the trigger. Most ER research targets dense data, as Petrovski and Bizer note when turning to sparse e-commerce data with many missing values ^[14]. Pavani et al. report that a single global threshold over-accepts sparse pairs. Their remedy learns thresholds per bin of shared populated fields, so that sparser pairs require higher confidence ^[1]. Missing values are also a configuration matter. One vendor's documentation says a null-involving comparison receives a default score of 0.5 ^[15] and advises setting the null score equal to the match threshold for optional columns ^[15]. Petrovski and Bizer report that lowering the evidence of uncertain pairings with missing values keeps borderline pairs from being matched, with improvements of up to 16% F-measure over hand-written rules ^[14]. "Missing" can thus be scored as mild similarity, neutral, or non-matching, depending on settings a reviewer may not see.

The Paper Example: A Three-Record Sparse Bridge

What the preprint shows

The preprint's smallest demonstration has three records, all named "Sakura Sushi." R1 has a Portland phone, street address and city and belongs to entity A. R2 carries only the name, with phone, address and city blank, and is the bridge, labeled as entity A. R3 has a Seattle phone, address and city and belongs to entity B. The matcher scores R1-R2 at 0.91 and R2-R3 at 0.88 and never scores R1-R3, so connected components merges the Portland and Seattle clusters ^[1]. The caption says the bridge lets connected components chain the two entities "without ever directly comparing R1 to R3" ^[1]. This is a paper example: the records and scores are the authors', and nothing here was reproduced by running their code.

The introduction uses a five-record version in which the bridge "has nothing in any populated field" that disagrees with either group, so the pipeline "chains the two correct-looking links together". Two details matter for anyone reproducing it. First, record identifiers differ between the two figures, and the bridge's true entity is unknown in the five-record figure but entity A in the three-record one. Second, the three-record pair table has an outcome column in which one cross-entity pair carries a label that reads as correct, although the pair joins entity A to entity B and the table's last row marks the resulting R1-R3 relation as a false positive. The authors do not explain the label. The likeliest reading is that it describes the mechanical outcome of connected components rather than correctness against ground truth, but the text cannot settle whether this is loose wording or an error. This report does not reproduce that label and relies only on the ground-truth entity assignments.

A synthetic table for practice (Hypothetical Example)

Table 1 below is a synthetic record set built for this report, not taken from any paper. It follows the same structure but adds a second sparse record so a reviewer can practice the perturbation test and compute the later metrics. Names, phone numbers and scores are invented. The "expected entity" column is the label a reviewer would adjudicate from an external document.

For this hypothetical exercise, add two above-threshold edges within the expected entities: S1-S2 and S4-S5. The complete undirected above-threshold edge list is S1-S3, S2-S3, S4-S3, S5-S3, S6-S4, S1-S2 and S4-S5; assume no other edges. Connected components over this graph returns one cluster of six records containing two expected entities. No pair between {S1, S2} and {S4, S5} was scored, and a direct S1-S4 comparison would show two populated phone numbers that differ. Table 1 separates three facts a reviewer must not conflate: the cluster holds two entities, the bridge S3 is itself labeled E1, and the failure is the cluster, not the record. Removing S3 leaves two components, {S1, S2} and {S4, S5, S6}, an increase of one. This partitions only the remaining records. To obtain the complete correct partition, reassign S3 to E1 using the hypothetical adjudicated label, yielding {S1, S2, S3} and {S4, S5, S6}. The next section turns that observation into a procedure.

Transitive closure and cluster evaluation

The risk is old. Hassanzadeh et al. noted that partitioning by transitive closure can put many dissimilar records together ^[4], found higher recall at the cost of precision ^[4], and concluded that it produces poor-quality groups ^{[4] [16]}. The Leipzig group's clustering comparison reached the same ranking: connected components "suffers from very poor precision" ^[17], because indirect matches may not be similar enough ^[17]. A survey by Christophides and co-authors says false positives make clusters "dominated" by non-matching descriptions. In a study of Scottish birth records, the connected component method gave the worst linkage quality of those compared ^[18]. The Leipzig repair papers state that transitive closure can propagate linkage errors into erroneous clusters ^[13].

Threshold choice interacts with this. Splink's guide shows records that form one cluster at a threshold of 0.95 and split into two at 0.99 ^[19], and says the choice of threshold can have a significant impact on the final linked data ^[19]. Dedupe's documentation states the same trade-off: lowering the threshold increases recall ^[20]. These are dataset-specific results, but they point the same way: transitive closure amplifies each false positive edge.

Black-Box Acceptance Questions and the Bridge-Removal Perturbation Test

An identity steward usually sees only exported output: cluster identifiers, member records, and perhaps pairwise scores. The four questions below are answerable from that output. They are this report's synthesis of the cited literature, not a published standard, and no study has validated them as a package.

Question 1: Are the endpoints directly supported?

For any candidate bridge, take one record from each side and ask whether the pipeline ever scored that pair. In the paper's example it did not. A missing score may reflect blocking, the step that limits which pairs are compared: Splink's documentation notes that blocking rules can prevent comparisons between some true matches ^[21], and a practitioner source adds that false negatives from blocking are silent and hard to detect ^[9]. A missing comparison is a gap, not a non-match. Verified merge closes the gap mechanically by scoring representatives of the two clusters directly, up to three per cluster ^[1]; a reviewer can run the same check by hand.

Question 2: Are contradictory attributes exposed?

Before applying this proposed checklist, declare the veto fields and contradiction rules for the chosen identity unit. For each designated field, specify normalization, a field-specific similarity floor and domain rules, source reliability, validity dates, and permitted multiple values. Compare normalized values in their temporal context; review changed, mistyped, differently formatted or multivalued phones and addresses before deciding that they contradict identity. Hold unresolved discrepancies and reject only verified contradictions under those declared rules. In the preprint, fields designated no_override encode unconditional business rules that "no learned model can bypass" ^[1]. Their asymmetry is that "a single piece of negative evidence is sufficient" to block a merge ^[1]. For the reviewer the question is whether the contradiction is visible in the output at all; a cluster that hides a differing phone number behind a high aggregate score has not exposed it. Treat a null as absence of evidence, never as agreement. Vendor documentation shows nulls can be scored as mild similarity by default ^[15], and another documented algorithm places a record with a null match score in its own cluster ^[15], so behavior differs by algorithm and setting.

Question 3: Does the cluster survive removal of the bridge?

This is the perturbation test. It needs only a way to recompute clusters over the exported edges.

1. Select candidates. For each cluster, list records with the fewest populated fields (for example, two or fewer) and graph bridge edges; unusually large clusters deserve the same scrutiny, since Splink's guide treats a cluster implying one individual appears hundreds of times as a sign of false positive links ^[12]. Splink's documentation shows a nine-node cluster splitting into clusters of five and four on removal of a bridge ^[12].
2. Remove one candidate at a time. Recompute clusters on the remaining records and edges with the same threshold and configuration.
3. Record the change. Count the resulting components and the records that change cluster-mates.
4. Adjudicate the split. If the sides carry different expected labels, the bridge was joining distinct entities. If they carry the same label, the bridge was legitimate.
5. Report the rate. Report the bridge-removal cluster change as the share of sampled clusters in which removing any single low-evidence record changes the membership of others, separately from the false-merge rate defined later.

On the complete hypothetical graph specified after Table 1, removing S3 changes one component into two: {S1, S2} and {S4, S5, S6}. The surviving sides have different adjudicated labels, E1 and E2, confirming a false merge. S3 remains labeled E1 and must be reassigned to the E1 component before claiming a complete correct partition.

A cluster joined by two sparse records in parallel survives removal of either, so repeat with pairs for large or flagged clusters. Edge betweenness, which the Leipzig repair work uses to rank suspicious edges ^[13], can help prioritize removals.

Question 4: Is a past decision reproducible?

Approval is a decision about a snapshot. A reviewer should be able to rerun the pipeline on the same inputs and configuration, obtain the same cluster, and say what changed since. Order dependence is a documented threat. Saeedi, Peukert and Rahm describe a naive incremental method as strongly dependent on insertion order ^[22] and tested all twelve orders of four sources ^[22]; a later paper cites that work for the finding that source order significantly affects resolution quality ^[13]. A reproducibility check therefore permutes the arrival order of sources and compares clusters.

For lineage, the W3C PROV data model supplies a vocabulary. It defines provenance as a record of the people, institutions, entities and activities involved in producing data ^[23], calls it crucial in deciding whether information is to be trusted ^[23], and defines a derivation as a transformation of an entity into another ^[23], linked to facilitate provenance-based reproducibility ^[23]. In practice the reviewer asks for each cluster's derivation chain: source records, match decisions, configuration version, and approving agent. Work on explaining ER decisions observed that none of the systems it surveyed explicitly explained their results ^[24] and that explanations are needed to build trust in the decision process ^[24]. A bundle, a named set of provenance descriptions that is itself an entity ^[23], is one way to record the provenance of the approval decision itself. Whether a pipeline can export the chain is an observable property to test before approval.

Comparing Connected Components, Center Assignment and Verified Merge

The Pavani et al. ablation compares three cluster constructions, and the wider literature adds a repair family. Table 2 below summarizes the output each produces on the bridge case, the evidence gap it leaves, and what the cited studies report. It describes alternatives evaluated by the papers and names no winner, because the papers support none.

The first three rows are the paper's arms; its clustering table reports Pair-F1, adjusted Rand index and pairwise precision per dataset. The paper's evidence for each method comes from the benchmark ablation, not from the three-record illustration. And verified merge changes which evidence exists in the output, since it generates direct pairwise scores that blocking may never have produced, which is useful to a reviewer irrespective of F1.

The repair row addresses a different problem. Saeedi et al. describe a light-weight approach to correct wrong entity clusters ^[10], and the group's earlier study notes that SplitMerge and CLIP both start from connected components and post-process them ^[25], and that CLIP can repair clusters produced by other schemes ^[25]. The same study found CLIP, SplitMerge and Split clearly superior to previously known schemes on match quality ^[25]. Repair complements acceptance testing: the test decides whether a cluster is safe now, and repair changes clusters afterward. A repaired cluster is a new snapshot that needs its own sign-off. The last row is included because the publisher offers a system of record, and its listed properties are the ones the acceptance questions test; it makes no performance claim and describes no mechanism.

Decision Worksheet: Accept, Hold Ambiguous or Reject

Table 3 below is a sign-off worksheet with one row per field. Each tested value should carry a citation to its source record, the source's observation date, and the reviewer's note. The structure maps to classical linkage: a confident link, a possible link sent to clerical review, and a non-link ^[2].

Each evidence row carries where the value came from and when it was observed: a phone number observed three years ago is weaker evidence against a merge than one observed last month, and the worksheet should expose that difference. The PROV concept of an agent, something that bears responsibility for an activity ^[23], is a template for the final row: the decision belongs to a named reviewer on a named date.

Suggested decision rules

These rules are a proposal to adapt, not a published standard.

• Accept when every candidate bridge has direct endpoint evidence above threshold, no verified contradiction under the declared veto rules or unresolved discrepancy remains, bridge removal changes membership only between records adjudicated to the same label, and the rerun reproduces the cluster.
• Hold ambiguous when a relevant discrepancy remains unresolved, when a bridge lacks direct endpoint evidence but no verified contradiction under the declared veto rules is found, or when the rerun differs under a source-order permutation. Show the cluster with its ambiguity and do not use it for decisions that treat it as one entity. One practitioner source says borderline scores need "a review workflow, confidence tiers, and a human-in-the-loop process" ^[9].
• Reject when a bridge has a verified contradiction under the declared veto fields and domain rules for the identity unit, or when bridge removal separates sides carrying different adjudicated labels. Raw phone or address inequality alone is insufficient; hold unresolved discrepancies.

A hold matters because a merge may be irreversible downstream ^[9].

Sampling High-Risk Clusters and Reporting False-Merge and False-Split Uncertainty

Testing every cluster by hand is rarely feasible, so sample.

Definitions

• The false-merge rate is the proportion of clusters in a stated frame that contain two or more distinct adjudicated entity labels.
• The false-split rate is the proportion of adjudicated entities in a stated frame whose records appear in two or more clusters. The two use different units, clusters and entities, so they need different frames.
• The bridge-removal cluster change rate is separate: the proportion of sampled clusters whose membership changes under single-record removal. A cluster can show change and no false merge.

Evaluation compares a result with a gold standard, an ER result assumed correct and often built by human experts ^[26]. Cluster-level definitions are used on purpose, since Nanayakkara and co-authors argue that traditional pairwise measures are not suitable for evaluating groups of linked records ^[18]. Menestrina, Whang and Garcia-Molina define a configurable merge distance that counts splits and merges, allowing splits to be penalized more than merges or the reverse ^[26], and show that pairwise precision and recall fit within it ^[26]. Because measures can disagree on which result is best ^[26], report more than one. These definitions follow the cited papers.

Frame and strata

State the sampling frame: the snapshot, the cluster size range, and the exclusions. Then stratify. A suggested high-risk stratum holds clusters with at least three records and at least one record with two or fewer populated fields, or at least one graph bridge; the low-risk stratum holds the rest. Sampling the low-risk stratum matters because it is usually far larger and, as the example shows, can hold more false merges in absolute terms.

Sampling clusters from a stated frame avoids a trap shown by Binette and co-authors: in a toy experiment true precision was 52% while naive estimates from benchmark clusters were usually near 100%. Do not reuse a training benchmark as the frame.

Worked example (Hypothetical Example)

Suppose a snapshot holds 16,000 multi-record clusters: 1,800 in a high-risk stratum and 14,200 in a low-risk stratum. A reviewer adjudicates 120 high-risk and 60 low-risk clusters against external documents. Nine of the 120 high-risk clusters carry two or more labels, a false-merge rate of 7.5% with a 95% Wilson interval of about 4.0% to 13.6%. One of the 60 low-risk clusters does, a rate of 1.7% with a Wilson interval of about 0.3% to 8.9%. Weighting by stratum size gives an overall estimate of 2.3%, with an approximate 95% interval of 0% to 5.2% from a normal approximation that is crude at these counts. At those rates the high-risk stratum would hold about 135 false merges and the low-risk stratum about 237, so the lower-rate stratum contributes more affected clusters. All numbers are invented.

The Wilson interval is the recommended default. NIST's handbook presents it for proportions and notes that, unlike the usual normal interval, its lower limit cannot be negative ^[6]. Brown, Cai and DasGupta show that the standard Wald interval has erratic coverage and recommend the Wilson or equal-tailed Jeffreys prior interval for small samples ^[27]. When no false merge is observed, do not report zero: if 0 of 100 sampled clusters carry two labels, the exact one-sided 95% upper bound is 1 minus 0.05 to the power of 1/100, about 3.0%. NIST describes an exact binomial-based method for very few failures ^[6].

False splits need an entity-level frame: sample adjudicated entities, not clusters, and count those whose records appear in several clusters. Because blocking can produce silent false splits, draw this reference sample independently of the pipeline's own candidate set, and record who labeled each cluster and from which documents.

Data Analysis and Evidence

This section lists the quantitative results the report relies on, with the scope of each. None is a benchmark for a reader's data.

Pavani et al. (2026), clustering ablation. Six public benchmarks, 864 to 5 M records, with Pair-F1 as the primary metric. As stated in the narrative:

• Geo Settlements: transitivity lowered F1 from 0.889 to 0.771; verification raised it to 0.972.
• MusicBrainz 200K and NCV: transitivity reduced F1 from 0.540 to 0.000 and from 0.667 to 0.002 ^[28]; the authors attribute this to common field values chaining unrelated records into mega-clusters.
• Verified merge limits: on MusicBrainz 200K it reached 0.277, well below the 0.540 baseline, and at matcher precision of 0.509 the authors say even the gates cannot save it ^[1].
• Dataset-specific cluster evaluation: Do not infer safe transitive closure from high baseline precision alone. Require dataset-specific cluster evaluation: on Geo Settlements, raw transitivity reduced F1 from 0.889 to 0.771 as geographically similar but distinct settlements were chained ^[1].
• Sparsity-aware thresholds: purity gains of 8.4 percentage points on MusicBrainz and 1.5 on NCV.

The authors' limitations: results are accuracy metrics on public data, not production outcomes such as business impact or drift robustness ^[1]; some findings depend on a 10,000-label budget; only point estimates are reported. Their statement that single low-evidence links repeatedly chained hundreds of records is anecdotal and gives no counts.

Earlier peer-reviewed and preprint evidence.

• Incremental repair (Saeedi et al., 2020): prior repair methods were limited to small single-source datasets ^[22]. On the 10-million-record person dataset ^[22], the authors link batch clustering's lower precision to chaining entities up to the maximum possible cluster size of 10 ^[22]; in the tenth increment batch clustering took five times as long as one-depth reclustering ^[22]; under the worst source order the non-repairing method had substantially lower recall ^[22]. The abstract reports no numeric F-measure; results are in figures.
• Graph-metric repair (Christen et al., 2025): CLIP's F1 ranges from 0.1 to 0.9 depending on how dirty the dataset is ^[13]; LLM-based labeling oracles had accuracy of 0.56 to 0.73 on one dataset ^[13]; randomizing half the edge similarities changed F1 by up to 10% on MusicBrainz ^[13].
• Measure disagreement (Menestrina et al., 2010): in simulation, the probability that two measures conflict on ranking averaged 21.6%, 9.1% and 10.7% across three plots ^[26], so measure conflicts are not trivial ^[26].

Two gaps stand out. No source found measures how often sparse bridges cause false merges in operational data. And no peer-reviewed study of the sparse-bridge mechanism specifically was found; the preprint is a single source for that framing, supported by older peer-reviewed work on transitive closure in general. Only a reader's own sampling yields a local rate.

Implications and Future Directions

For approval workflows, the shift is from asking "is the matcher accurate?" to asking "what evidence supports each link in this cluster, and what happens if the weakest link is removed?" The perturbation test and worksheet answer the second question.

For system design, the properties a reviewer should ask of any canonical-record system follow from the tests: duplicates that resolve by stated rule rather than silent chaining, ambiguity shown rather than hidden, related entities related rather than merged, and a verbatim source and observation date behind every value. These are the publisher's stated guarantees for its own system of record and are testable in exported output; this report makes no claim about how any system achieves them, and none about performance. A reader who needs blocking, matching-model training or master data management should use a tool built for that, and apply the acceptance test on top of it.

For research, two directions follow. Prevalence: measuring how often a cluster's connectivity depends on one low-evidence record would show whether the failure is rare or common. Explanation: ER users get matching output without enough explanation of why records match ^[24], so a standard bridge-evidence export would help.

Frequently Asked Questions (FAQs)

What is a bridge record in entity resolution?

A record whose presence is the only thing joining two sub-groups of a cluster. The sparse variety has few populated fields and so matches both groups without contradicting either.

Why does transitive closure over-merge?

Because every above-threshold edge is treated as true and chained, so one borderline edge can join unrelated clusters. Earlier evaluations found the same precision loss ^[4].

How do you prevent false positive merges in record linkage?

The cited literature offers hard vetoes on identifier fields, thresholds that rise as shared populated fields fall, direct verification of cluster pairs before merging, and a clerical-review band for borderline pairs ^[3]. None replaces testing the output, since verified merge is a safety net rather than a cure.

How do you validate an entity resolution cluster?

Run the four acceptance questions, the bridge-removal test and the worksheet, then estimate error with an adjudicated stratified sample of clusters and a stated frame, reporting the false-merge rate with a Wilson interval.

How do sparse records affect entity matching?

A record with a single populated field has nothing to disagree with, so global thresholds over-accept sparse pairs. Null handling is configurable in some tools ^[15], so confirm how missing values are scored.

What errors does connected components clustering produce?

Mostly over-merging: higher recall with poor precision ^[17], and clusters dominated by non-matches when false positives are common.

What lineage and auditability should an ER output carry?

For each cluster: members with source and observation date, the decision path, the configuration version, and the approving agent. The W3C PROV model defines these concepts ^[23], and PROV-O expresses them as a lightweight ontology ^[29].

Conclusion

A sparse bridge record is a cluster-level failure that pair-level accuracy does not reveal. The Pavani et al. example shows it in three records: two above-threshold links, no direct comparison of the endpoints, and a cluster joining two real entities. The older literature on transitive closure supports the direction, and no source quantifies how often the pattern occurs in practice.

The acceptance test asks four things of any cluster: whether the endpoints of each candidate bridge are directly supported, whether contradictory attributes are exposed, whether the cluster survives bridge removal, and whether the decision can be reproduced. The worksheet records the evidence, its source and observation date, and ends in accept, hold ambiguous or reject. Sampling converts individual verdicts into a false-merge rate with a stated frame and a Wilson interval, alongside a separately reported bridge-removal change rate.

The compared methods produce no universal winner. Connected components is best on some datasets and ruinous on others, center assignment under-merges, and verified merge helps when the matcher is reasonably precise and cannot rescue it when it is not. The reviewer's task is to test the output in front of them. The protocol is a synthesis, not a validated standard, and its first use on a reader's own data is the first measurement of whether the failure matters there.