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

*You can score any candidate record pair on weighted signals and route it to auto-merge, review, or keep-separate with thresholds two operators apply the same way.*

- Canonical URL: https://www.refolk.ai/guides/record-match-verdict-auto-merge-review
- Pillar: Process, data, and compliance
- Format: Framework
- Published: 2026-10-15
- Last reviewed: 2026-10-15
- Reading time: 16 min

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.

| Source/domain | Auto-merge | Review | Keep-separate |
|---|---|---|---|
| General (RudderStack) | above 0.90 | 0.50 to 0.90 | below 0.50 |
| Probabilistic reference | above 0.90 | 0.70 to 0.90 | below 0.70 |
| Catalog (Claro) | 0.92 and up | mid-band | low bound |
| Financial services (Neo4j) | 0.98 | 0.90 to 0.98 | below 0.90 |

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.

**0.98 - Auto-merge threshold in financial-services dedupe configs**

Against a general norm of above 0.90, the extra 0.08 buys precision where a wrong merge is costly to undo.

## 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.

> **Rule:** Deterministic keys before fuzzy scoring
>
> Resolve strong unique identifiers first - verified personal email, EIN, LEI - and only then layer probabilistic scoring on the pairs that remain. A fuzzy score must never override a verified unique ID.

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.

| Pair | Levenshtein (normalised) | Jaro-Winkler |
|---|---|---|
| Jon Smith / John Smith | n/a | ~0.96 |
| Mohammad / Muhammad | n/a | ~0.93 |
| Martha / Marhta | 0.667 | ~0.961 |
| Johnson & Associates Inc / ...Incorporated | 0.62 | 0.78 |

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.

#### From two raw records to one verdict

1. **Normalise** - Canonicalise emails, domains, names, and codes on both records
2. **Deterministic keys** - Match on verified email, EIN, or LEI and merge exact hits
3. **Field similarity** - Jaro-Winkler on names and addresses, Levenshtein on codes
4. **Weighted score** - Combine into one calibrated 0-to-1 confidence
5. **Band and route** - Auto-merge, review, or keep-separate by reversibility

*Deterministic keys settle the easy cases first; fuzzy scoring only decides the pairs that survive.*

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.

