What Prolog Taught Me About Building an AI-Assisted Family Tree

My family-tree project has become considerably more complicated than entering names and dates into genealogy software. I am now dealing with civil records, parish registers, old photographs, certificates, correspondence, archives in several countries, translations, uncertain relationships, research hypotheses and a steadily growing collection of people who may or may not turn out to be relatives. As the project expanded, I realised that the difficult part was no longer simply finding information. I needed a system that could remember how I wanted the research to be conducted.

For this I am using two large language models, ChatGPT and Grok. Both are connected, with the appropriate permissions, to parts of my Google environment, including services such as Google Drive, Gmail and Calendar. They can therefore do considerably more than answer an isolated question. Depending on the available tools and permissions, they can search material, examine documents and correspondence, help organise evidence and assist with the increasingly complicated workflow surrounding the research.

The interesting part, however, is not really the LLMs themselves. It is the layer of rules I have put around them.

And, rather unexpectedly, the idea behind that layer goes back more than twenty years.

An old idea from Prolog

In the early 2000s I was exposed quite heavily to Prolog. It is a very different programming language from the procedural and object-oriented languages that most programmers encounter first. Instead of describing every step that the computer should execute, a Prolog program is largely expressed as facts and rules. You describe relationships and constraints, pose a query, and let the inference mechanism work out how those rules apply.

One feature that stayed in my head was Prolog's ability to work with a dynamic database. Predicates can be declared dynamic, allowing facts and rules to be asserted or retracted while the program is running. My memory of this after more than two decades had simplified the mechanism into “the program can update its own rules”. Technically, that is not quite the same as rewriting its source code, but the underlying idea is the one that mattered to me: behaviour does not necessarily have to be completely fixed when execution begins.

A system can acquire another fact or rule and behave differently the next time it has work to do.

The idea I borrowed from Prolog was simple: instead of repeatedly telling the system how to behave, maintain a body of rules that can evolve as the work evolves.

That idea turned out to fit remarkably well with the problem I was beginning to encounter with AI.

The problem with increasingly enormous prompts

At the beginning of an AI-assisted project, instructions are easy. “Research this person.” “Translate this certificate.” “Find out where this village was.” “Check my email for a reply.” But genealogy quickly introduces rules that are not specific to one question. A document can be evidence for several people. A hypothesis must not silently become a fact. An original historical image should be preserved even if I create a cleaned-up derivative. Sources need to be organised consistently. Research from one family branch may produce evidence affecting another branch.

Then there are rules about correspondence, privacy, folder structures, document names, evidence quality and how information should eventually be entered into my genealogy software. Some instructions apply everywhere. Others apply only to a country, family branch, person or particular kind of source.

I could put all of this into every prompt, but that would rapidly become ridiculous. The instructions would eventually be longer than the question.

More importantly, I would have to maintain them manually. If I changed a rule today, I would need to remember that change tomorrow. If I discovered after processing fifty documents that a particular procedure was inadequate, I would have to incorporate the improved procedure into every future conversation myself.

That is when the old Prolog idea resurfaced.

My rule base lives in Google Drive

I created a dedicated area in Google Drive containing text-based instruction files for the Family Tree project. These files are deliberately simple. They are not an application, a database server or some elaborate AI framework. They are readable documents containing the rules that describe how I want the project to operate.

The project-level instruction given to the LLM is consequently much smaller. Before carrying out family-tree work, it is instructed to consult the relevant instruction material, interpret those rules and use them as part of the context for the task. Instead of attempting to encode the entire operating model in every prompt, the prompt can concentrate on what I actually want to accomplish.

I have also designed the workflow so that when I establish a genuinely new standing rule, the persistent instruction material can be updated rather than leaving the new rule buried inside one conversation. In practice, any write operation still depends on the permissions and capabilities available to the particular AI environment, but conceptually the important point is that the rule belongs to the project, not merely to the chat in which I happened to think of it.

I no longer want a clever prompt that remembers everything. I want a relatively simple prompt operating against a persistent and evolving set of project rules.

The distinction sounds small, but architecturally it changes the way I use the LLM.

My request
    │
    ▼
Family Tree project
    │
    ├── Read persistent rules
    │     └── Google Drive
    │
    ├── Gather permitted context
    │     ├── Family documents
    │     ├── Gmail
    │     └── Other connected sources
    │
    ▼
Apply rules to the task
    │
    ▼
Research / analyse / organise / correspond
    │
    ▼
New standing rule?
    │
    └── Preserve it for future work

