Frequently asked questions

There is no live Ancestry connection to link. Export the Ancestry tree as a GEDCOM, upload the file here as a second tree, and compare the two in Reconcile trees.

Upload both as trees, open Reconcile trees and pick the pair. You get an overview, the people that may be the same, the facts that contradict each other and the branches present in one tree only, with a preview before anything is applied.

On Pro or Premium, yes: each GEDCOM becomes its own tree, so you can hold several side by side and compare them. The free plan holds one tree, so a second upload is refused until you delete the first or upgrade.

On Pro or Premium, upload it as a separate tree, compare the two and decide what to carry over before deleting anything. The free plan holds one tree, so delete the old one first or upgrade.

No. AutoTreeGen has no connection to Ancestry or MyHeritage accounts. It reads the file you export and upload, and writes nothing back.

Yes, within your plan. The free plan accepts one tree of up to 250,000 people; above 20,000 people the core tree is imported and duplicates are searched, while hypotheses, the Evidence Graph and research reports run on Pro. Pro holds up to 250,000 people per tree across ten trees, Premium up to 500,000 people per tree with no limit on the number of trees.

No. Upload them separately and compare them in Reconcile trees. Reconciling always builds a new, third tree and never modifies the two originals, so merging by hand first only throws away the record of where each claim came from.

The two records stay separate people in their own trees. Accepting a match in Reconcile trees makes them one person in the new, combined tree it builds; the originals are untouched.

Yes, if you own it: open the tree's menu on the dashboard and choose Delete. It is erased for good right away and cannot be undone.

No. Deleting a tree and erasing your account are separate actions on separate pages.

A priestly or Levite line is kept as a hypothesis that depends on Y-DNA evidence and is never attributed automatically. The tradition, the documents and the DNA signal stay together without the platform declaring the status settled.

1. On Ancestry, open DNA, then Settings, and choose Download DNA data. Ancestry emails you a link; the download is a .zip file. 2. Here, open DNA and click Add DNA, choose Raw genotype file, pick that .zip and give consent. The kit appears with the number of markers read. 3. A raw file alone gives haplogroups and segment data, not relatives. Ancestry does not offer a match-list export: copy your Ancestry matches page and paste it into Import match list, or get your relatives from GEDmatch: upload the same raw file to GEDmatch (free), wait until it is processed, run One-to-Many and download the CSV. 4. Back here, open DNA, find your kit's row and click Import match list, then choose that CSV. 5. Link the kit to yourself in your tree so matches can be placed. Stuck on any step? Send us a screenshot of the screen you see, and we will tell you exactly what to click.

After the import, read Tree health for what is documented and what is not, then Duplicates and the open conflicts. Those three screens show where the tree actually needs attention.

Import it as it is. The platform is built to surface the duplicates, conflicts and unsourced claims an old file carries; cleaning it by hand first only hides what it would have found for you.

A new import can bring back a claim you already rejected, because it arrives as a new assertion. Your earlier rejection is kept, so it shows up as the same conflict again instead of silently overwriting the decision.

Yes. A relationship's evidence view traces it to the import or the source that asserted it; no relationship claim arrives without that origin record.

No. It analyses and reconciles the genealogy you bring from those platforms as GEDCOM and DNA exports. It does not replace their record collections or their matching.

No. It is a workspace for evidence-based research on your own trees, under your own access controls. A public link you create shows one tree read-only; there is no public directory.

A tree has to exist first, and today that means an import: a GEDCOM or a document reconstructed into a tree. There is no from-scratch tree builder, so a minimal import is the practical starting point.

Yes, once each tree is exported as a GEDCOM and uploaded. AutoTreeGen compares the trees it holds, not the platforms they came from.

Reconcile trees compares two whole trees and shows where their people overlap. It does not yet let you limit the comparison to one branch.

When it builds the combined tree, Reconcile trees accepts the pairs it judges obvious on its own; everything less than obvious waits for you, and a decision you made yourself is never overwritten. Your two original trees are never touched.

