family_history_research v1.0.0

name: "family_history_research" description: "Plan genealogy research that holds up: frame one provable research question, plan census, vital, church, land, probate, and military searches by locality, build layered citations, weigh conflicting evidence under the Genealogical Proof Standard, and keep a research log that records negative searches. Ships a GEDCOM parser and validator, a citation builder for common record types, and a worked proof case. Use when tracing ancestors, testing a parentage or identity claim, sorting same name people, working a brick wall, parsing or checking a GEDCOM file, or writing a proof argument."

Family History Research

Purpose

Family trees copied from other trees fail in a predictable way: a same name person gets merged in, no one can tell where a date came from, and the error spreads. This skill runs research the other way. One question at a time, a plan written before searching, every fact tied to a citation, conflicts resolved in writing, and a log that records the searches that found nothing as well as the ones that found something.

The standard behind it is the Genealogical Proof Standard from the Board for Certification of Genealogists: reasonably exhaustive research, complete and accurate source citations, thorough analysis and correlation of the evidence, resolution of conflicting evidence, and a soundly reasoned written conclusion. A conclusion counts as proved only when all five hold.

Workflow

1. Frame one question that can be proved or disproved. Name the person, the fact or relationship in dispute, and the place and period. Good: "Who were the parents of Margaret Ellis, born 1884 in Dayton, Ohio?" Bad: "Research the Ellis family." One file, one log, and one conclusion per question.

1. Write down what is already claimed and where each claim came from. Separate records you have seen from family stories, unsourced tree data, and transcripts someone else made. Treat every unsourced claim as a hypothesis to test, including your own earlier work.

1. Build the FAN list before searching. FAN stands for Friends, Associates, and Neighbours, a term coined by Elizabeth Shown Mills for cluster research. List known kin, in-laws, witnesses, bondsmen, godparents, neighbours, fellow congregants, and men who served in the same unit. When direct records run out, the answer usually sits in a FAN record.

1. Write the research plan by locality, not by website. For the place and period in the question, list the records that could answer it: census, vital records, church registers, deeds, probate, court, tax, military, directories, newspapers, cemetery. Note the custodian for each one and the years it covers. A database is a way to reach a record, not the record itself. Use references/record-types.md for what each record type can and cannot prove, its usual custodian, and its weak points.

1. Check the calendar traps for the place and period before you plan dates. United States federal census: taken every 10 years from 1790, public through 1950 under the 72 year restriction in Public Law 95-416. Census before 1850 names only heads of household. Most 1890 schedules were destroyed in a 1921 fire. State vital registration for births and deaths became common around 1890 to 1915, so earlier events often exist only in church records. County boundaries and record custodians change over time, so confirm the county that held the place in the year of the event.

1. Search in plan order and log every search the same day, including failures. Use the bundled tool to start and keep the log:

python3 scripts/genealogy_tools.py log-init research-log.csv python3 scripts/genealogy_tools.py log-add research-log.csv --date 2026-10-12 --repository "Montgomery County Probate Court" --record "birth register 1880-1885, Ellis and variants" --question "Who were Margaret Ellis parents?" --result negative --notes "No entry. Register incomplete for home births in this period."

A negative entry must say what was searched, for which years and name variants, and how complete that record set is. "Not found" with no scope is worthless to the next search, which may be yours in six months.

1. Capture a full citation while you are looking at the record, not later. Ask five questions: who created it, what is it, when was it created, where is it held, and how did you access it. Build the citation with the tool and then adjust the wording to match the record in front of you:

python3 scripts/genealogy_tools.py cite census --year 1900 --county "Montgomery County" --state Ohio --place "Dayton, Ward 4" --ed 87 --sheet 6B --dwelling 118 --family 132 --person "Margaret Ellis" --provider "FamilySearch" --accessed "12 Oct 2026" --microfilm T623 --roll 1308 python3 scripts/genealogy_tools.py cite vital --jurisdiction "Ohio Department of Health" --record-type "death" --certificate 45231 --person "Margaret Ellis Bauer" --event-date "3 Nov 1962" --repository "Ohio History Connection" --repository-place "Columbus, Ohio" --accessed "12 Oct 2026"

The tool also builds church, land, military, and probate citations. Cite the record and the specific person entry, not just the collection or the website.

