Skip to main content

#655 option 2 — a cross-source weak-label scorer has no non-circular anchor (the gate is blocked)

Feasibility analysis, not a measurement. #655 option 2 proposes a learned cross-source link scorer trained on a weak-labelcomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. pipelinestaged pipelineMailwoman's runtime architecture: a sequence of pure-function stages (normalize → query-shape → locale-gate → kind-classifier → phrase-grouper → classifier → decoder) connected by typed handoffs. Each stage is published as its own npm package.. Before building it, we check the gate it was explicitly conditioned on — "can we build cross-source weak labelscomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag.?" — and find we cannot, for a structural reason in the data. This documents why, so the idea isn't re-tread without a new data source.

The question

The dedup (within-NPPES) matcher has a learned scorer (the GBTGBT (Gradient Boosted Trees). A non-linear machine learning model that combines many weak decision trees into a strong predictor. Mailwoman uses a GBT as an optional learned scorer for single-dataset dedup, improving F1 by 5–7 percentage points over the Fellegi-Sunter baseline., #603) because it has clean ground truth: the NPI groups records, so labelscomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. are free. Cross-source matching (NPPES ↔ FCC RHC ↔ TX HHSC) has no such key — that is the whole difficulty, and the reason FS is pinned for cross-source by design (#664 showed a re-thresholded GBTGBT (Gradient Boosted Trees). A non-linear machine learning model that combines many weak decision trees into a strong predictor. Mailwoman uses a GBT as an optional learned scorer for single-dataset dedup, improving F1 by 5–7 percentage points over the Fellegi-Sunter baseline. can't beat it there). Option 2 asks: could a weak-labelcomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. pipelinestaged pipelineMailwoman's runtime architecture: a sequence of pure-function stages (normalize → query-shape → locale-gate → kind-classifier → phrase-grouper → classifier → decoder) connected by typed handoffs. Each stage is published as its own npm package. manufacture enough signal to train a cross-source scorer anyway?

A weak-labelcomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. pipelinestaged pipelineMailwoman's runtime architecture: a sequence of pure-function stages (normalize → query-shape → locale-gate → kind-classifier → phrase-grouper → classifier → decoder) connected by typed handoffs. Each stage is published as its own npm package. is only useful if the labelscomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. come from a signal independent of the featuresfeatureAn input signal a model conditions on. Beyond the raw tokens, Mailwoman feeds soft features — gazetteer-membership channels and the postcode anchor — that inform predictions without overriding them. the scorer will use. Otherwise it is circular — the scorer just learns to imitate whatever produced the labelscomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag..

What the sources actually share

Inspecting the raw headers of every source in the matcher's catalog:

sourcerows' identity keyshares a clean strong ID?
NPPES registryNPI (+ EIN, taxonomy)
FCC RHC posted-services (71 cols)FCC HCP numberno NPI / EIN / TIN / tax-ID field
FCC RHC commitments (53 cols)Participating HCP numberno NPI / EIN / TIN / tax-ID field
TX HHSC nursing facilities (43 cols)TX license numberno NPI / EIN / TIN / tax-ID field

NPPES is the only source carrying a clean strong identifier (NPI, EIN). The FCC and TX sources key on their own program-internal IDs and carry no crosswalk back to NPI/EIN. The fields shared across all sources reduce to: organization name, address / geocode, and phone.

Why each candidate weak-label source fails

  • Name + address/geocode — these are precisely the featuresfeatureAn input signal a model conditions on. Beyond the raw tokens, Mailwoman feeds soft features — gazetteer-membership channels and the postcode anchor — that inform predictions without overriding them. the Fellegi-SunterFellegi-SunterA probabilistic record linkage model that computes match probability from agreement-level log-likelihood ratios: log₂(m/u) where m is the probability of agreement given a true match and u is the probability of agreement by chance. Mailwoman learns m and u label-free via expectation-maximization. scorer already uses. Weak labelscomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. drawn from agreement on them, fed to a scorer over the same featuresfeatureAn input signal a model conditions on. Beyond the raw tokens, Mailwoman feeds soft features — gazetteer-membership channels and the postcode anchor — that inform predictions without overriding them., is circular: the modelneural classifierThe machine learning model at the core of Mailwoman's parser — a transformer encoder (~30M parameters) trained from scratch to do BIO token classification over addresses. It learns the 'grammar' of address formats; the gazetteer supplies the 'atlas.' learns to reproduce FS. This is the mechanism behind #664's result — the GBTGBT (Gradient Boosted Trees). A non-linear machine learning model that combines many weak decision trees into a strong predictor. Mailwoman uses a GBT as an optional learned scorer for single-dataset dedup, improving F1 by 5–7 percentage points over the Fellegi-Sunter baseline., re-thresholded over the FS featurefeatureAn input signal a model conditions on. Beyond the raw tokens, Mailwoman feeds soft features — gazetteer-membership channels and the postcode anchor — that inform predictions without overriding them. vector, has nothing independent to add cross-source.
  • Phone — shared across all sources, and the one candidate independent signal. But #625 established NPPES phone is an unreliable secondary identifier: institutional switchboard lines are shared by many distinct providers, so phone agreement over-links. A scorer trained on phone-anchored weak labelscomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. would learn to over-link on the switchboard noise — worse than FS, not better.
  • An external crosswalk (an NPI↔HCP or EIN↔license table) — would give clean labelscomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag., but none exists in the data we hold, and sourcing one is a data-acquisition task, not a modeling one.

Conclusion

The gate #655 option 2 was conditioned on does not open with the current data. There is no cross-source signal that is both strong enough to labelcomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. and independent of the featuresfeatureAn input signal a model conditions on. Beyond the raw tokens, Mailwoman feeds soft features — gazetteer-membership channels and the postcode anchor — that inform predictions without overriding them. a scorer would use. So FS stays pinned for cross-source — that is a property of the data (no shared clean key), not a modeling shortfall. The honest move is to record this rather than run a circular experiment that would post a misleadingly-positive number.

What would change the answer: a new source carrying a shared strong identifier (an NPI or EIN that also appears in the FCC/TX records, or a published crosswalk). With that, the weak-labelcomponent tagOne of the 33 labels in Mailwoman's address schema — street, locality, region, postcode, house_number, unit, po_box, country, venue, intersection, and others. Each parsed span carries exactly one component tag. pipelinestaged pipelineMailwoman's runtime architecture: a sequence of pure-function stages (normalize → query-shape → locale-gate → kind-classifier → phrase-grouper → classifier → decoder) connected by typed handoffs. Each stage is published as its own npm package. becomes viable — train a geocode+name scorer to predict the strong-ID matches, then apply it to the records that lack the strong ID. Until such a source exists, option 2 is blocked. Recommend closing #655 with this finding (option 1 was answered by #664; option 2 is data-blocked).

Neutral entity-resolution framing: this is about whether two records denote the same organization, nothing about what that resolution implies.