No. It has no tool that changes your tree. Merges and other edits stay under your own control on their own screens.

ROOT is set per tree. With several trees, check that it is set on the one you are working in right now.

No. Set as ROOT changes which person the tree opens on and nothing else. Relationship labels are measured from the person named under Who you are in this tree in the tree's settings.

Yes. ROOT belongs to one tree; another tree has its own. Who you are in this tree is set separately and may be a different person.

At any time: open the person you want and use Set as ROOT. The person may be alive or long dead. Only the opening person changes.

Yes. A person can carry any number of name records: birth, married, Hebrew, religious, nickname, also-known-as or other. Each is its own entry, so none has to overwrite another.

Add both as separate name records: Hebrew and birth or civil are distinct name types, neither replaces the other, and both stay visible on the person. A person may well have a Hebrew name that differs from the civil one; that is what the two records are for.

"Also known as" is a name type of its own, beside birth, married, Hebrew, religious and nickname, for an alternate name the same individual went by.

A name record has its own patronymic field, separate from the given name and the surname. Recording it there keeps it available for identity review instead of buried inside a free-text name.

Yes. Sound-alike matching and Cyrillic-Latin transliteration feed both person search and duplicate finding, so a Yiddish, Russian or Latin spelling of one name is read as a variant of the same name. A spelling match is a strong signal, not proof of identity.

No. The finder treats them as a name variant, one signal among several weighed together with birth year and place, never as proof of identity on its own.

They can be variants of one underlying name, and the finder weighs them like any other name variant, alongside the rest of the evidence. It never assumes the match on its own.

A shared or similar name is never enough to merge two people automatically, because the same name is common inside one family and a wrong merge is hard to undo. The pair appears as a duplicate candidate for you to review.

Yes. Nickname is its own name type, kept beside the person's other names.

No. Surnames follow naming customs, which do not always travel with a genetic segment. A shared surname and shared DNA are two separate pieces of evidence.

Yes, because a surname often runs down the same paternal line. A shared surname and a shared Y haplogroup together mean two men could share a paternal ancestor, not that they share a recent, documented one.

No. A Cohen-type surname, Kahn included, is a hypothesis that depends on Y-DNA, not proof. Many families adopted the name without the line, and many with the line never carried the name.

Often decisively, which is why a name record has its own patronymic field. It still has to agree with date, place and family context before it identifies anyone.

Yes, through migration, transliteration and the adoption of fixed surnames. A spelling or surname change is therefore a variant to investigate, not a sign of a different family.

No. A surname, even an unusual one, is a naming pattern, not a link. It can point at a hypothesis worth investigating; it does not settle it.

No, but it is an important clue: a shared patronymic points at a common father's given name, which narrows the search considerably without confirming the relationship by itself.

Both, through different doors. The raw genotype file goes through the raw-file entry, which recognises the company from the contents. The matches CSV belongs to a kit: register or upload the kit first, then import the list on that kit's row.

The GEDmatch entry registers a kit by its number and takes no file, so it is the wrong door for a file you already have. Go back and choose the entry that matches the file: raw genotype, match list, clusters or Y-DNA results.

No. Matching happens in the database of the company you tested with; AutoTreeGen reads the exports you bring from there. For newer matches, export the list again and import the new file.

Yes. Link every one of those kits to the same person: they are one individual tested more than once, not several relatives.

No. Testing happens at the testing company. AutoTreeGen reads the files you export from there.

For GEDmatch, yes: that entry registers a kit by its number and takes no file. Every other company's kit needs its export, raw genotype or match list, before there is anything to analyse.

No. A match is analysed from the export you uploaded. The person behind it is never contacted and does not need an account here.

No. A match in your export is analysed from that file alone, whether or not that person has ever heard of the platform.

No. A kit belongs to the one individual who was tested. Several kits can be linked to one person, but one kit cannot belong to two people.

