Guides
Part of 8 things a family tree can honestly claim to show you
Family trees updates: questions to ask before you edit
A practical guide to family trees updates: what to check before correcting a link, how to version entries, and when to order a vital record.
A family tree update is not one edit. It is a change to a claim, a check on everything that rested on that claim, and a record that shows why the old version was wrong. This guide covers the questions to ask before you correct a link in family trees updates: what breaks when parentage moves, how to decide a merge, what a change record must contain, how to treat derived values, and when a vital record is worth ordering. It also corrects a date error that follows the topic around: no 2027 edition of the GEDCOM standard exists. GEDCOM 7.0, released in 2021, is the most recent version as of July 2024.
What a family tree update actually changes
When a parentage link is withdrawn, three sets of things break at once. Everything above the link moves to a different family; that is the obvious case. Everything derived from the link also breaks: generation counts, relationship labels between people elsewhere in the structure, ages calculated against the wrong person's dates, and any statement that two people are related. Narrative sentences built on the structure break silently, because prose does not know it was generated from a diagram.
Step one is an inventory. List what asserted the link, what was inferred from it, and what text anywhere on the site depends on either. Do that before the edit. The other order leaves a corrected tree surrounded by uncorrected sentences, which is worse than the original error because it now looks reviewed.
Relationship claims travel further than their source page. In coverage of celebrity children, a single parentage correction can affect an age, a sibling order, and a household description on pages that were never edited. The sweep has to include those pages by name.
The questions to ask before you edit a link
Ask these questions in this order, and write the answers into the change record.
- What exactly is the claim? Name the parentage or identity link by a stable identifier, not by a position in a chart.
- What is the basis? Quote the record or statement the claim rests on, with its own date.
- What depends on it? List derived values, labels, ages, and prose sentences that used the old link.
- What does the new evidence actually say? A record that fails to confirm a link is not the same as a record that contradicts it.
- What would change if we accept the new basis? Write the before and after in one sentence each.
- What will not change, and why? This prevents the same question being reopened by someone who assumes it was overlooked.
- Who made the change, when, and on what authority? An author and a date are part of the claim's history.
- What is the reversal path? If the change is later withdrawn, what will restore the old state, and where is it kept?
These questions are the practical core of family trees updates. They apply whether the tree is private research or a published celebrity family tree, and they apply before the first edit, not after.
Why a merge is the one edit you cannot reliably undo
Most changes can be reversed. Merging two entries that turn out to be one person cannot, in practice, because the merged record stops looking suspicious the moment it exists, and the evidence that once separated them is now attached to a single entity.
Work by exclusion before merging, not by resemblance. Keep two candidates as two entries. Follow both forward and backward. Look for the moment they must be different people: one recorded in one place while the other is recorded elsewhere, or one has a documented event the other cannot share. Merge only if you fail to find that moment after searching, and record the search.
Where a merge does happen, keep both original entries in the history with their own identifiers, so an unmerge is a restoration rather than a reconstruction from memory. The same caution applies to celebrity sibling lists and celebrity parents, where two public records can describe one person under different names.
Version the claims, not the picture
A diagram is a rendering. Versioning the rendering tells you that the picture changed and nothing about why. Version the underlying entries instead. Keep one record per claim, each with its own history of what it said and what it rested on. Then a change is a change to a claim, with an author, a date, and a reason, and the diagram is regenerated from whatever the claims currently say.
Two properties follow that hand-maintained trees rarely have. The picture and the evidence cannot drift apart, because one is produced from the other. And a question about any line in the diagram resolves to a specific record with a specific history. This is also why a positional identifier is unusable as a reference: positions move when the structure moves, and a citation to a position cites a slot rather than a person. The same problem is described in what chart conventions encode.
Build the claim history rather than the chart history. A family trees list can be regenerated; a lost claim basis cannot.
What the change record has to hold
Every correction should leave a record with the same fields. The point is not bureaucracy. It is to make the update complete and to make the next review cheaper.
Field / Content
- The claim
- Which link or identity changed, named by stable identifier
- Before
- What the record asserted previously, kept rather than overwritten
- After
- What it asserts now
- Basis
- The evidence for the change, quoted, with its own date
- Who and when
- The person who made it and the date they made it
- Dependents checked
- Everything that rested on the old value, listed, with its outcome
- Not changed
- Claims the new evidence does not affect, and why they stand
- Confidence after
- The state the link is now in, from the same fixed vocabulary as always
The "not changed" row prevents the same question being reopened every few months by someone who assumes it was overlooked. The "dependents checked" row turns a correction into a completed piece of work rather than a started one.
Recompute derived values instead of storing them
Anything you calculated should be calculated again whenever its inputs move. Store the source dates and the source statements; let ages, relationship labels, and generation counts be produced on demand. Stored, they persist after inputs change and become quiet contradictions nobody checks. Recomputed, they simply move, and a value that turns into a range signals that the evidence underneath was thinner than the display suggested.
Interchange formats such as GEDCOM carry source dates rather than derived ages for the same reason. The current version is GEDCOM 7.0, released in 2021. It is the most recent version of the specification as of July 2024, so a "2027 update" has nothing to report from the standard itself. The update work is in your claim records, not in a new GEDCOM release.
What source records cost when you need proof
Some updates cannot be settled from what you already hold. You may need a birth, death, or marriage record from a vital records office. Fees are set by the issuing office and vary by place.
In Washington State, the nonrefundable fee for ordering a vital record online or by phone starts at $40.50, made up of a $25 certificate fee, an $8.50 VitalChek fee, and a $7 DOH processing fee (Washington State Department of Health). In New York City, each birth or death certificate costs $15, along with processing fees (NYC Health).
Treat those figures as examples, not a national price. Check the office that holds the record before you pay, and order only when the document will settle a claim you can name. A record that does not answer one of the questions above is an expense, not evidence.
Downstream copies do not update
Published trees get copied, and the copies do not follow your corrections. Agreement between copies measures how widely something was duplicated, which is different from agreement between sources. A mistake entered once can propagate across many collections and then look independently confirmed, because agreement between copies is indistinguishable from agreement between sources.
Two responses follow. Make corrections explicit and machine-visible rather than quiet, so anyone comparing versions can see what moved. A silent edit is invisible to exactly the people who need to know. Then accept the limit instead of pretending it away. The fix is worth making even if it will not reach everything, and the real defense is upstream: publish fewer links that the evidence does not carry.
For living people, the review trigger is not only new evidence. It is also any change in what is published about them. The standard for that portion moves independently of the tree, as described in privacy in a structure.
Common questions
A new record contradicts a link we published. Do we remove it or mark it disputed?
Depends on what the record is. Where it directly contradicts the basis, correct the link and note what it said before. Where it merely fails to confirm, that is not contradiction, and the honest outcome is to move the confidence state rather than the claim.
How often should a family tree be reviewed if nothing has happened?
On a schedule you actually keep, and on triggers. The triggers are any new statement by someone in the tree, any correction anywhere in the chain, and any change to what is published about living people.
Someone sends a correction with no source. What do we do?
Record it as a lead with its date and who sent it, and do not change the published claim on it alone. Family corrections are often right and are still assertions. Ask what they rest on, and say plainly that you have received a contested account if the question is likely to recur.
Should the old version stay visible to readers?
The fact that something changed should, along with what it was and when it moved. Full historical versions are useful internally and rarely useful on the page. What readers need is the ability to tell that the page is maintained, and to see that a specific claim was withdrawn rather than quietly disappearing.
