Blocking is a budget problem

The 3 × 2 matrix, closed

Full-protocol v2 runs, 2026-10-20/21. E1 and E2 use different test splits, hence two Cora baselines.

Cora · E2 marginal allocation — the effect, decomposed

E2 replaces the uniform per-record budget with a learned allocation: records whose next neighbours are still likely to be true matches receive more pairs; records that have run dry receive fewer. Two calibration variants — A (Platt-calibrated model fitted on labelled train pairs) and B (an unlabeled mixture model of the similarity profile) — land on exactly the same test result.

A gain of dPC +0.3227 on fewer pairs (−1.5%). The permutation test then splits the credit. Shuffling who gets the budget — keeping the multiset of per-record budgets fixed — still buys ≈ +0.170: that half is generic pool mechanics (any reallocation beats the rigid grid). The observed allocation adds a further ≈ +0.15 on top, and that increment is what the test certifies: it beat all 199 permutations (variant A null mean +0.1704, sd 0.0156; variant B +0.1697, sd 0.0154).

Cora · E1 collective blocking — a bigger headline, a rejected explanation

E1 allocates the budget by community: Leiden communities on the similarity graph receive budget shares, on the theory that dense regions hide more duplicates. At an exactly aligned budget (24,267 pairs, deviation +0.00%) the headline is even larger than E2's — and the permutation test refuses to certify it.

D10K & MusicBrainz-20K — where the effect cannot live

On the two larger datasets the fixed-k baseline is already at (D10K) or near (MusicBrainz) the ceiling, and every kill line fires as pre-registered. Reallocation can only swap away pairs the baseline already holds. These are not failures of the experiments; they are the measurements that bound the claim.

One nuance survives the ceiling. MusicBrainz E2-A is dead against fixed-k (−0.0010), yet its permutation null sits at −0.0060 (sd 0.0012): the learned allocation is significantly less bad than random reallocation (p = 0.005). The ordering learned > random holds on both Cora and MusicBrainz — what flips sign across datasets is the headroom, not the quality of the allocation. Variant B shows no such signal (p = 0.93).

Related methods under the same ruler (2026-10-22)

A claim about allocation invites an obvious question: how do the classic methods do under the same protocol — same split, same pool, same budget? We re-ran five of them: global top-B (the whole pool ranked by cosine — the degenerate allocation with no per-record structure), adaptive-k (each record keeps neighbours within a relative threshold of its own best cosine, α tuned on train), meta-blocking (token blocks with block purging; edges weighted by common-block count or Jaccard, plus weight-based neighbourhood pruning), sorted neighborhood (one lexicographic key, sliding window), and canopy (two-threshold greedy clustering). This comparison is descriptive — no permutation tests were run for these methods.

The uncomfortable result first: on Cora, plain global ranking beats our calibrated waterfill by +0.0135, and adaptive-k sits between them. We therefore withdraw the claim that calibrated marginal allocation is the best allocator. What survives is the framework — spending the budget by global score gains +0.32 to +0.34 over the fixed-k grid — plus the scope law below and E2's permutation attribution, which compared waterfill against shuffled budget profiles and is untouched by this run. (Global top-B's +0.34 is a headline number; nobody has decomposed it.)

• Meta-blocking never wins at equal budget — on any of the three datasets. On Cora its token graph holds only 15,009 edges, fewer than the budget itself: sparse bibliographic tokens are a poor fit for token blocking.
• Sorted neighborhood is uniformly weak, and collapses on MusicBrainz (0.2075): one lexicographic key cannot group music-metadata duplicates.
• Canopy is the efficiency side-finding. At equal budget it changes no verdict, but on near-duplicate data it needs a fraction of the pairs: PC 1.0000 on D10K with 5,668 pairs — 14% of the budget.
• On MusicBrainz the plain fixed-k baseline beats every alternative on the table — the scope law from the other side.

Reproduce these runs in R

Every number on this page comes from four R scripts run against a source checkout of the ERBOT package. The scripts are the protocol — there is no hidden step. If a re-run disagrees with the archived numbers, the disagreement is in the data files or the package state, and step 5 below is how you catch it.

1 · Environment

R ≥ 4.1 (the archived runs used R 4.3/4.4). Install the package dependencies once:

install.packages(c("pkgload", "data.table", "dplyr", "tibble", "stringr",
                   "stringi", "tidyr", "purrr", "readr", "readxl",
                   "text2vec", "Matrix", "irlba", "stringdist", "igraph",
                   "FNN", "cluster", "gridExtra", "scales", "magrittr",
                   "jsonlite"))

2 · The scripts

Download the four scripts and place them in experiments/ at the package root. Each loads the package from the working tree (pkgload::load_all), so always run Rscript from the package root. The dataset is the first argument (default cora).

• exp-e1-collective-blocking-v2.R — E1 collective blocking + community-label permutation
• exp-e2-waterfill-v2.R — E2 marginal allocation (variants A/B) + allocation-profile permutation
• exp-related-baselines-v1.R — the related-methods comparison above (global top-B, adaptive-k, meta-blocking, sorted neighborhood, canopy)
• build-musicbrainz20k.R — one-time MusicBrainz-20K sample builder

3 · Data placement

inst/extdata/cora.csv            inst/extdata/cora_gold.csv   # bundled with the working tree
data/10Kfull.csv                 data/10Kduplicates.csv       # D10K — source on the Datasets page
data/raw/musicbrainz-20000-A01.csv.zip                        # MusicBrainz — Leipzig download

Build the MusicBrainz-20K sample once (whole-cluster sampling, seed 20261020; writes data/musicbrainz20k.csv and its gold file; check the printed fingerprint — 20,000 records / 10,294 entities / 16,934 matched pairs):

Rscript experiments/build-musicbrainz20k.R id CID 20000

4 · Run

Rscript experiments/exp-e1-collective-blocking-v2.R cora
Rscript experiments/exp-e2-waterfill-v2.R cora
Rscript experiments/exp-related-baselines-v1.R cora

Rscript experiments/exp-e1-collective-blocking-v2.R d10k
Rscript experiments/exp-e2-waterfill-v2.R d10k
Rscript experiments/exp-related-baselines-v1.R d10k

Rscript experiments/exp-e1-collective-blocking-v2.R musicbrainz20k
Rscript experiments/exp-e2-waterfill-v2.R musicbrainz20k
Rscript experiments/exp-related-baselines-v1.R musicbrainz20k

Cora finishes in minutes. The E1/E2 permutation sections (R = 199) on D10K and MusicBrainz are hour-scale — run them in one sitting, on a machine that will not sleep. The related-baselines script has no permutation section, and it can also run without the package installed: it carries local replicas of the three package functions it needs (standalone mode; data.table, Matrix and tibble suffice).

5 · Check against the archive

The E2 Cora run must open with these lines (the same numbers the related-baselines script prints as its self-check). If your baseline differs, stop — your data or package state differs from the archived runs, and later numbers are not comparable.

baseline (fixed-k):   20,898 pairs · PC 0.5865
waterfill A / B:      20,575 pairs · PC 0.9092
permutation (R=199):  null +0.170 ± 0.016 · observed +0.3227 · p = 0.005

State note: the scripts were run on 2026-10-20–22 against the ERBOT working tree; they also live in the public package repository (xinminchu/erbot · experiments/), which was unified on 2026-10-22 to the working-tree state that produced these results. The D10K and MusicBrainz data files are not redistributed here — their sources are on the Datasets page.