The Record-Match Verdict: Auto-Merge, Review, or Keep Separate

You have two records that might be the same person or the same company. They came from different sources, some fields agree and some do not, and you have to decide: merge them now, send them to a reviewer, or leave them apart. This guide gives recruiting-ops, revenue-ops, and anyone answerable for the data a repeatable way to turn one candidate pair into a documented verdict. It weights signals by how much they actually discriminate, treats GitHub, LinkedIn, and open-web identifiers differently, and sets the thresholds by how reversible a wrong merge is, so two operators looking at the same pair reach the same answer.

It covers people and companies in one rubric, because the hardest part is the same for both: a score alone does not tell you what to do with it. The band does, and the band is a judgement about risk.

What the verdict actually is: three bands, not one cutoff

The verdict is an assignment of a candidate pair to one of three bands: auto-merge, human review, or keep-separate. The three-band model is near-universal across entity-resolution tools; what differs is where the lines fall.

The instinct to pick a single "match score" and merge above it is the mistake this guide exists to correct. A score is a continuous number from 0 to 1. A verdict is a discrete action with consequences, and the two mid-band actions - route to a reviewer, or do nothing - exist precisely because the score in the middle is not trustworthy enough to act on alone. In published practice, confident matches are auto-merged, ambiguous ones are queued for human review at configurable thresholds, and the rest stay apart.

Here is how several published configurations draw the lines. Read this as a range, not a recommendation to copy.

The single most important fact in that table is the gap between the general norm and financial services: the auto-merge cutoff jumps from above 0.90 to 0.98, a difference of roughly 0.08. Nothing about the matching algorithm changed. The domain changed, and with it the cost of a wrong merge. That gap is the whole argument of this guide, so hold on to it.

Score by discriminating power, not by field count

A confidence score is only as good as its weights, and the right weight for a field is how much that field narrows the set of possible entities. A verified personal email identifies almost exactly one person; a shared surname identifies thousands.

Build the score by resolving deterministic keys first and fuzzy signals second. Deterministic matching on strong identifiers is fast and precise - it delivers 80 to 90% accuracy with few false positives, and in well-maintained databases precision can reach 99.9%. You settle those matches before you ever compute a fuzzy score, because no amount of string similarity should override or second-guess a verified unique ID.

What counts as a strong identifier depends on the entity type, and this is where the two cases diverge.

Person records

For a person, a verified personal email is the strong key. On LinkedIn and the open web that is usually a confirmed contact email. On GitHub it is subtler: attribution links a commit to a user by matching the email in the commit header to an email on a GitHub account. So the strong signal lives in commit metadata, not the profile. Only about 15% of GitHub users expose a public profile email, which means a finder that reads only profiles fails on four out of five developers. Read the commit-header email, confirm it belongs to a verified personal account, and you have a key worth auto-merging on.

Company records

For a company, the obvious proprietary key is weaker than its reputation. DUNS identifies a business location, not a company, so a firm with 40 offices carries 40 DUNS numbers, and matching on it fragments one company into many records. The strong company keys are legal-entity identifiers: an EIN confirms the legal tax entity issued by the IRS, and an LEI identifies the entity in global financial markets, issued by GLEIF. Weight those high and treat a shared DUNS as a weak, review-band signal rather than a merge trigger.

Once deterministic keys are exhausted, the remaining fields get field-appropriate similarity measures.

Pick the similarity measure the field was made for

Match the algorithm to the field: Jaro-Winkler for names and addresses, Levenshtein for codes and IDs. Using the wrong one is a quiet source of both missed matches and false merges.

Jaro similarity was built by Matthew Jaro in 1989 for US Census record linkage to compare short strings like names and addresses, and Jaro-Winkler is the go-to metric for name matching, address comparison, and customer-record deduplication. It handles the errors humans actually make in names - transpositions and dropped letters. Levenshtein, which counts single-character edits (the distance from "kitten" to "sitting" is 3), suits short structured codes where every character is load-bearing.

The difference is not academic. These are published scores on near-match pairs.

On the transposition Martha versus Marhta, Jaro-Winkler reads about 0.961 while normalised Levenshtein reads 0.667 - a gap of roughly 0.29 on a pair any human reads as the same name. Pick Levenshtein for that field and you would route a true match to review or worse. The general guidance that a score above 0.85 indicates a strong match only holds when the measure fits the field.

There is a hard ceiling here that no weighting fixes: high string similarity is not identity. Zhen and Zheng are different surnames that still earn a high Jaro-Winkler score. A name score alone, however high, can never clear the auto-merge band. It needs a second corroborating field - a matching employer, a shared verified email, a co-located commit. Build that rule into the score so a lone name match is capped below your auto-merge cutoff.

Finding people who already carry two corroborating identifiers is exactly the friction the scoring step describes, and asking Refolk in plain English returns them with the commit email and the second profile attached, so the pair arrives pre-corroborated rather than stuck in the review band.

Set the bands by reversibility, not by habit

The cutoffs are a risk decision, not a modelling one: set the auto-merge threshold by the cost of a wrong merge, and tighten it the harder that error is to undo. This is why the same algorithm auto-merges at 0.90 for a product catalog and at 0.98 for financial compliance.

The mechanism is precision versus recall. When wrongly merging is dangerous - medical records, financial compliance, fraud - you favour precision, optimise toward F0.5, require high confidence, and route more edge cases to human reviewers even at the cost of throughput. When missing a match is the worse error - broad customer dedup, fraud sweeps - you favour recall and optimise toward F2, loosening the cutoff to catch more true pairs.