A file exported from your testing company that lists the people who match a kit, with the statistics the company provides: shared centimorgans, segments and the like.

A group of your matches who also tend to match each other, built from an AutoCluster export you upload or computed from the match lists already attached to a kit.

Not always. In endogamous populations the same ancestors sit on more than one line, so clusters overlap. The platform applies a correction for that, and still shows the overlap rather than hiding it.

No. A shared-centimorgan amount maps to a range of relationships. The prediction here is endogamy-aware precisely because a raw number cannot pick one.

Because repeated marriage within a community inflates shared DNA between people who are genealogically further apart than the number suggests. The platform detects it and corrects for the population before predicting a relationship.

No, least of all in an endogamous population, where that amount can be several distant shared ancestors adding up rather than one recent one. The endogamy-aware prediction corrects for exactly this.

The direct paternal line, father to son. A person's Y haplogroup is recorded separately from their mt haplogroup for that reason.

Women carry no Y chromosome, so a male relative on the paternal line in question tests instead. The result is linked to the person the line is about, not to whoever ordered the test.

No. A haplogroup can be many centuries older than any documented family line. Sharing one is a starting point, not proof of a recent connection.

The direct maternal line: from a mother to all her children, and onward only through her daughters. It is recorded as its own field, separate from Y-DNA.

No. Like Y-DNA, a shared mt haplogroup can go back to a maternal ancestor who lived long before any documented genealogy. It is a lead, not proof of a recent relationship.

Yes. The haplogroups are their own fields on a person, kept as a separate evidence layer beside the documents, and the paternal line check compares a new Y result with the documented fathers automatically.

Yes, as family testimony, which is an evidence type of its own. It stays distinct from documents and from Y-DNA and is not upgraded to either on its own.

Only within the platform's consent rules. It cannot see DNA that consent has not opened to it, the same boundary every other feature observes.

No. DNA is opened only by explicit consent, the same rule the assistant follows. Nothing about your DNA is visible to anyone without it.

No. Access follows the same permission and consent model as any other account; there is no unrestricted view. Support access to a specific account, if ever needed, goes through accountable, logged channels like any other operator action.

Yes. Delete a kit from the DNA kits page and its stored data is erased; withdrawing a consent is done on your consents page.

Usually an unsupported layout, delimiter or encoding for the company the file claims to be from. Export it fresh from that company instead of re-saving it through another program, which can change the encoding without telling you.

The upload entry reads the file's content to recognise the company, not the file name. A renamed or repackaged export can genuinely look like another company's file; the message names what it detected so you can choose the right entry.

On the free GEDmatch plan the One-to-Many results are shown on the page only; the download button belongs to their paid Tier 1. The free way: 1. Open the One-to-Many results for your kit. 2. Click at the start of the table (the Kit header), hold Shift, click at the end of the last row, press Ctrl+C (Cmd+C on Mac). 3. Open a new Google Sheet or Excel file and press Ctrl+V: the table lands in columns. 4. Save it as CSV (Google Sheets: File, Download, Comma-separated values; Excel: File, Save As, CSV). 5. Here, open DNA, find your kit's row, click Import match list, choose GEDmatch and pick that file. The import reads the columns by name, so the copied table works like the export. If the file is refused, send us a screenshot and the file, and we will fix the reader.

A kit registered by number or from a raw genotype file carries no matches by itself. Import that company's match-list export on the kit's row, and the matches appear.

Yes. The documentary side, import, sources, evidence, conflicts and hypotheses, runs fully without a kit. DNA is an extra evidence layer, not a requirement.

No. An assertion can reach verified on documentary evidence alone. DNA is one supporting evidence type among several, not a gate.

Yes. A relationship derived from DNA is still an assertion, and a strong documentary claim against it becomes a visible conflict for you to weigh. Neither side wins automatically.

No. Describe the problem in words or with a screenshot of the screen. A raw DNA file is never needed to report a bug.

