Research Logs Track Where You Looked. Nothing Tracks What You Found.

In March you found an 1878 marriage record. You transcribed it, confirmed the bride and groom, and added them to your tree. The record also named two witnesses, the bride's father, and a priest.

In August you find a different record, in a village forty kilometres away, with one of those witness surnames on it.

You will not make the connection, because the March record's witnesses exist only in a scan and a transcription file that you have not opened since March, and your tree only ever knew about the bride and groom. The information is on your own hard drive, but your system does not know it.

This is the most common failure in genealogy research and it has nothing to do with archives, handwriting, or access. It is a workflow problem, and it is worth being precise about its shape.

The two things your system stores

Nearly every genealogy setup, from a shoebox to a professional's Airtable base, stores two categories of thing.

Searches. Where you looked, when, in what collection, and whether you found anything. This is the research log, and the entire established genre of genealogy organisation is about it: the printable templates from Family Tree Magazine and Cyndi's List, the Airtable systems professionals build, and purpose-built tools like Goldie May, which logs the pages you visit into a project and has since added AI that reviews an objective for gaps and suggests collections you have not searched. The purpose of the layer is to stop you repeating a search you already ran and to record the searches that came back empty.

Conclusions. Who you have decided is related to whom. This is the tree, and it is what Ancestry, MyHeritage, FamilySearch, RootsMagic and every GEDCOM file hold. A tree is an assertion set. It says this man is that woman's father, and it hangs sources off that claim as support.

Both are worth keeping, and the missing layer sits between them.

The layer nobody keeps

Between the search and the conclusion sits the evidence: every name, date, place, occupation, age and stated relationship written in every record you have already read.

That layer is enormous and almost nobody holds it in queryable form.

Consider one ordinary Catholic baptismal entry. It names the child, the father, the mother, the mother's maiden name, two godparents, sometimes a godparent's spouse, the officiating priest, and a house number. That is seven or eight people and a location, in four lines of Latin. Of those, most researchers record one, occasionally three.

The other five are in the scan, and possibly in a transcription, but not in anything that will raise its hand in six months when a name comes back around. Functionally they are lost, and you will pay to find them again.

Multiply by every record you have processed. A researcher three years into a project has typically read several hundred records and entered a fraction of the people named in them. The gap between what you have read and what your system knows is usually wider than the gap between what your system knows and what you have not yet found.

Why the gap exists

It exists because it used to be rational.

When reading a record was the expensive step, being selective about what you extracted was correct. If a page takes an hour to transcribe and another twenty minutes to enter, you extract the two people you came for and you move on. Recording eight people per record, with their stated ages and their relationships to each other, would have tripled the work for people you did not care about yet.

That calculation has changed. Transcription is now the cheap part of the process, and it got cheap fast. FamilySearch's full-text search went from about a hundred million images at launch in 2024 to about 2.5 billion two years later, with roughly a billion more added each year. Ancestry shipped document transcription in April 2025, MyHeritage shipped Scribe in March 2026, and Transkribus has been doing this for institutions for years. Whatever else you think about those tools, the direction is not ambiguous: reading a record is no longer the constraint.

The workflow did not update. Most researchers now transcribe faster and still extract selectively, into the same tree they were keeping before, which means the transcription capacity mostly goes into producing more files they will not re-read.

The cost that does not show up

Reading records is linear work. Ten records take ten times as long as one. If you double your reading speed, you halve that cost, and the relationship holds forever.

Reconciling records is not linear. Every new person you add has to be considered against everyone you already have, because the question "have I seen this person before" is asked against the whole corpus. Two hundred people in your files means roughly twenty thousand possible pairs. Four hundred people means roughly eighty thousand. You doubled the corpus and quadrupled the checking.

You do not feel this as a wall. You feel it as research that gets slower the better it goes, which is easy to misread as the records getting harder. Sometimes they are. Often what has happened is that your corpus outgrew your memory, and memory was doing the reconciliation.

The uncomfortable consequence is that making transcription faster makes this worse. More records read, at the same extraction rate, produces more unreconciled material. The linear step got cheaper and the quadratic step got bigger.

Which direction the checking runs

