---
title: How to tell a duplicate from a child named after a dead sibling
slug: tell-a-duplicate-from-a-child-named-after-a-dead-sibling
description: Review same-named siblings without merging them on shared parents alone. Check the dates, sources and limits of the necronym heuristic.
tools: [duplicate-finder, merge-arbitration, determination-ledger]
difficulty: advanced
time: 25 minutes
lastChecked: 2026-09-06
published: 2026-09-02T23:15:28+02:00
---

# How to tell a duplicate from a child named after a dead sibling

Your duplicate finder shows two records with the same surname, given name, parents and parish, but births seven years apart. A high similarity score does not establish that they describe one person.

One possibility is two children: the first died and the parents reused his name. Another is one child with conflicting dates. Check the sources before choosing.

## What causes it

Parents sometimes named a child after a deceased sibling. Treat this as a possible explanation for repeated names, not a conclusion based on a family's nationality or religion.

Look for this combination, which can also arise from duplicate records or data errors:

- the same given name
- the same surname
- shared parents or the same `FAMC` pointer
- births a few years apart, which reads as "close" to a date comparator
- often the same birthplace, because the family did not move

The shared names, family and place contribute positive weights in this finder. A seven-year birth gap contributes a negative weight.

## Why shared parents inverts the usual heuristic

This finder adds weights for matching names, dates, places and family links, and subtracts weights for conflicts. Shared parents contribute +0.15. That contribution can support either a duplicate hypothesis or a sibling relationship, so it needs context.

Shared parents plus the same given name fits both a duplicate and the naming pattern. Those facts alone do not separate the two explanations.

Run `fixtures/public/necronym-synthetic.ged` through [Duplicate Individual Finder](/duplicate-finder) and the signal table shows the arithmetic:

| Weight | Signal | What it compared |
|---|---|---|
| +0.25 | surname match | `Zieliński` = `Zieliński` |
| +0.20 | given name match | `Franciszek` = `Franciszek` |
| -0.10 | birth apart | birth 7 years apart: `14 MAR 1904` vs `9 NOV 1911` |
| -0.20 | death far | death 69 years apart: `2 FEB 1909` vs `1978` |
| +0.10 | birth place match | same parish |
| +0.15 | shared parents | both children of `@F1@` |

The local run checked on 6 September 2026 returned score 0.40 and a `necronym` verdict with confidence 0.92. The score and verdict are separate: the necronym rule prevents the finder from offering a merge link even if the score reaches the threshold.

Without the elder's death event, the `death far` penalty no longer applies. The weights then sum to **0.60**, the default merge threshold, while the missing-death branch of the necronym rule still applies. Preserve the source file; do not remove evidence to change a score.

Family-structure similarity needs a timing and source check before a merge.

```mermaid
flowchart LR
  E["Two records: same surname, same given name, same parents, same parish, births 7 years apart"]
  E --> H1["Hypothesis A: one person entered twice"]
  E --> H2["Hypothesis B: two brothers, the second named after the first"]
  H1 --> S1["Ordinary scoring counts shared parents at +0.15 and the same given name at +0.20 as agreement"]
  H2 --> S2["The naming custom requires shared parents and the same given name"]
  S1 --> C["Both hypotheses predict the same two signals, so neither signal separates them"]
  S2 --> C
  C --> T["Check dates against sources and confirm they belong to these children"]
  T --> V1["death before birth: supports two people"]
  T --> V2["birth ranges overlap: the rule returns to scoring; identity remains unproved"]
  T --> V3["missing dates: retain both records while researching"]
```


## The rule the finder applies instead

```mermaid
flowchart TD
  P["A pair sharing parents and a given name"] --> B{"Does each record carry a birth date?"}
  B -- "one is missing" --> U["necronym, confidence 0.60, evidence birth-unknown. Sequential lives cannot be excluded"]
  B -- "both present" --> O{"Do the two birth ranges overlap?"}
  O -- "yes, identical or overlapping" --> S["Not a necronym. The pair goes back to scoring and can become a merge candidate"]
  O -- "no, one is clearly earlier" --> D{"Does the elder record carry a death?"}
  D -- "no death recorded" --> N1["necronym, 0.75, evidence no-death-recorded"]
  D -- "death range ends no later than younger birth range starts" --> N2["necronym, 0.92, evidence death-before-birth"]
  D -- "death entirely after the younger birth" --> S2["Not a necronym. The elder was alive when the younger was born"]
  D -- "death range straddles the younger birth" --> N3["necronym, 0.70, evidence death-uncertain"]
```

The current rule compares year ranges. A death and birth in the same year need a manual day/month check even if the rationale says `death-before-birth`.

**A missing death date does not clear the pair.** Absence of a death event supplies no evidence that the two records describe one person.

**Identical or overlapping birth ranges clear only this heuristic.** The finder returns the pair to scoring. Twins, repeated names and date-entry errors remain possible; the date match does not prove identity.

## What the third verdict means

The finder returns three verdicts, not two: `merge candidate`, `necronym`, and `below threshold`.