I ran this search: `Developers whose public GitHub commits show a verified work email and a LinkedIn profile, based in the San Francisco Bay Area` - [see the full result list](https://www.refolk.ai/s/tzgb1fxcm6).

*Returns developers already carrying the corroborating signals that make a confident person-record merge - the commit-header email and a second profile - rather than profiles you would have to review by hand.*

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.

#### Where to set the auto-merge cutoff

Horizontal axis runs from Hard to reverse to Easy to reverse. Vertical axis runs from Weak signals only to Strong unique ID matched.

| Quadrant | What it means |
| --- | --- |
| Weak signal, hard to reverse | Keep separate or require two corroborating fields before review |
| Weak signal, easy to reverse | Route to review; a reviewer can catch the error cheaply |
| Strong ID, hard to reverse | Auto-merge only at a tightened cutoff (toward 0.98) with full lineage |
| Strong ID, easy to reverse | Auto-merge at the general cutoff (above 0.90) |

*Two variables decide the band: how reversible a wrong merge is, and how discriminating your strongest matched signal is.*

> **Watch out:** Do not copy a threshold from a slide
>
> The right cutoffs come from testing against a labeled sample of your own records, not from borrowing a vendor figure. An untuned probabilistic threshold can merge two different people into one record; a copied figure is untuned by definition.

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.

#### Scoring and routing a candidate pair

1. **Normalise both records** - Lowercase, strip punctuation, expand abbreviations, and canonicalise emails and domains so both records' fields are comparable. Done means every compared field holds a value in the same shape.
2. **Apply deterministic keys first** - Run exact rules on strong identifiers - verified personal email, EIN, LEI - to settle clear matches before any fuzzy scoring. Done means high-confidence matches are resolved and only ambiguous pairs remain.
3. **Score fields with field-appropriate similarity** - Use Jaro-Winkler for names and addresses and Levenshtein for codes, and set missing-field indicators. Done means you hold a per-field similarity vector.
4. **Combine into a weighted confidence score** - Weight each field by its discriminating power, deterministic keys first and fuzzy signals second, and collapse the vector into one 0-to-1 number. Done means the pair carries a single calibrated score.
5. **Set bands by reversibility** - The risk owner sets auto-merge, review, and keep-separate cutoffs by the cost of a wrong merge, tighter where an error is hard to undo. Done means documented thresholds tied to reversibility.
6. **Route the pair** - Compare the score to the bands and assign the pair to exactly one. Done means the pair sits in auto-merge, review, or keep-separate.
7. **Review the mid-band** - A reviewer inspects pairs close enough to flag but not close enough to auto-merge, then records a decision and a reason code. Done means every review-band pair has a human verdict with a reason attached.
8. **Write the audit record** - Persist the fields compared, the score, the rule or model version, the active band, the reviewer, and the source lineage. Done means the merge is answerable and reversible.

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

**Pair-scoring rubric skeleton**

```
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: ___
```

*Replace the weights and cutoffs with values you tuned on your own labeled sample.*

## 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.

**4.1% - True matches missed by exact-key matching alone**

Against a 0.2% false match rate - exact keys are precise but quietly drop real duplicates, which is why fuzzy layering is worth it.

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.

| Segment | Count | Top employer |
|---|---|---|
| Entity Resolution, US | 194 | Deloitte / Quantexa |
| Entity Resolution, UK | 55 | Quantexa |
| Record Linkage, US | 138 | Meta / Google / Deloitte / Amazon |

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.

#### Before you turn on auto-merge

- [ ] Deterministic keys run before fuzzy scoring, and a fuzzy score cannot override a verified unique ID.
- [ ] Company matching uses EIN or LEI as the strong key, not DUNS alone.
- [ ] Person matching confirms a verified personal email, and on GitHub reads the commit-header email.
- [ ] Name-only similarity is capped below the auto-merge cutoff and requires a corroborating field.
- [ ] Missing-field indicators prevent two empty fields from scoring as a match.
- [ ] Thresholds were tuned on a labeled sample of your own records, not copied from a vendor figure.
- [ ] Bands are set by reversibility, with tighter cutoffs where a wrong merge is hard to undo.
- [ ] Every merge persists fields compared, score, model version, band, reviewer, and source lineage.
- [ ] An un-merge has been tested end to end and restores the prior state.

> **Tip:** Re-tune on a schedule, not on a hunch
>
> Thresholds drift as your sources change. Re-score a fresh labeled sample periodically, measure the missed-match rate against it, and move the cutoffs only on that evidence. The landmark figures in this guide are for orientation; your labeled sample is the authority.

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.

## Frequently asked questions

### What confidence score should I auto-merge at?

Start from the general norm of auto-merging above 0.90 and routing 0.50 to 0.90 to review, but treat that as a starting point, not a law. Raise the cutoff toward 0.98 when a wrong merge is dangerous or hard to undo, as financial-services configs do with a 0.98 auto-merge and 0.90 flag threshold. The right values come from testing against a labeled sample of your own records, not from copying a figure.

### Can I auto-merge two company records that share a DUNS number?

No, not on DUNS alone. DUNS identifies a business location, not a company, so a firm with 40 offices has 40 DUNS numbers, and matching on it both fragments single companies and can over-merge unrelated locations. For companies, lean on legal-entity identifiers like an EIN (the IRS tax entity) or an LEI (the global financial-markets entity) as your strong key, and treat a shared DUNS as a review-band signal.

### Why does exact-email matching fail on so many GitHub developers?

GitHub attributes a commit by matching the email in the commit header to an email on a GitHub account, but only about 15% of users expose a public profile email. A finder that reads only profiles therefore fails on roughly four in five developers. The high-discriminating signal lives in commit metadata, so read the commit-header email and confirm it is a verified personal account before auto-merging, since a shared or noreply address only justifies review.

### Jaro-Winkler or Levenshtein for name matching?

Use Jaro-Winkler for names and addresses and reserve Levenshtein for short codes and IDs. Jaro-Winkler handles transpositions better: Martha versus Marhta scores about 0.961 on Jaro-Winkler against a normalised Levenshtein of 0.667, a gap of roughly 0.29. Above 0.85 typically indicates a strong match, but a high name score alone never clears auto-merge because different surnames like Zhen and Zheng can score high.

### How do I make a merge reversible?

Reversibility is a stored-field property, not a policy toggle. Un-merge works by iterating through retained history and lineage to return records to their pre-merge state, so it only succeeds if you persisted the fields compared, the score, the model version, the band, and the source identifiers at merge time. Confirm those audit fields are being written before you allow any auto-merge.

### Why not just set one fixed threshold for everything?

Because the cost of a wrong merge is not fixed. Where a false merge is dangerous, you favour precision and tighten the cutoff; where missing matches is worse, you favour recall and loosen it. A single cutoff forces one entity type and one risk profile onto records that differ in both. Band by reversibility and validate on your own labeled data instead.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/record-match-verdict-auto-merge-review*