No. Consent and privacy apply the same way on every plan. A subscription changes capacity and processing, never who may see DNA.

The evidence is not yet enough to call it proven. A hypothesis keeps the idea, its reasoning and its evidence together until something settles it, so a guess cannot enter the tree and be copied onward as documented.

Your tree seen as claims instead of lines. Each claim about a person points back to the source it came from, the citation inside that source and the confidence the source earns. The lines of the tree are the conclusions drawn from that.

Any document type in the catalogue: government records such as a birth, death or marriage certificate, a census or a military record; private records such as a family bible, a captioned photograph, a headstone or an obituary; and derived material such as a GEDCOM import, a copied public tree or oral testimony. Each tier starts with a different weight.

Yes, as a copied public tree, which sits in the lowest tier beside a GEDCOM import and oral testimony. It is evidence of a claim, not independent proof of it.

The exact place inside a source that supports a claim: the page or section, the quoted text, and a quality score taken from the record's own certainty marker where the source carries one.

A specific statement such as "this person was born in 1893" or "X was the father of Y". Each one has its own status: hypothesis, entered by you, probable, verified, rejected, or in conflict with another assertion.

A document-backed item linked to an assertion. It carries its own document type, which sets its weight, and its own origin record, which says how it was obtained. The two stay separate instead of being folded into one number.

Yes. A marriage record can back assertions about names, ages, parents and marital status at once. Each link is its own entry, so the source is not used up by the first claim it supports.

Yes, and each link records whether the source supports or refutes the assertion. Independent sources that agree strengthen the case; sources that disagree turn it into a visible conflict instead of an averaged answer.

They all carry the same document type, a copied public tree, in the same low tier. Repeating a derived claim five times does not make five independent records, and the weighting counts it that way.

A record of how a piece of evidence was obtained: the channel, the archive, the request reference, the cost. It is kept apart from how strong the document type is, so those two questions are never confused.

Because it is the difference between five independent lookups and one record copied five times. Without it, copying looks exactly like corroboration.

Yes. Oral testimony is its own document type in the same evidence graph as certificates and registers, with the person who gave it attached, so it is never presented as anonymous fact.

Its default tier is lower than a government certificate, but a tier is a starting weight, not a verdict. What the person actually knew, and when, still decides how much a claim may lean on it.

Yes. A top-tier document starts with a strong weight, not with immunity. An informant who never knew the deceased's birth details is a common cause of a wrong date on an otherwise official record.

No. Tier is the starting point for a confidence score, not a rule that quietly overrides a conflicting lower-tier source. A real conflict between two claims stays visible for you to resolve.

The meaningful absence of something a source should normally contain, such as a person missing from a census where the rest of the household appears. There is no separate record type for it; you record it and reason about it like any other claim.

Not by itself. A record you have not found yet is an open gap. A record that should exist in a source you did check, and does not, is the real negative evidence.

Two live assertions about the same fact with different values. They are grouped together and both are marked as in conflict until someone resolves it.

Yes. Both assertions stay live and marked as in conflict until you resolve them. Neither is hidden or dropped because the other exists.

Yes, at any time. Resolving it marks one assertion verified and the other rejected, and keeps the reasoning.

The two parentage claims go into conflict like any other contested fact. The tree keeps showing both parents as competing claims instead of settling on the one that was imported first.

Borders moved and names changed across the period these records cover, so this is often not a contradiction at all. Check the exact place name and the date each record refers to before treating it as a conflict.

No. Most conflicts come from ordinary error: a clerk who misheard a name, a relative's imperfect memory, a place that was renamed. Treating every disagreement as suspicious would miss how records actually fail.

A possible relationship between two records, for instance that two person records are the same individual, with its own score and evidence, kept apart from your own judgment on it.

Yes. Your review of a hypothesis, confirmed, rejected or deferred, is independent of the tree itself, so nothing forces a premature choice between two open possibilities.

