Same building. Different company. Now what?

Suppose you have a set of records and no key to join them on. A clinic appears in the federal provider registry, again in a state licensing export, and a third time in a funding-program spreadsheet that someone typed by hand. The files share no identifier. The provider number is internal to one publisher, and the facility ID is internal to another. You must judge which records describe the same place for each pair, repeated a few million times.

The market offers two kinds of tools for this. Each solves part of the problem, and neither solves all of it.

The two tools, and the halves they skip

The first tool is a string matcher, such as Splink, Zingg, dedupe, or the fuzzy-match component inside Tamr or Tilores. You give it name and address columns, and it scores how similar the text is. Used as the whole answer, it has a basic flaw: text similarity does not measure place similarity. An address two doors down the same street is one character away. The same building written two different ways can score far apart. Threshold tuning then takes weeks, and a threshold that is too loose in cities is too tight in suburbs. (We covered this in detail in Match where it is rather than how it's spelled. In short, Jyllandsgade 15 and Jyllandsgade 75 score 0.96 similar and sit 650 meters apart, and no threshold handles that.)

Strings are still useful. Names are some of the best evidence available, and later sections argue for relying on them heavily. The limitation is narrower: a string describes how a record is spelled and makes no statement about where it is, so it should not be the field you block on.

The second tool is a join key, such as Placekey, SmartyKey, or our own @mailwoman/address-id. It normalizes the address, geocodes it, and returns a deterministic identifier. Records with the same key are at the same place. This is better than string matching, because it keys on where instead of on spelling. Placekey will tell you that two records are in the same building.

The key does not go further than that, and matching the building solves only the easy eighty percent.

A key gets you to the doormat

Key vendors say little about the remaining cases. At 1504 Taub Loop in Houston, four separate provider registrations resolve to the same rooftop, and all four are Baylor College of Medicine, one organization registered four times. A deterministic key groups them together, and that grouping is correct. At the next address, a single medical-office building holds a dozen distinct practices with different owners and specialties that share only the street address. The key groups them together too, and that grouping is wrong. The key cannot distinguish the two cases, because it encodes only location.

Placekey's own FAQ states that it "operates as a universal join key rather than a matching service… it doesn't perform record linkage itself." That is an accurate description of what a key does. The key finds records in the same building. The remaining question is whether records in the same building, with different company names, are one entity or two.

A probability answers that question.

The missing half: a number you can read, and the humility to abstain

Mailwoman is built around this second step. It first resolves every record to a coordinate and a place hierarchy and blocks on where. It then runs a probabilistic scorer over the candidates that share a place. The scorer is Fellegi-Sunter. Every field agreement or disagreement contributes a weight in bits, and the sum gives a calibrated probability that two records are the same entity, with the evidence shown so you can see why. A shared rare street counts for more than a shared common one. A shared rooftop counts for more than a shared interpolated point, because the geocoder reports its confidence to the matcher. The score also includes the string comparison: Jaro-Winkler over the names, where agreement on a rare organization-name token counts heavily and a shared LLC counts for very little. Names still matter, but they now decide who and no longer decide where. That role suits them better. When the probability falls in the uncertain middle, the matcher abstains and routes the pair to a human reviewer.

In summary: Placekey tells you two records are in the same building. Mailwoman tells you, with a calibrated probability and a readable reason, whether they're the same company, and flags the pair for review when it should not guess. That covers the linking step the key vendors omit and the geography the string-only matchers omit, and it keeps name matching in the model.

When the string is the answer, normalize it first

Sometimes the name decides the match. A comparison of the federal provider registry with the FCC's funding records shows one such case. The same health system appears in one file as BAYLOR COLLEGE OF MEDICINE and in the other as Baylor Coll. of Medicine, as a d/b/a, or with a , LLC that the other publisher dropped. Geography places the two records in the same area, so they are plausibly the same place. The name decides whether they are the same entity, provided it is normalized before comparison.

Normalization therefore runs first. canonicalizeOrganizationName strips legal-form terms (LLC, Inc, a leading The), splits the d/b/a, normalizes punctuation, and uses the ISO 20275 entity-form list so that Coll and College compare as the same word. Then the names are compared, and agreement on the rare token Baylor counts for much more than a shared Medical Center. The same mechanism handles both directions. The building with a dozen distinct practices stays a dozen entities, because they share a coordinate but have different normalized names. One facility registered twice under different operational names merges into one. The coordinate does the blocking, and the normalized name comparison decides the match. Neither step by itself reconciles NPPES and the FCC data. Together they do.

The matcher does not need labels

Most ML-based matchers also assume you have training data. Zingg asks you to label thirty to fifty pairs to start, dedupe runs an active-learning loop built on labeling, and Tamr expects ongoing human curation. The input may consist of CSV files and a deadline, without labeled pairs.

Mailwoman's scorer estimates its parameters from the data without labels, using expectation-maximization. Splink uses the same label-free Fellegi-Sunter method, and it runs at a scale we have not matched. The difference is that Splink expects you to have already geocoded the addresses, while Mailwoman covers the whole stack from raw string to resolved place to calibrated link. When you do have labels, an optional gradient-boosted scorer captures non-linear interactions that the hand-built weights miss. In our held-out tests it added about six points of pairwise F1 and five of clustering F1, across every random seed we tried.

It travels

A learned scorer may memorize one dataset's quirks. To test that, we trained the boosted scorer on Texas providers and evaluated it on held-out states it had never seen. It beat the unsupervised baseline by 20.5 points of F1 on California and 21.9 on New York. The pattern it learns, what over-merging looks like, transfers beyond Texas.

Show your ruler

A result such as "F1 of 68%" is meaningless until you state what it was measured against. The same clusters score from 53.6% to 68.1% against four different definitions of truth. The clusters did not change. Only the ground truth changed, as it defined one entity more precisely. We hand-adjudicated 120 of the hardest Texas pairs (co-located, with similar names and distinct IDs). All 120 were the same real-world organization under different registrations, and none were unrelated companies merged by mistake. We report the ground truth next to the number. Most vendors do not.

Own it, and what it doesn't do

It runs on your machine. It is open source, runs on your infrastructure, and has no per-record charge. The alternatives include AWS at $0.25 per thousand records (billed on non-matches as well), Senzing starting around $58k a year, and Tamr, Quantexa, and Tilores. Those three all require a quote. This can meet data-control requirements in compliance and healthcare workflows.

The claims above depend on stating these limits. Placekey does implement place-identity matching. Angle four is our response, but the overlap is real. Melissa ships patented coordinate-proximity matching, so it would be false to say no one else uses coordinates. Our narrower claim is that we make the calibrated coordinate the primary evidence in a probabilistic model. Splink offers the label-free baseline at much larger scale. The enterprise incumbents lead on raw volume, multi-domain mastering, support, and decades of name-matching expertise. None of them combines an open, label-free, geocode-first approach with the geocoder and the linker in one auditable stack. That combination is what distinguishes Mailwoman.

Every match the matcher surfaces is a candidate for review, and the final decision is yours. You decide what a correlation means and whether it means anything.

npm install @mailwoman/registry

import { resolveEntities, toMapHTML } from "@mailwoman/registry"

const entities = await resolveEntities(records, {/* sensible defaults */})
// → clustered entities, each with a coordinate, a cohesion score, and the records it merged

resolveEntities runs the whole block → score → cluster pipeline; toMapHTML drops the result on a map so you can see, dataset by dataset, what linked to what.