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 and the signal table shows the arithmetic:

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.

Diagram source

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

Diagram source

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 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.
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 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. The dismissed pair no longer appears, and the page reports the dismissal count.
• Open 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. 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, 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 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.