Find and Fix Family Tree Errors Automatically

Most family tree errors fall into one of seven categories. GEDminer detects all of them:

1. Date contradictions — death before birth, child born after father's death (more than 9 months), marriage before either partner's birth, future events, ages over 120.
2. Duplicate individuals — the same ancestor entered more than once because of a merge, an import, or two contributors working independently.
3. Broken structural links — a family points to a spouse or child ID that doesn't exist; an individual claims a family that doesn't reference them back.
4. Unlinked individuals — people in the file with no parents, no children, no spouses, and no events tying them to anyone else.
5. Encoding corruption — non-ASCII characters mangled by an old export pipeline (UTF-8 read as Windows-1252 is the classic case).
6. Place inconsistencies — the same location written multiple ways, frustrating searches and mapping.
7. Sourcing gaps — facts asserted with no citation, or citations that point to an empty source record.

Each of these has its own report in the analyzer with copy-and-paste record IDs so the fix can happen in your main editor with no guesswork.

The date checker normalises every GEDCOM date into a canonical form (year, month, day, plus precision flags for "abt", "bef", "aft", date ranges and approximate dates). It then runs a series of cross-fact comparisons:

• Self-consistency: birth ≤ death; death ≤ today; ages within plausible bounds.
• Marriage logic: both partners born before the marriage; both alive at the time; neither already married to the same partner.
• Parent-child logic: father at least ~14 years older than child and alive at conception; mother at least ~12 years older and alive at birth (with sensible upper bounds).
• Sibling spacing: large gaps between recorded siblings are surfaced separately in the Incomplete Families report rather than flagged as errors.

Approximate dates ("abt 1850") are not flagged as errors — they're flagged as opportunities by the Vital Sharpener, ranked by how much your tree would improve if they were tightened.

Naive duplicate detection ("two people with the same name and birth year") misses most real duplicates and produces too many false positives. GEDminer combines several signals:

• Soundex phonetic codes so "McDonald" matches "Macdonald" and "Stewart" matches "Stuart".
• Levenshtein edit distance on full names so "Mary Eliz Smith" matches "Mary Elizabeth Smith".
• Vital-date overlap with tolerance for approximate dates ("abt 1850" matches "1849–1851").
• Parent overlap as a strong corroborating signal (or a strong dis-corroborating one — different parents = probably not a duplicate).
• Place agreement as a secondary signal.

Each pair gets a single normalised confidence score. Pairs above the 0.55 threshold are shown ranked by score, with the supporting evidence visible so you can make the call. The threshold is tunable in settings.

Encoding corruption is the most common error in old GEDCOM files and the easiest to miss because it's invisible if you only look at one record at a time. The classic symptom: "Müller" appears as "Müller", "O'Brien" appears as "O’Brien", or accented vowels appear as random punctuation.

This happens when a file is written in one encoding (typically UTF-8) and read in another (typically Windows-1252 or Latin-1). GEDminer's parser tries each encoding in turn and scores the result by how many recognisable words appear, picking the cleanest decoding automatically. If your file has been corrupted at multiple points (re-saved through a different encoding twice), the parser will surface what it can and flag the rest.

Once the parse is clean, the encoding fix is permanent — you re-export from your editor and the corruption is gone.

The error report is structured by severity and by effort. High-severity items (broken links, impossible dates) come first because they actively break the tree. Medium-severity items (duplicates, encoding) come next because they distort searches and analysis. Low-severity items (vague dates, missing sources) are surfaced separately by the Vital Sharpener as improvement opportunities rather than outright errors.

A practical fix order:

1. Fix broken structural links first — they cascade.
2. Resolve duplicates next — fixing other things in a duplicate is wasted effort.
3. Fix encoding — re-export once and many downstream issues vanish.
4. Resolve impossible dates record by record.
5. Use the Vital Sharpener to tighten the highest-impact vague facts.
6. Use the Sourcing report to add citations to the most-referenced unsourced facts.

Re-export and re-run the analyzer after each pass — the Tree Health Score will tell you whether the work moved the needle.