FuturPulse analysis · 26 October 2026
ex-USSR Kinship Research version 1.6.0 shipped on 26 October 2026 with a genealogy workflow that requires independent evidence chains before a family link is corroborated, records provenance for every artifact, and supports authorized archive requests. That makes it more auditable for former-Soviet family history than the general research skills compared here.
At a glance
- The skill covers family-history work spanning the former USSR, the Soviet Union and the Russian Empire.
- Version 1.6.0 uses six explainable claim states, from
hypothesistostrongly-corroborated. - A relationship cannot become corroborated until it has at least two independent evidence chains.
- The published evaluation file contains cases for namesakes, copied indexes, repression records, living people and disputed birthplace claims.
- Our comparison finds six explicit genealogy evidence controls in the skill, more than the general-purpose research workflows reviewed.
What is ex-USSR Kinship Research?
ex-USSR Kinship Research is an agent skill, meaning a package of instructions and helper scripts for an AI coding agent. Its purpose is narrow: trace family relationships through church books, civil registration, military material, migration records, deportation files, repression records and unindexed archive scans.
The key design choice is that a scanned record is treated as an artifact, not automatically as a fact. The workflow asks the agent to record where it came from, whether it is an original or a copy, how readable it is, and whether another apparent source merely repeats it. That is a useful discipline when a family tree contains copied indexes or several people with the same name.
The skill also separates identity from kinship. Establishing that a soldier card belongs to a named person does not, by itself, prove a parent-child relationship. The published rules require the agent to keep same-name candidates as separate person_id records until distinguishing evidence appears, such as a house number, parents, witnesses, date of birth or military unit.
Evaluation verdict: strong fit for a researcher who needs a defensible family-history report, not merely a plausible tree. Less suitable for a quick “find my ancestors” prompt where the user does not want to maintain logs, artifact registers or unresolved alternatives.
Why is the evidence-first approach different?
The distinguishing control is the independence_group. Copies, mirrors, indexes and retellings of the same underlying record must share a group, so three websites repeating one baptism index cannot become three confirmations. A claim remains single-source until an independent chain supports it.
The published protocol uses six labels instead of a confidence percentage: hypothesis, single-source, corroborated, strongly-corroborated, contradicted and unresolved.
The project’s logic tests show the intended behaviour. In one case, three genealogy websites display the same date of birth; the expected result is to check whether they copied one index and avoid calling the claim corroborated. In another, two men share a name in one village; the agent must retain both candidates and search for spouses, households, godparents and occupation before merging them.
This is not proof that an AI agent will always read handwriting correctly or find the right archive. It is a more limited and valuable claim: the workflow is designed to preserve uncertainty when the underlying record, transcription or identity match remains uncertain.
How does it compare with research skills?
General research skills excel at planning, broad web research, report structure or reusable organizational knowledge. ex-USSR Kinship Research adds controls designed for a special problem: proving each edge in a family tree while historical borders, scripts, calendars and spelling change around the person being researched.
Our coding below counts distinct, explicit evidence controls in each published workflow. The count is not a quality score and does not measure search accuracy. It measures whether the instructions explicitly require source provenance, independence checks, contradiction handling, identity separation, claim status and an auditable final chain.
| Skill | Primary job | Published evidence controls our count | Practical difference |
|---|---|---|---|
| ex-USSR Kinship Research | Historical genealogy | 6 | Tracks artifacts, claim status, source dependence, namesakes, contradictions and separate kinship links. |
| Research Worker | Read-only codebase investigation | 2 | Requires file references and unknowns, but it is built for software investigation rather than historical identity resolution. |
| Research | Research outline creation | 1 | Builds a topic framework, requests a time range and creates outline files before deeper work begins. |
| Deep Research | Multi-source synthesis | 4 | Defines sub-questions, cross-references findings, grades evidence quality and reports open questions. |
| Research Repository | Persistent user-research knowledge | 4 | Retains study provenance, confidence, conflicting findings and supersession for an organization. |
Our calculation counts only controls explicitly described in each workflow. It does not rate a skill’s safety scan, popularity, model quality or archive access.
The comparison highlights a division of labour. Research Worker is careful about uncertainty but searches a local codebase first. The Research skill is a planning tool that produces an outline and fields schema. Deep Research orchestrates wider investigation. Research Repository preserves research over time. None of those published descriptions specify a rule that copied records cannot increase genealogical proof.
That does not make ex-USSR Kinship Research a replacement for them. A team could use a general deep-research workflow to map an archive system, then use the genealogy skill to assess records and relationship claims inside one family case. The specialized skill’s advantage appears after search results arrive.
What was promised and what shipped?
The dated release history shows fast expansion over 25 and 26 October 2026. The latest version adds operational controls around archive correspondence and evidence dependence, rather than changing the central claim that family links must be traceable and independently supported.
The changelog says the skill would continue research while questions, sign-ins or access requests awaited a reply. It also promised reusable cases, optional PDF output and an evidence audit that checks direct evidence, provenance, contradictory evidence and invalid person references.
The same release history records expanded regional starting points for the Caucasus and Central Asia, explicit coverage of all 15 former Soviet republics, and guidance that separates digitization from actual record availability. That is important because an online catalogue does not guarantee a viewable page or a surviving register.
The latest release shipped rules for coordinating parallel register changes, handling authorized institutional requests with sending-state and reply provenance, and assessing evidence dependence claim by claim. It also permits one normal CAPTCHA attempt when tools and site rules allow it, followed by a user hand-off rather than bypass attempts.
The “shipped” part is visible in the current workflow. It directs an agent to register artifacts, claims and relationships; calculate a file hash for stored artifacts; audit a case before the final report; and treat an archive reply as evidence rather than as automatic confirmation. Those are concrete workflow components, not only a description of desired research behaviour.
Which family-history tasks fit best?
The strongest use case is a question with a defined person, approximate place and a request to prove a specific relationship. For example, a user may have a marriage certificate and a military card and need to know whether they identify the same person before claiming a parent line.
- Namesake separation: distinguish two people with the same surname and patronymic in one locality.
- Jurisdiction reconstruction: find the parish, district or civil office that held authority on the event date, rather than searching only today’s map.
- Unindexed scan work: log the film, image, column and legibility of a record that has no searchable transcription.
- Repression or deportation research: distinguish an official list entry from a fuller case file and avoid inferring an accusation from a terse notation.
- Family-ready reporting: produce a readable chain in which every parent-child link carries its own evidence status.
The workflow is also practical for a long-running case. Its case structure separates people, artifacts, claims, relationships, search logs and a final report. That avoids the common failure mode where an agent finds a useful record, summarizes it in chat, then loses the path needed to revisit or challenge the conclusion.
What does model use cost for a long case?
The skill is published under an MIT license, but it does not include a model or pay for archive access. Costs therefore depend on the AI model and the amount of reading. By our calculation from OpenRouter list prices, 1,000 agent steps using 30,000 input tokens and 2,000 output tokens cost $22.40 with Hermes 3 70B Instruct and $76.00 with Perplexity Sonar Deep Research.
| Model | List-price estimate per 1,000 agent steps | What changes the bill |
|---|---|---|
| Hermes 3 70B Instruct | $22.40 | Lowest estimate in this four-model comparison. |
| Hermes 3 405B Instruct | $32.00 | More expensive input and output use than the 70B model. |
| Hermes 4 405B | $36.00 | Higher output-token pricing raises long report costs. |
| Sonar Deep Research | $76.00 | Highest estimate in the published price set used here. |
Our calculation assumes 30,000 input tokens and 2,000 output tokens per agent step. Tokens are the chunks of text a model reads and bills by. This is a list-price estimate, not a test of model quality or a forecast of archive fees.
A careful workflow can reduce wasted model use because it records failed searches, blocked routes and rejected candidates. However, no published material establishes average token consumption for a complete family case. Scans, handwriting quality, archive portals and the number of competing namesakes will drive the real total.
Is this a surveillance skill?
No. ex-USSR Kinship Research is framed as family history, not a tool for finding living relatives. Its rules say not to seek current addresses, phone numbers, personal accounts, identity documents or information about minors that is unnecessary for the historical question.
The boundary also applies to documents. The workflow says not to upload user records, DNA data or photographs to third-party services without explicit permission. Sensitive findings, including adoption, possible parentage discrepancies, repression, ethnicity and religion, should be reported neutrally and only to the extent required by the user’s question.
Those guardrails are unusually specific for a research skill. They matter because genealogy research often begins with old records but can quickly touch living people, family conflict or records that have access restrictions.
What does this say about the research-skill market?
The skill fits a growing market for packaged agent workflows rather than generic prompts. A March 2026 launch post for the Prosper Knowledge Repository described a collection of three skills and 23 commands, alongside research, writing and coding systems. The pattern is clear: users increasingly install task-specific operating rules around a general model.
ex-USSR Kinship Research makes a stronger specialization bet than a generic research pack. Its value is not that it knows every archive in advance. Its value is that it forces the agent to disclose which document supports which relationship, what remains unproven and whether two apparently separate sources are actually one chain.
What we could not verify?
No public benchmark establishes the skill’s success rate on real genealogy cases, handwriting transcription, archive discovery or identity resolution. The repository includes published logic cases, but no independently audited pass rate, user-study results or comparison against human genealogists is public.
Pricing for archival copies, response times from institutions, and access to restricted collections also remain case-specific. Archives and record custodians could settle those questions through their current access policies, catalogues and replies to individual requests.
Finally, the project’s latest release date is clear, but the public release history does not assign dates to every older version. The maintainer could settle that gap by adding dated entries for versions 1.1.0 through 1.3.0.
