What "GPS-Compliant" Actually Means for Your Family Tree (And Why Most Software Ignores It)

If you've spent any real time in the genealogy community, you've run into the term "Genealogical Proof Standard" — usually shortened to GPS, usually mentioned by someone more experienced than you correcting a conclusion that looked solid but wasn't. Most consumer software acts like it doesn't exist. I wanted to write down what it actually means, concretely, and why I think it should shape how research software works, not just how research papers get written.

The five things GPS actually asks for

The Board for Certification of Genealogists defines it as five components, and none of them are complicated on their own:

1. A reasonably exhaustive search — not exhaustive in the impossible sense, but enough that you're not building a conclusion on the first record you happened to find.
2. Complete, accurate source citations — not just "Ancestry hint," but where the record actually lives, who created it, and how you accessed it.
3. Analysis and correlation of the collected information — actually comparing what different sources say, not just collecting them.
4. Resolution of conflicting evidence — when two sources disagree, you don't just pick one and move on silently.
5. A soundly reasoned, coherently written conclusion — you can explain why you believe what you believe, not just what you believe.

None of this is exotic. It's what a careful researcher already does in their head. The problem is that almost no software actually supports doing it — most of it is built around collecting facts, not reasoning about them.

Where the big platforms fall short

Ancestry, FamilySearch, and MyHeritage are genuinely good at the first problem: finding records. Hints, record matching, massive databases — that part works. Where they fall short is everything past that:

• A "hint" usually isn't a citation. It tells you a record exists and roughly what it says. It doesn't force you to record where you actually found it, in what collection, accessed when — the stuff you'd need if someone asked you to defend the conclusion later.
• There's no structured way to mark evidence as direct, indirect, or negative. A birth certificate and a wild guess about someone's age both just become "a fact on the tree," with nothing distinguishing how solid they are.
• When two sources disagree — and they always eventually do — most tools just let you overwrite one value with another. The conflict itself, and whatever reasoning resolved it, isn't preserved anywhere.

None of this makes those platforms bad at what they're for. It just means the actual proof-standard work — the part that makes a family tree trustworthy instead of just plausible — happens in your head, or in a separate document, or not at all.

Direct, indirect, and negative evidence, with an actual example

These terms sound academic but the idea is simple. Say you're trying to figure out when someone was born.

Direct evidence states the fact outright: a birth certificate that says "born March 12, 1866." One document, one clear answer, assuming you trust the document.

Indirect evidence requires you to combine information to get there. A census record doesn't give a birth date — it gives an age and a census date. "Age 44 as of the April 1910 census" implies a birth year of around 1865 or 1866, but you're doing the math, and that math can be off by a year depending on whether the birthday had passed yet.

Negative evidence is the absence of something you'd expect to find. If someone should appear in a census — they were alive, in that county, as far as every other record shows — and they don't, that absence is itself evidence. Maybe they'd died. Maybe they'd moved. It doesn't prove anything on its own, but it's a data point a careful researcher writes down instead of ignoring.

A real research conclusion usually leans on more than one of these at once — the birth certificate (direct) corroborated by the census-age math (indirect), with no contradicting negative evidence found. That correlation step is GPS component #3, and it's exactly the kind of reasoning that's hard to do well if your software only has room for "birth date: [single field]."

How this shows up in the actual product, not just the philosophy

This is the part I care about more than the definitions — what does GPS-aware software actually look like day to day?

Concretely, in Gather the Family: citations carry an evidence type (primary vs. secondary source) and an evidence quality field, not just a link to a record. When the AI extracts something from a document, it's a suggestion with a confidence score, not a silent overwrite — you're the one deciding whether it's solid enough to accept. And the review inbox has an actual "Data Conflicts" category — if two sources disagree on a date or a place, that shows up as something to resolve, not something that quietly gets lost the moment you edit a field.

I'm not going to claim this is a complete, formalized GPS-compliance engine — it isn't, and "GPS-compliant software" isn't really a certification that exists to claim in the first place. What I'm saying is narrower: the standard is a genuinely good description of what careful research looks like, and I think software should make that easier to do rather than easier to skip.

If you want to see how this compares across tools more broadly, the full comparison has the honest breakdown, including where GTF doesn't have an answer yet (there's no record database here — you'll still want Ancestry or FamilySearch for that part).