Quick Answer: Former USSR genealogy research means tracing ancestors through church books, civil registers, military files, and deportation and repression records across the 15 former Soviet republics and the Russian Empire. The open-source ex-USSR Kinship Research skill makes AI agents like Codex and Claude Code follow that discipline: originals first, every claim traceable, and conclusions held back until the evidence supports them.
Most family trees for people from the former Soviet Union rest on guesses. A surname matches, a village matches, and two trees get merged. Anyone who has tried to trace a grandparent through Ukrainian parish books or a deportation file in Kazakhstan knows how fast that goes wrong. The skill, published by Denis Shiryaev on GitHub, tries to stop that drift at the source.
Start With the Jurisdiction, Not Today's Map
Here's where most searches go wrong. People look up a village by its current country, but the record was created under the state that governed it on the event date. A birth in a Podolia village in 1890 falls under the Russian Empire. The same village in a 1940s file sits under Soviet Ukraine. Which archive holds the record depends on that historical jurisdiction and on who holds the record today.
The skill resolves every event to the state, province, district, parish, or civil registry as it existed on that date. Names move too. The same man might appear as a Ukrainian, Polish, Russian, or Yiddish form in different records, with patronymics that shift from one document to the next.
Calendars add another trap. Russia used the Julian calendar until 1918, and during the nineteenth century the gap with the Gregorian calendar was 12 days. A date written in old style can look like a different week when you compare it with a Western source. Mismatched dates are a common reason two correct records seem to describe different people.
Originals First, Trees Last
The conventional advice is to start with a tree-merging site because it's fast. The skill inverts that order. Its source hierarchy puts original scans first, then official catalogs and indexes, then published document collections. Trees and forums come last, and they count only as leads.
The reason is structural. A tree node usually copies a claim without its source, so one wrong birth year can spread across dozens of profiles and look like confirmation. When you go back to the parish entry, you can see who wrote it, when, and under what spelling.
In practice, the agent might find a film number in FamilySearch for a parish in the 1890s and then read the births for a surname by hand. That's slower. It's also the only way to know what the register actually says.
Statuses Instead of Percentages
Most genealogy tools give you a confidence score. The skill refuses to. A percentage hides which evidence produced it, and it invites you to add points without asking whether the points are independent. Instead, each claim gets one of six explainable statuses:
| Status | What it means | Typical trigger |
|---|---|---|
| hypothesis | A working idea with no linked artifact | A matching surname and village alone |
| single-source | One artifact supports the claim | One baptism entry naming the father |
| corroborated | Two artifacts from different independence groups agree | A parish birth entry plus a military card naming the same father |
| strongly-corroborated | Several independent groups agree and nothing conflicts | Parish, civil, and military records converge on one parent pair |
| contradicted | A reliable artifact conflicts with the claim | A dated record places the person in another district |
The status depends on the independence group. Copies and mirrors of one record share a group, so a photograph of a register page and the indexed transcription of that same page don't count as two proofs. The audit script enforces this. A group counts only when a cited artifact actually belongs to it, so you can't declare corroboration into existence by listing extra sources.
This is the part practitioners often skip. Two websites showing the same entry are one piece of evidence, not two.
Namesakes Stay Separate Until Proven Otherwise
Common names in Russian and Ukrainian parishes repeat constantly. Several men named Ivan Kovalenko may have married in the same decade within a few miles of each other. Merging them creates a fake ancestor, and that error pollutes every descendant you add later.
The skill handles this with identity resolution. Each candidate gets a separate person_id until distinguishing evidence appears. Useful separators include a house number, named parents, godparents, an exact birth date, or a military unit. A shared name is never enough to merge.
Here's the counter-intuitive part: keeping two people separate is often the more useful result. A report that says "these two records may describe different men, and here's what would decide it" gives you a concrete next search. A forced merge gives you a tidy tree that's wrong.
Audit Before You Write the Conclusion
The skill's workflow ends with checks, not prose. A typical case runs in this order:
- Run
init_case.pyto create a case folder outside the skill's Git checkout. - Save each scan and run
hash_artifact.pyto record its SHA-256 hash. - Log every search in the CSV search log, including the failed ones.
- Run
audit_evidence.pyto check referential integrity and weak corroboration. - Write the final report, then build a PDF with
build_pdf.py.
The audit script checks that every ID cited in the report exists in the registers and that every status matches them. It also summarizes what remains uncorroborated or marked illegible. It needs only Python 3 and the standard library, so you can read every check it performs.
Don't skip step 4 because the report looks finished. A report can read well and still cite a record that was never saved.
Requests to Archives, and Where Automation Stops
Some answers exist only in an archive's reading room or on a request form. The skill can draft focused requests to archives, libraries, universities, and museums, and it can send them through available mail tools, but only when you've authorized it. Connecting a mailbox doesn't authorize sending, and neither does attaching files or agreeing to a paid service.
The agent records each outcome, avoids duplicate sends, and treats the reply as evidence like any other artifact. When a site presents a CAPTCHA, the agent may try once through normal controls in its browser. If that fails, it hands the tab to you with the URL and the required action. It doesn't use external solvers, bypass protections, or evade rate limits. You complete any sign-in yourself.
This matters because the fastest route to a record is often the one that gets your access revoked or your request ignored. A slow, legitimate request usually beats a fast, risky scrape.
Privacy Is Part of the Method
Family history involves living people, and the skill treats that as a constraint on the research itself. It refuses to look up current addresses, phone numbers, or accounts of living relatives, and it minimizes their data in reports. Other rules follow the same logic:
- Keep private case files outside the skill's repository, and check staged files before contributing.
- Don't upload your documents or DNA data to third-party services without explicit consent.
- Report sensitive findings, such as deportation, repression, adoption, or unexpected DNA results, neutrally and only as far as your question requires.
- Keep examples in shared notes free of personal data.
Sensitive findings deserve extra care. A deportation record can change how a family understands its history, so the report should state what the record says and stop there.
Frequently Asked Questions
What is former USSR genealogy research?
Former USSR genealogy research is the process of tracing family history across the Soviet Union, the Russian Empire, and their successor states. It relies on church books, civil registers, and military, deportation, and repression records, and it requires identifying the historical jurisdiction for each event. Because borders and names changed, the work depends on original records rather than current maps or merged trees.
How do I find my ancestor's parents in Soviet-era church records?
Start by identifying the historical jurisdiction and parish for the event date, then find the register through an official catalog or a known film collection. Read the baptism and marriage entries by hand, checking the calendar style and name variants. Save each scan, record the search, and look for a second independent record, such as a military card, before treating a parent pair as corroborated.
Why does the skill count two copies of one record as one source?
Copies and mirrors of the same page share one origin, so they can repeat an error without adding evidence. The skill assigns them a shared independence group. Corroboration counts only when two artifacts from different groups agree, which keeps a single transcription error from appearing as multiple confirmations.
Can the agent look up current addresses of living relatives?
No. The skill refuses to look up current addresses, phone numbers, or accounts of living people, and it minimizes personal data in reports. If your research touches living relatives, keep their details out of shared files, and treat any DNA data as private unless you've given explicit consent for it to be processed.
Try running init_case.py on one question from your own family this week, then run the audit before you write anything. If the summary shows an uncorroborated claim, you've found your next search. Pass this to someone stuck on a grandparent's missing parish record, and point them to the skill repository to start with former USSR genealogy done properly.