Reversibility is the single variable that ties this to your own situation. Ask one question of every merge: if this is wrong, can I cleanly undo it? If un-merge restores the prior state in one operation, you can afford a lower auto-merge cutoff. If a wrong merge silently poisons downstream outreach, billing, or a compliance record, raise the cutoff and send more to review.

The published numbers in this guide - 0.90, 0.92, 0.98 - are landmarks that tell you the shape of the range and which direction reversibility pushes you. They are not your answer. Your answer comes from a labeled sample you scored and checked by hand.

Run the verdict: the procedure for one pair

This is the procedure for a single candidate pair, start to finish. At scale the first four steps automate; the judgement lives in steps five through eight.

A scoring rubric is easier to apply the same way twice if it is written down. This is a skeleton two operators can share.

ENTITY TYPE: person | company
DETERMINISTIC KEYS (any exact match -> auto-merge, skip scoring):
  person: verified personal email, verified commit-header email
  company: EIN, LEI
FUZZY FIELDS (weight by discriminating power):
  name          weight ___  measure: Jaro-Winkler   score ___
  employer/org  weight ___  measure: exact/JW       score ___
  location      weight ___  measure: Jaro-Winkler   score ___
  code/id       weight ___  measure: Levenshtein    score ___
RULES:
  - name-only match caps below auto-merge cutoff
  - empty field vs empty field scores 0, not 1
WEIGHTED SCORE: ___
BANDS (reversibility-set): auto >= ___ | review ___ to ___ | keep < ___
VERDICT: ___   REASON CODE: ___   REVIEWER: ___

How the verdict goes wrong

Most bad merges are not scoring bugs; they are confident scores on the wrong signal. These are the failure modes that produce a high number and a wrong answer, with the check that catches each.

• DUNS-as-company-key false positive. Two records sharing a DUNS look confident, but DUNS identifies a location, not a company, so the match can fragment or over-merge accounts. Check: compare a legal-entity identifier - EIN or LEI - not DUNS alone.
• Shared or role email auto-merge. An info@ address or a GitHub noreply address passes an exact-email rule while linking different people. Check: confirm the email is a verified personal account before auto-merging.
• High name similarity, different entity. Zhen and Zheng are different surnames that score high on Jaro-Winkler. Check: require a second corroborating field; a name score alone never clears auto-merge.
• Empty-field inflation. Two blank fields can score as highly similar and inflate the total. Check: add missing-field indicators so two empty strings are not classified as a match.
• Exact-key complacency. Deterministic matching against inconsistent data misses real duplicates outright, since a single typo or formatting difference breaks the match. Check: measure your missed-match rate against a labeled sample.
• Untuned probabilistic over-merge. Probabilistic matching without properly tuned thresholds merges two different people into one record. Check: validate thresholds on your own labeled data, not a borrowed figure.
• Irreversible merge with no lineage. Without retained history, an un-merge cannot restore the prior state. Check: confirm the fields compared, the score, and the source are persisted before allowing auto-merge.

The miss rate is measurable, and it is asymmetric. In a study of paediatric intensive-care data the patient identifier showed a false match rate of 0.2% against a missed match rate of 4.1% - exact keys bought precision but silently lost roughly one in 24 true matches.

That asymmetry is why you layer fuzzy signals on top of deterministic keys: approximate string comparators increase deterministic linkage sensitivity by up to 10% compared to exact matching. The exact key protects precision; the fuzzy layer recovers the matches it missed.

A confident score on the wrong signal is more dangerous than a low score on the right one. </pull>

Who does this work, and where the talent sits

Entity resolution is a named, countable skill, and the pool is concentrated. In Refolk's index of professional profiles, 194 US professionals name Entity Resolution as a skill, against 55 in the UK - the US pool is roughly 3.5 times larger. A related 138 US professionals name Record Linkage, about 71% the size of the US Entity Resolution pool.

The concentration matters when you need to hire or consult on a pipeline like this. Among UK Entity Resolution profiles, one vendor, Quantexa, is the single largest employer, accounting for 9 of the sampled profiles. If you are building or auditing a dedupe pipeline and need someone who has set reversibility-calibrated thresholds before, the pool is small and clustered, so naming the specific experience - Splink, survivorship pipelines, financial-crime matching - narrows it fast. Asking Refolk in plain English for people with record-linkage and Splink experience in financial-crime teams returns that cluster directly rather than making you reverse-engineer it from title strings.

Make the verdict auditable and reversible

A merge is only safe if it can be explained and undone, and both depend on fields you persist at merge time. Reversibility is a stored-property, not a policy toggle: un-merge works by iterating through retained history and lineage to return records to the state they were in before the incorrect merge.

That gives you the audit contract. For a high-confidence auto-link, retain the record fields compared, the score, the rule or model version, and the active threshold band. For a review-band or conflicting pair, additionally record the conflict, the reviewer decision, a reason code, and the extra evidence used. Underneath both sits the minimum provenance metadata: ownership records, source identifiers, ingestion timestamps, and audit stamps on every later change - who modified what, when, and how.

Verify these before you let the first pair auto-merge.

Keep the verdict current the same way you keep any model current: hold a labeled sample of pairs you have hand-checked, re-measure precision and missed-match rate against it, and adjust the bands when the numbers move. The three-band shape is stable. The cutoffs are yours, and they only stay right if you keep testing them.