When you confirm it after reviewing the evidence. Confirming is a manual decision and does not change the tree by itself; turning it into a merge or a claim is a separate, explicit step.

Yes, and there is a middle option, deferred, meaning "I will come back to this". It leaves your default review queue without counting as a rejection.

Because the same pair can resurface through a later import or a hint. Keeping the rejection lets the system, and you, recognise it as already decided instead of asking the same question again.

The reason you attach when you accept, reject or leave a claim open. It stays on the assertion itself, so later readers see why a decision was taken, not only what it was.

A research-status marker you set on a person to say your own research on that line has stopped. It describes the state of your work, not a judgment about the ancestry.

No. Like every research marker here it makes no claim about the future, only that the evidence has not settled the line yet. Clear it the moment new evidence arrives.

There is no separate form. Use the person's notes and sources as for any research: what is known, what has been ruled out, which records are missing, the geographic clues and any DNA gathered so far.

Two person, source or place records that the finder scored as possibly the same real thing, ranked by confidence. It is a suggestion to review, never an automatic merge.

No. It is one signal among several, with name, surname, birth year and place, that the finder weighs together and shows on the row in plain words. On its own it proves nothing.

Yes. Not duplicate records that you reviewed the pair and kept the two apart, and excludes that exact pair from every future scan of the tree.

No. The rejection is durable and per tree, so a re-scan does not surface the same pair again. A different pair involving either person can still appear, because the dismissal covers that pair, not the people.

Yes. A long and prestigious pedigree gets the same generation-by-generation review as any other line, and the platform shows where the documentary support actually stops instead of accepting the chain on reputation.

No. A title describes a role, not a family link. Two people who held the same title still need evidence connecting the generations between them.

No. It means the chain should be reviewed, not that it has been disproven. A claimed line to a famous or biblical figure is marked as a hypothesis awaiting confirmation, never attributed as fact either way.

Only if the evidence holds generation by generation. A famous rabbinical line is held to the same standard as any pedigree, and the platform shows the generation where the documented chain stops instead of accepting the whole claim on the name.

It can evaluate whatever chain you present. A Davidic line is kept as an unproven hypothesis that depends on Y-DNA and documents, and is never asserted as fact because a family says so.

Because a chain is only as strong as its weakest generation. One unsupported link breaks the documented connection to everything claimed beyond it, however solid the rest looks.

Yes. Extracted facts are candidates to check against the source, not verified claims, which is why every one of them stays linked to the record it came from.

Yes. A captioned photograph is a document type with its own tier, like a certificate or a letter. The better its date, inscription, origin and identified people are documented, the more it counts.

Yes. An obituary is its own document type. It usually carries details reported by the family rather than an official record, and its default weight reflects that.

Yes, especially together with Hebrew names, patronymics, dates and relationships. A headstone inscription is its own document type because it carries exactly that kind of identifying detail.

Yes. It lays out both sides and their evidence without deciding. Resolving a conflict is your research decision, not the assistant's.

That is one of its core jobs. It reads each claim's actual status, hypothesis, verified, in conflict or rejected, from the evidence graph and states it, instead of treating every claim as equally settled.

The share of claims in your tree with at least one citation attached. It is shown as its own figure, so documentation and DNA linkage stay separate signals.

Coverage counts claims with a citation attached, not sources uploaded. A tree can hold many sources that are not yet linked to the facts they support, and each of those facts counts as uncovered until it is.

Yes. The score is recomputed from the tree's current state, so citing uncovered claims moves it, as does resolving conflicts and linking DNA.

That the scan ran and found no flags under its rules. It does not mean every ancestor is proven. A tree where the scan has not run shows "not scanned", never the same zero.

That the item deserves a look, wherever it appears: a duplicate suggestion, a fantasy-line warning, a conflict. A flag points at something to review; by itself it is not proof that anything is wrong.

