# A family history book — records, stories and the questions still open Recipe No. 28, Home and family. From The know.sh Cookbook: https://know.sh/cookbook/family-history - For: a family historian writing up four generations, from the ship manifest to the people still living - You bring: a genealogy program or a tree on a records site, a folder of downloaded record images, and the notes you have kept on who said what - You get: a written family history in one document per family line, every claim resting on a record, every open problem filed as a question, an index of names and places, and a link the family can read - Time: an evening for your assistant to build the lines, a weekend to check them, then an evening per record set; years, if you are honest about it - Keep it: private while you work; share one document by a read-only link A family tree tells you who. It does not tell you why the ages in two censuses disagree by three years, which of three spellings of the village is right, or why great-grandfather's naturalisation took eleven years. That reasoning usually lives in a notebook, a dozen browser tabs and the memory of the one person who did the research. This recipe gives the reasoning a home. Each family line is a research document; each record you have seen is an Evidence finding that says what the record states, what it supports and what it does not, with links to the record itself. Every problem you have not solved is a Question finding, so the gaps are as easy to find as the facts. The index at the back gathers the surnames and places that recur as you write. When a line is ready, a link lets cousins read it, with the findings about living people left out. Your tree stays in your genealogy program and the record images stay on the sites and drives that hold them. know.sh holds the write-up: what you found, how you know, and what is still open. ## What you will use - **Shelf**: One shelf for the family, *The Marek family*, with a line on which lines and which years it covers. - **Research document**: A document per family line or ancestral couple, with the living generations in a document of their own. - **Finding**: An *Evidence* finding per record, its sources in order; a *Question* finding per open problem; the records that settle identity marked **Key**. - **Your AI assistant**: Whichever assistant you use builds the lines from your research log, researches where records survive, and flags conflicts between records. - **The editor**: Where you check each finding against the record image, fix misreadings, reorder by date and write the overviews yourself. - **Proposed notes**: Your assistant leaves a proposed note, with **Accept** and **Dismiss**, where two records disagree on an age, a date or a place. - **The A–Z index**: The index of surnames, parishes and towns, built from the names that recur in finding titles and first lines. - **Public link**: A read-only link per family line, with findings about living people left out and a password for the family. ## Method ### 1. Give your assistant the research log Connect the assistant you already use, Claude, ChatGPT or a local model, to know.sh, then give it your research log and transcriptions. Files go to the assistant itself; know.sh has no upload. Leave out anything about living relatives that you would not want passing through the assistant's provider. Ask it to build the shelf *The Marek family* with a document per line, *Jan and Anna Marek — from Spiš to Cleveland*, *Joseph and Helen Marek — Slavic Village, 1913–2002*, *The Kowal line*, and a separate *The living generations* that you will never share. Every record becomes an *Evidence* finding titled person, record, year and place, with three headings: **What it says**, **What it supports**, **What it does not settle**. Every open problem becomes a *Question*. ### 2. Check every finding against the record An evening's building gives you dozens of findings, and every one is a first draft. Open each line, press **Edit**, and read each finding beside its record image. Put back the misspellings it tidied away, correct misread ages, and add the source links in order, the image first. Drag the findings into date order, fix any type that is wrong, and mark as **Key** the records that fix identity: the manifest, the naturalisation, the marriage. Then write each overview yourself, two or three paragraphs on what the records add up to. The story is yours to tell, not the assistant's. ### 3. Give every brick wall a Question finding An open problem deserves a page as much as a fact does. File each one as a *Question*: "Where in Spiš was Anna Novak born?" Under it, list what you have already searched and found nothing in, because a negative search is a result and you will not remember it in two years. End with the record that would answer it, if it exists: a parish register, a passport application, a church marriage entry. Questions keep the history honest. A cousin reading the link sees "we do not know yet", rather than a guess repeated until it hardens into fact. ### 4. Ask your assistant where the records are Ask about records, not people: "What naturalisation records survive for Cuyahoga County, Ohio, 1906–1930, and where are they held?" Ask your assistant to research it on the web and file what it finds as a new document on the shelf, one finding per record set, each with its source links. This needs an assistant with web search; Claude and ChatGPT have it, and many local set-ups do not. Read that document as a list of leads. The assistant reaches the open web only, not your subscription sites, and it can cite a page that does not say what it claims. Open every link, and let nothing into a line document until you have seen the original record. ### 5. Let the conflicts show Records disagree. Ask your assistant to read *Jan and Anna Marek*, compare every age, birth date and birthplace across its Evidence findings, and leave a proposed note wherever two records conflict. The notes arrive in the margin with a dashed rule; **Accept** the ones that are real and **Dismiss** the rest. Do not settle a conflict by editing the older finding. Write a new finding, filed as an *Insight*, that weighs the records against each other and says which you trust and why: a manifest filled in by a clerk at Bremen against a census answered by a neighbour. The reasoning is the part of a family history that no tree shows. ### 6. Steer the index with names and places Open the shelf's index and read it. You want every surname and every parish and town. Finding titles and first lines feed the index one word at a time, so put surnames, married and maiden, and parish names in titles: "Anna Novak Marek on the 1911 manifest", "Baptism at Lipník, Spiš". A maiden name buried deep in a body will not reach the index; Look up (⌘K) still finds it. Highlight the lines that carry the weight: the manifest entry naming a village, the obituary listing survivors. Highlighted findings show their numbers in bold in the index, which is where a cousin looking for their own grandmother will start. ### 7. Share the dead, not the living When a line reads well, press **Share** and add a password; send the password to the family separately from the link. Copy the link the moment it appears; know.sh shows it only once. Then open each finding that mentions someone alive, a DNA match, or a story someone asked you to keep, and leave it out of the link from that finding's own page. Readers see the overview and the findings with their sources, never your notes or highlights. Corrections come back by phone or email, and you file them. If you replace the link, its exclusions reset: check them again before you send the new one. ## Prompts to try Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, read every Evidence finding in the document *Jan and Anna Marek* on my *The Marek family* shelf. Make a table of each age, birth date and birthplace the records give for Jan Marek, with the finding number and the record. Where two records disagree, leave a proposed note on the later finding naming the earlier one. Do not change any finding. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Search the web: what naturalisation records survive for Cuyahoga County, Ohio, from 1906 to 1930: declarations, petitions and certificates? For each record set, say which court or archive holds the originals today, whether an index or images are online and free, and give the link. Say where sources disagree, and file it in know.sh as a new document of leads on my *The Marek family* shelf, one finding per record set. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, list every Question finding on the Marek family shelf, with what each says has already been searched. Group them by the kind of record most likely to answer them, and file the result as a new document called “Research plan, winter 2026”. Do not mark any question as answered. ## Variations - Link each line to the [family cookbook](/cookbook/family-cookbook): the pound cake recipe points to the woman who baked it, and the cookbook becomes a way into the records. - Interview the oldest relatives while you can, with their consent, and keep the interviews as an [oral history](/cookbook/oral-history); cite the interview as a source in the finding it supports, and mark it as memory, not record. - Write a house history instead of a family one: a document per owner, the deeds, directories and censuses as Evidence, and the questions a title search leaves open. - Before the reunion, ask your assistant for a quiz on *Jan and Anna Marek*: five to ten questions on the dates and places, each citing its finding, taken in know.sh or the iOS app, so the story you tell at the table matches the records. ## Where it falls short - know.sh holds words, not images. There is no upload, so the record images stay on the records sites or your own drive; link to them as sources and transcribe the lines that matter. - It is not a tree. There is no pedigree chart, and no GEDCOM file goes in or comes out. Keep the tree in your genealogy program and the reasoning here. - Web research needs an assistant with web search, and it reaches only the open web, not subscription databases. An assistant that reads a record image for you can misread old handwriting; check every transcription. - Smaller local models call know.sh’s tools less reliably. Whatever assistant you use, Revisions shows every change it made, with **Restore**. - Cousins read; they do not add. Their corrections reach you by email or phone, and you file them, with the relative named as the source. ## A note on consent and the privacy of the living Get consent before sharing details about living relatives, and check every fact against the original record before it goes in a line document. Assistants make mistakes; a lead is not a record, and a transcription is not the image. Keep the living out of every link: names, birth dates, addresses, marriages and divorces, and anything from a DNA test, because every DNA match is a living person who did not agree to appear in your book. Adoption, parentage, illness, prison and cause of death can hurt people who are still here even when the person in the record is long dead; ask the nearest relatives before those findings are read by anyone else. Whatever you hand an assistant passes through its provider, unless you run a local model; keep the living out of what you give it, too. A public link can be forwarded. The password keeps it among people you chose, not among people they chose. Indexed under: Genealogy, Census records, Vital records, Living relatives, Conflicting evidence, Brick walls, Place names.