There is plenty of automation aimed at this, and it all runs the same way round.

Disclosure, since it is our table: we make the last row. KleioBase is an AI research companion that turns scattered historical records into one connected family archive: it reads handwritten records in more than 100 languages, turns every person named in them into a profile, and checks each new record against everything you have already read. We went looking for another product to put in that row and did not find one that runs the check for you. The closest is Clooz, which indexes your documents so that you can cross-check them by hand. That gap is the whole reason this article exists.

Every row but the last starts from a conclusion you have already committed to and looks out at material you have not seen. That is a useful thing to automate and the platforms are good at it. It is also the easier problem, because the corpus on the other side is indexed, owned by one company, and identical for every user.

The last row is the one that compounds, and it is the one almost nothing runs. It starts from the record in front of you and checks it inward, against your own accumulated material, including every person you transcribed and never promoted into your tree: the witness, the godparent's spouse, the neighbour who signed. The corpus on the other side of that comparison is different for every researcher, which is why no record platform has an incentive to build it and why it is worth more to you than a hint is.

The two directions do different jobs. Outward checking tells you where to look next. Inward checking tells you that you already looked, five months ago, and did not notice.

The methodology everyone recommends and almost nobody runs

There is a well-established answer to hard research problems, and it has been the standard advice for decades. Elizabeth Shown Mills named it the FAN principle: friends, associates and neighbours. When you cannot trace an individual directly, you trace the cluster around them, because people moved, married, witnessed and settled in groups.

Ask any experienced genealogist how to break a brick wall and cluster research will be in the first three answers. Now ask how many of them systematically record every witness, godparent and informant they encounter.

What stops people is cost. Cluster research requires the layer described above, held for years before it pays off, and building it by hand costs more than most brick walls are worth.

That is a clerical constraint rather than an intellectual one, and clerical constraints are the kind software removes.

A diagnostic

Before concluding that this is your problem, test it. Five questions, answered honestly about your own current setup.

1. Can you list every record you hold that mentions a given surname, in under a minute, including records where that surname belongs to a witness rather than a principal?
2. Do you know how many distinct people are named in your files but do not exist in your tree? The test is whether you could find out at all, more than the number itself.
3. When you open a new record, what do you check it against? Your files, or your memory of your files?
4. How often do you re-open a record you have already read, to remind yourself what was in it?
5. Can you state what you have ruled out? That means what you have looked for properly and established is not there, which is different from what you have simply not found. That distinction is negative evidence, and it is only usable if it is recorded.

If questions 1 and 2 are answerable, your bottleneck really is finding and reading records, and you should spend your money on access and your time on paleography.

If they are not, then more records will not help you as much as you expect, because you are not using the ones you have.

What an evidence layer actually has to do

Suppose you decided to fix this. Tool-agnostic, these are the requirements. They are worth holding onto because they are also the right questions to ask of any product that claims to solve it, including ours.

Every person mentioned becomes an entity, not a note. The witness on the 1878 marriage has to be a thing the system knows about, with a name, an age if stated, a place, and a link back to the record and the image. A transcription that sits in a text file is not this. Neither is a scanned PDF with searchable text, because search finds strings, not people.

Reconciliation happens on ingest, and it runs inward. Per the direction table above, the check has to fire when the record enters, without you deciding to run it, and it has to run against everything you have already read. If it requires you to remember to look, it has the same failure mode as memory, which is the thing it was supposed to replace.

Uncertainty survives. Two records giving different ages for the same man is information. A system that silently picks one, or averages them, has destroyed the evidence and handed you a conclusion. The contradiction should be visible and should stay visible until you resolve it deliberately.

Extractions stay attached to their images. An AI reading of a handwritten page is a reading, not a fact. It can be wrong about a name, and names are where it is most likely to be wrong, because unlike the formulaic parts of a record a proper noun has nothing around it to constrain the guess. If you cannot get from a stated fact back to the pixels in one step, you cannot cite it and you should not trust it.

The system can say what is missing. Given a person's known dates, place and jurisdiction, the records that should exist are largely computable. A man who married in Kovno gubernia in 1878 and died in 1911 should have a death record, and the archive that would hold it is knowable. This is deterministic work rather than a matter of AI judgement, and it turns an open-ended question into a list. Several tools now attempt some version of this, with varying scope.