It is usually showing you a conflict it found between two of your own sources, not declaring your tree wrong. Open the conflict to see which source says what.

Correct the record it belongs to and attach the source that shows the right value. A correction with evidence behind it lasts; one that only overwrites a field does not.

Usually not. A rejected claim is kept as rejected, so the tree remembers that the idea was considered and ruled out. That memory is what keeps the same wrong claim from returning unchallenged.

Within what the origin record kept, yes. Every claim carries the import job or the manual edit that produced it, so a fact can be traced back to the file or the edit that introduced it.

Yes. Competing claims on the same fact surface as a conflict both of you can see, instead of one edit silently overwriting the other.

Yes. Reliable sources can record different information through ordinary error, memory or a real change over time. A conflict is not evidence that one source is bad.

Yes, when the clues are independent of one another and consistent. Several evidence links supporting the same claim can move it towards verified even if none would on its own.

Yes. Ten copies of one unsourced tree are not ten independent sources; they trace back to a single claim. One primary record can outweigh all of them.

Yes. Usefulness depends on what the record contains and who gave the information, not on which document is older. A death certificate can carry a wrong birth date despite being an official record.

No. A shared place is supporting context. It strengthens a case only beside matching names, dates and relationships.

No, though it supports a broader case. The same trade is one more consistent detail among several, not proof on its own.

No, but it may support a household reconstruction. People at one address could be a family or simply boarders, so it is a lead to investigate, not a conclusion.

Yes. Ages vary across historical records, so one wrong age is common and does not on its own mean the record describes a different person.

Not automatically. Judge identity across all the relevant details together. One wrong field does not undermine the rest of a record.

The Genealogy Evidence Agent can point at the gaps the engines already found in your tree: disconnected branches, open conflicts, people without relatives. It reads those results; it does not invent leads beyond what has actually been computed.

The reader that takes a source's text and proposes facts from it, dates, names and relationships, as candidates. Each one still has to be linked back to the source and reviewed; none is accepted blind.

No. It proposes facts read from the record; the record stays the evidence. An extracted fact is only as good as the citation that points back to where it came from.

It can propose facts from any text you give it, register pages included. The original image or transcription remains the evidence a citation points to, not the reading of it.

Yes. A family letter and a captioned photograph are document types in their own right, attachable to a person and usable as evidence, not decoration.

The research assistant for your tree, its evidence, its conflicts and your open questions. It answers from tool results over your data and from these help pages, not from general chat memory.

No. It fetches the specific evidence a question needs through its tools, and only what it is allowed to see. It does not assume it already knows your tree from the conversation.

No. It never invents a person, a link or a path a tool did not return. A finding it cannot show you is reported as unavailable, not filled in.

Yes, and often it is the right answer: the platform has not computed something yet, or the evidence does not settle the question. It says so instead of guessing to sound useful.

Yes. It traces a relationship back to the assertions and the evidence behind it, because every relationship claim here is explainable through its reasoning and linked evidence.

Yes. It surfaces a real conflict on that claim with the competing assertion and the evidence on both sides, not only what already stands.

No. Hints and community matches are suggestions to review, never proof, and the assistant reads them with that status attached.

That the tree is reasonably well documented. The grade measures completeness, not accuracy, so a B does not say the genealogy is proven.

No. The grade measures how well documented the tree is, which is a different question from whether it is right. A well-sourced tree can still contain an error the grade cannot see.

Yes. A bigger GEDCOM usually brings in people and relationships without citations, which lowers the coverage share even though your already-sourced records did not change.

Only the people you have given access to, through an invitation or a public link you created. Nobody else can open it.

Yes. A person marked living gets extra protection, including being withheld from the assistant's answers and shown without dates on a public link.

No. Your trees and your DNA are never sold, never shared with advertisers and never used to train AI models. The privacy notice states this in full and is the document that governs it.

Yes. Erase account, on the account page, erases your DNA kits and uploaded files right away, signs you out and removes your trees and people from the site. It cannot be undone. It is separate from deleting a single tree.