1. Grade every item before you weigh it. Source: original or derivative. Information: primary, from a participant or eyewitness close to the event, or secondary. Evidence: direct, indirect, or negative. A death certificate is primary information for the death and secondary information for the birth and parentage on the same page, so grade the information item, not the document as a whole.

1. Correlate before you conclude. Line the items up in a timeline and test them against each other: ages across censuses, places in sequence, occupations, neighbours who recur, names of children who often repeat family names. Use the tool to pull a timeline from a GEDCOM file and catch date conflicts:

python3 scripts/genealogy_tools.py parse tree.ged python3 scripts/genealogy_tools.py validate tree.ged python3 scripts/genealogy_tools.py timeline tree.ged @I1@

The validator checks that a file starts with HEAD, ends with TRLR, keeps level numbering sane, and points every family and source reference at a record that exists. Run it on any GEDCOM you receive or export before you trust the data in it.

1. Resolve every conflict in writing. When two records disagree on a name, date, or place, say so, weigh the informant, the time between event and recording, and whether the record is original or a copy, and state which value you accept and why. A conflict you explain strengthens a case. A conflict you hide, or never notice, breaks it later.

1. If direct evidence runs out, work the cluster. Search the FAN in widening rings: known kin first, then same surname households in the same place, then associates, then associates of associates. Deeds, probate bonds, marriage witnesses, baptism sponsors, and census neighbours are where cluster links show up.

1. Write the conclusion even when the answer is "not yet proved". A proof argument states the question, summarises the evidence, resolves the conflicts, and gives the answer with its reasoning. A research report for an open case states what was searched, what was found, what the negative searches rule out, and the next steps. Follow the shape in references/worked-proof-case.md, which takes one question from plan to conclusion and shows a negative search and a conflict handled in the open.

1. Run the log check before writing. python3 scripts/genealogy_tools.py log-check research-log.csv counts found, partial, and negative entries and flags found entries with no citation. Fix those gaps first. A conclusion built on uncited finds is an opinion.

Output Contract

For a research task, deliver:

• The research question, stated in one sentence.
• A short list of prior claims, each marked with where it came from and whether you have seen the record.
• The research plan: records to search, in order, with custodian and coverage years for each.
• The research log in CSV, with one row per search, including negative results with their scope.
• A citation for every record used, in the layered form the citation builder produces.
• An evidence table: one row per information item, graded for source, information, and evidence type.
• A conflict list: each disagreement, the resolution, and the reason.
• The written conclusion or, for an open case, the report of what the searches rule out and what comes next.
• If a GEDCOM file is involved, the parse summary and the validator result.

For a GEDCOM check only, deliver the validator verdict and the parse summary, and name any broken references, missing HEAD or TRLR, or date conflicts by record ID.

Operating Rules

• Never merge two same name people on name match alone. Require agreement on place, time, and at least one associate, or a record that links the two identities directly. Same name men in one county are often cousins, and fathers and sons share names across a census boundary.
• Never copy a date, place, or parent from an online tree, index, or transcript into a conclusion without seeing the underlying record image or the original. Indexes drop details and misread handwriting. A transcript is a lead, not evidence.
• Never delete a negative search because it found nothing. Negative evidence and a clean record of where you already looked are part of reasonably exhaustive research. They stop repeated work and they bound what a conclusion can claim.
• Never present an age from a census as an exact birth date. Convert it to a birth year range, carry the range through the work, and narrow it only when a record made near the birth supports a tighter date.
• Never publish identifying details about living people, including full birth dates, addresses, and family relationships, without their consent. Treat living people in shared files as private placeholders.
• Keep spelling as written in the record inside the citation and the log, and put your normalised form beside it in brackets or notes. Search under variants, including initials, nicknames, and the ways an enumerator or clerk could hear the name.
• Date every log entry and every access date in a citation with the day you actually did the work. Backdated or undated logs cannot show that a search was exhaustive.
• When records for the place and period do not survive, say which records are lost, when, and what substitutes you used. A known record loss explains a gap. Silence about it reads as a search that never happened.
• Stop and report rather than guess when the evidence supports two different answers about equally. State both hypotheses, the evidence for each, and the specific record that would separate them.