The tree becomes an output. If the evidence layer is real, the tree stops being the thing you type into and becomes a view of what the evidence supports.

Your data comes out in a standard format. Whatever the system holds, you should be able to leave with it. GEDCOM is the only format the field agrees on, so import and export in it is the minimum bar.

What that looks like on the 1878 record

Go back to the marriage from the first paragraph.

With an evidence layer, processing it produces seven profiles rather than two. The bride and groom, the bride's father, both witnesses, the priest, and the groom's father if he is named. Each one carries the record, the image, and the age or occupation the record states, and none of them are asserted to be related to anyone except as the document itself says.

Five months later the second record arrives with a matching surname on it. The check runs on ingest, and what comes back is a flag rather than an answer: this surname, in this district, appears on a record you processed in March, as a witness, aged 34. That is a lead you would not otherwise have had, and it costs nothing to produce because the work was done in March.

This is plain bookkeeping. The reason it does not happen is that the bookkeeping is too expensive to do by hand, which is a statement about clerical cost rather than about research skill.

Where this approach goes wrong

Four failure modes, stated up front, because a page that describes only the upside is an advertisement.

Automated matching produces false positives, and a bad queue is worse than no queue. Match confidence is not uniform. High-confidence candidates are usually right; low-confidence candidates, particularly ones based on name similarity alone, are usually wrong. A system that shows you everything it can think of will burn more of your time than it saves, and it will burn your trust first. Judge any matching feature on what it declines to show you.

Suggestion engines overproduce. The same is true of gap detection and research hints. It is trivial to generate a thousand things you could look at. The hard problem is ranking, and any tool in this space, ours included, is more likely to be bad at ranking than bad at generating.

It does not do the adjudicating. When two records conflict, deciding which is right is analysis, and analysis is yours. The Genealogical Proof Standard has not changed, and the Board for Certification of Genealogists' 2024 interpretation is explicit that AI may not transcribe, translate, abstract or analyse the supplied document in certification portfolio work. A system that surfaces a conflict has done its job. A system that resolves one quietly has done damage.

Garbage in scales too. Automatic cross-referencing across a corpus with a bad transcription in it will propagate that error further and faster than a manual workflow would, which is why the image belongs next to the transcription.

What we built

KleioBase is built to this shape, and this article is the reasoning behind it.

Records go in through the upload workspace, in whatever language and script they are written in. Every person named in a record becomes a profile in a knowledge base, witnesses and godparents included, each one carrying the record and image it came from. Every new upload is checked inward against everything already there, across name spellings and languages, and the candidates come back scored rather than merged. Conflicts between records are flagged instead of resolved. An Expected Records engine computes which documents should exist for a person given their dates and jurisdiction, and the Research Companion answers questions against the knowledge base with citations back to the records. The family tree is drawn from what is in the knowledge base rather than typed in. GEDCOM goes both ways.

What it is not: it is not a record database, it does not hold anyone's archive, and it does not decide what is true. It reads what you give it, keeps all of it, and tells you when something you already have is relevant to something you just found.

Where to start, whatever you use

None of this requires our software or anyone's.

Start by changing one habit: when you process a record, record every person named in it, not only the ones you came for. Witnesses, godparents, informants, the neighbour who signed. Give each one the record they came from. This is more work per record and it is the only version of this that compounds.

Then make your evidence queryable by person rather than by file. A folder of PDFs named after their collection is a filing system. A table where one row is one person-mention is a research instrument, and you can build a usable version of it in a spreadsheet in an afternoon.

Then record what you ruled out, with enough specificity that future-you can tell a search that failed from a search that was never run.

Do those three things and the tooling question becomes secondary, which is the correct order to take it in. The reason to automate it is that the manual version is expensive enough that almost nobody sustains it, and the people who do sustain it are the ones whose research does not stall.

If you want the shorter version of what changes when the evidence layer exists, our post on the family tree that shows what is missing is the same argument told through one feature. For where AI helps and where it does not, see how AI is transforming genealogical research.