A necronym verdict is a statement about the evidence, not about the people. It says: these two records share parents and a given name, their lives could have been sequential, and nothing in the file rules that out. It does not say the two people are certainly different. It says a merge is not supported by what the file holds.

Three consequences follow:

1. **Merge is not offered.** The pair shows `Merge is not offered for a necronym.` in place of the merge link.
2. **The threshold does not reach it.** The page states `Necronyms stay necronyms at any threshold.` Dragging the slider re-sorts scores; it does not overrule the rule.
3. **The computed rule uses confidence values from 0.60 to 0.92**, with evidence keys such as `same-parents`, `same-given`, `sequential-lives`, `death-before-birth`. A recorded determination can supply a different confidence. These values describe the heuristic or recorded judgment, not a measured probability.

## The fix

1. Keep a backup, then open [Duplicate Individual Finder](/duplicate-finder) and drop the file. Read the three counts above the pairs: merge candidates, necronyms, and pairs below the threshold. On `fixtures/public/necronym-synthetic.ged` they read `0 merge candidates`, `1 necronym` and `0 below threshold`.
2. Open each necronym pair. Read the two record cards side by side, then the signal table, then the block headed `Necronym rule: same parents and the same given name do not make a duplicate.`
3. Read the three rationale lines under that heading. They name the shared family, the shared given name, and the sequential-lives finding, for example `@I1@ died 2 FEB 1909, before @I2@ was born 9 NOV 1911`.
4. Go to the parish register, civil registration index or another source for the family. Look for the elder child's death or burial between the births. Confirm the parents, place and age so you do not attach another child's death to this record.
5. Look for evidence in the other direction. A marriage, a census entry, an emigration record or a child of the elder that postdates the younger's birth means the elder was alive, and the pair is either one person or two people who are not a necronym.
6. Click **Ask for arbitration** to review the argument. **Rule-based answer only** runs in your browser. **Ask the model** sends both records' lines, linked relatives' names, xrefs and birth/death dates, signals, the necronym flag and existing pair determinations through `/api/ai/v1` to OpenRouter and a model provider. Read the size and content disclosure, including any private notes. Model access may require the separate `/ai-access` challenge. A failed request returns a labelled rule-based fallback. Neither result proves identity or applies a merge.
![Merge Conflict Arbitration with the two same-named brothers side by side, the duplicate finder's 0.40 score below them, and the necronym flag under that.](/kb/shots/tell-a-duplicate-from-a-child-named-after-a-dead-sibling-arbitration.jpg)
7. When the evidence says two people, dismiss the pair. The button is **Dismiss: not the same person** on the duplicate finder and **Dismiss as different people** on the arbitration page, and the two write the same `merge-rejected` determination onto both records through the ledger. Use whichever page you are standing on.
8. Click **Build GEDCOM with N determinations**, then use the download link. Load that file before opening another tool; a dismissal in a page does not update your source file.
9. Open [Determination Ledger](/determination-ledger) on the downloaded file and confirm the row is there.

## What to check when it worked

- Load the exported file back into [Duplicate Individual Finder](/duplicate-finder). The dismissed pair no longer appears, and the page reports the dismissal count.
- Open [Determination Ledger](/determination-ledger) on that file. The pair appears as a `merge rejected` row naming both xrefs, the date, the actor and your reason. The `NOTE GEDTK-DET/1 merge-rejected` lines that carry it are printed under the row.
- Reopen the file in another browser session and check the dismissal. Before sharing with a relative, review living people's details and the determination text. Other programs may strip or rewrite the carrier notes.
- Search the elder record for a death event you added from the register. Once the elder's death precedes the younger's birth, the necronym confidence rises to 0.92 and the evidence key changes to `death-before-birth`.

## What to do when it did not

**A necronym verdict on a pair you know is one person.** Check missing births, death dates and parent links against sources. A recorded necronym determination can also retain the verdict after a date correction. Review it in [Determination Ledger](/determination-ledger). Correct evidence or a mistaken determination only after you can explain the change.

**A pair with the naming pattern that the finder did not show.** Missing blocking keys, the score floor or result limits can hide pairs. A missing `FAMC` does not prevent comparison through name/date blocks or a probable-duplicate reciprocity finding. Check family links with [Link Reciprocity Checker](/link-reciprocity-checker), or select the known pair in Arbitration. Do not invent dates or links to force detection.

**Three children with the same given name.** The custom repeats when the second child also died. Each pair gets its own verdict, and each needs its own dismissal.

**You have the death record and it is not in the file yet.** Add the death event before you dismiss. The dismissal records your decision; the death record records the evidence, and it is what makes the decision checkable by the next person.

**The file already carries a prose note explaining the case.** A previous researcher may have written the reasoning out in a `NOTE`. [Note Structurer](/note-structurer) reads prose notes, extracts the claims they carry with the exact words each rests on, and writes the ones you accept into the file as determinations. See [how to turn free-text source notes into real citations](/how-to/turn-free-text-source-notes-into-real-citations).