Yes. Erasing the account starts right away: DNA kits and uploaded files are erased, you are signed out, and your trees and people are removed from the site. The page shows when it is finished. Export first if you want a copy.

Yes. A DNA consent is its own record in your account, separate from the data it covers, so granting or withdrawing it does not require deleting the kit or the file.

No. It never reaches out to anyone on your behalf. Inviting a relative to a tree is something you do explicitly.

Yes. From the tree's Sharing page you invite someone by email as a viewer or an editor; they accept from the email and work on the same tree.

Use the feedback button in the top bar. It opens a form for a bug report or a suggestion, with the page you were on attached.

What you were doing, what you expected and what happened instead. The form attaches the page you were on; a screenshot helps.

Yes. The same feedback form takes suggestions, not only bug reports.

Yes. Feedback from people using the product is what surfaces the missing workflows and the confusing screens that testing alone misses, and it is read by the team.

There is no changelog page. To know whether something specific changed, ask through the feedback form.

Because these pages are kept in step with the product. When a feature changes, its help section changes with it instead of describing an older version.

Yes. The free plan lets you work with one tree, the GEDCOM Doctor and the Anti-Fantasy detector without a card.

Tree count and the heavier analysis follow the plan: Free holds one tree, Pro ten, Premium any number, and the engines that read a whole large tree run on the paid plans. Large trees cost real processing and storage, and the plans reflect that.

No. A claim's status depends only on its evidence, never on your subscription. Paying for more trees or capacity does not change what counts as verified.

Yes. A downgrade takes effect at the end of the period you have paid for rather than the instant you ask, and the billing page shows the exact date.

A failed payment gets a grace period before anything changes, and a plan drop lowers what runs and how many trees you may keep rather than deleting anything at once. The billing page shows your account's status and dates.

Evidence first, relationships second.

No. A different spelling of the same name is one of the signals the duplicate finder already uses. It is a reason to review a pair, not to split one person into two records.

Because a document's default weight is a starting point, not a rule for picking a winner. Deciding which date is right is a research decision, and the platform shows both sides and leaves it to you.

No. The rejected assertion leaves the main view but stays in the tree's history with its origin and reasoning, so the same idea arriving later from another import meets a real decision instead of a blank.

Yes. Like birth year and place, a matching death date raises the score when it lines up with the rest, above all with matching relatives and geography.

That can be a duplicate, or two siblings with similar names. The finder lists it as a candidate either way and shows the differing evidence side by side so you can tell which.

Because separating two people who were wrongly merged is far harder than making the right call once. That is why a pair already documented as parent and child, or as siblings, is refused even in the one-click bulk merge, and every other merge still needs your click.

Only when the documents and the DNA agree. DNA alone gives a range of plausible relationships, not one confirmed one.

Try another spelling first: search follows sound-alike variants across languages and alphabets, but an unusual transliteration can still slip past. If the tree was just imported, check that indexing has finished before concluding the person is missing.

A re-upload creates a separate tree instead of overwriting the one you have, so you are probably still looking at the original. Check which tree is open, or compare the two in Reconcile trees and decide what to carry over.

They are two separate records: a duplicate candidate not yet reviewed, or two relatives with similar names. The Duplicates page is where you tell which.

The relationship exists as a claim, but the assertion behind it has not reached verified. It may be a hypothesis, an import nobody has reviewed yet, or a claim waiting for a citation. It is not an error.

Whatever the engines have already flagged in your tree: a conflict, a brick wall, an unverified relationship. Those are gaps found in your specific tree, not a generic checklist.

Not necessarily. The oldest person in a tree is usually the least documented, so a brick wall or a conflict closer to you is often the more productive place to start.

No. An imported relationship arrives as a claim, not as verified, and stays that way until evidence or your review moves it. Treat it as the platform does: worth reviewing, not settled.