This is not Prolog, of course. An LLM is not executing a deterministic Prolog rule base, and natural-language instructions do not have the formal semantics of Prolog predicates. There is also an important operational difference between telling an AI to consult a file and having an architecture that technically guarantees that the file was consulted. The latter requires appropriate tooling, permissions and workflow enforcement. I therefore regard this as an architectural pattern inspired by Prolog rather than pretending that I have somehow rebuilt a Prolog interpreter around my genealogy.

Two LLMs, one research method

I am deliberately using both ChatGPT and Grok rather than making the project dependent on a single model. Both now support connections to external services, including Google Drive, and both can participate in workflows involving information outside the immediate chat. ChatGPT's current plugin system can connect services such as Google Drive and Gmail, while Grok provides connectors for Google Drive, Gmail and Google Calendar. Exactly which actions are available depends on the permissions granted and the capabilities of each environment.

For me, the useful architectural principle is that the methodology should live outside either model. ChatGPT may perform one piece of research and Grok another, but neither should be the sole repository of the project's operating knowledge. The documents, evidence and persistent rules should remain in systems that I control and can inspect.

This also makes the instruction files surprisingly important. They become something resembling the project's operating manual. I can open them and read what I have told the AI to do. If a rule is wrong, I can change it. If the workflow develops a bad habit, I can trace the instruction that encouraged it. If I eventually replace one LLM with another, the accumulated methodology does not have to disappear with the old tool.

That last point may become particularly important because this project is not going to finish next Tuesday. I am already researching family branches across Italy, Germany, Brazil, Argentina, Turkey and elsewhere, and some of the Italian work is taking me beyond modern civil registration into parish and historical archives. This could easily become a project lasting years.

The prompt becomes the question again

The practical benefit is wonderfully mundane: my prompts can become shorter.

I can concentrate on saying what I want to investigate rather than attaching an enormous operating manual explaining everything the AI has learned about my filing conventions, evidence standards and research methodology. The complexity has not disappeared. I have simply moved it to a more appropriate layer.

That is perhaps the part of this experiment that appeals most strongly to my engineering background. Complex systems become easier to manage when policy is separated from individual transactions. I do not want to explain the complete governance model every time I request one piece of work. I want the governance model to exist independently, and I want each request to execute within it.

There is an important limitation: natural-language rules are not executable guarantees. An LLM can misunderstand, overlook or incorrectly apply an instruction, so important genealogical conclusions still need evidence and human review.

That limitation matters particularly in genealogy. An AI that confidently converts a plausible relationship into an established family connection can contaminate generations of subsequent research. The rule system therefore does not remove the need for judgement. Its purpose is almost the opposite: to encode procedures that encourage the models to distinguish confirmed evidence from probabilities, hypotheses and leads.

A twenty-year-old idea finds another use

I find it amusing that an idea lodged in my head from working with Prolog in the early 2000s has resurfaced in a genealogy project involving technology that would have sounded like science fiction at the time. Prolog and today's LLMs are profoundly different technologies, but the conceptual connection was enough to give me the architecture I needed.

Facts change. Rules evolve. New evidence arrives. The system should be able to incorporate those changes without requiring me to reconstruct its entire operating context every time I ask another question.

The Family Tree project is therefore becoming something more interesting than simply “using AI for genealogy”. I am experimenting with a persistent research environment in which the LLMs are workers, Google Drive contains much of the documentary evidence and operating instructions, connected services provide additional context, and my genealogy software remains the place where properly evaluated family relationships are ultimately recorded.

It is still very much an experiment. I am changing the rules as I discover weaknesses, adding procedures when new kinds of evidence appear and learning where an LLM can be trusted to automate work and where I need to remain firmly in the loop.

But that, in a slightly unexpected way, takes me back to Prolog again. The useful part was never memorising a particular predicate or syntax. It was learning to think about problems in terms of facts, rules, relationships and inference.

More than twenty years later, I am using that way of thinking to find my great-great-grandparents.

I did not see that coming.

AI Assistance Disclosure: This article describes my own design and experience of using artificial intelligence as part of my family-history research. Artificial intelligence tools were also used as editorial and research assistants to organise and refine the text, review the technical description of the workflow, and verify terminology relating to Prolog and current AI connector capabilities.

Technical references were checked against current SWI-Prolog, OpenAI and xAI documentation. The Family Tree architecture, workflow, project rules, conclusions and opinions described here are my own. AI-generated research remains subject to documentary verification and human review before genealogical conclusions are treated as established facts.