How This Tool Is Built

The model never answers from its own general knowledge

Every question first runs through a keyword-matching retrieval step against the actual cleaned dataset. Only the matching archival records are passed to the model, with an explicit instruction to answer only from what it's given and say plainly when the records don't cover the question. This follows a specific argument from a paper I am co-authoring, currently in peer review: "Leveraging Open Source LLMs for Historical Databases of Agricultural Science Research". That paper argues that retrieval-augmented generation, or an equivalent technique, functions as a baseline requirement for any conversational LLM interaction used in historical research, not an optional refinement — the safeguard against a model confidently filling gaps with plausible-sounding but ungrounded claims.

Because retrieval works by keyword, the model sees only the handful of best-matching records (up to eight), not the whole dataset. The interface says so: the records it retrieved are labelled as such, and answers about the dataset as a whole are not left to the model. When the retrieved records do not answer a question, the tool says that plainly and cites nothing, rather than listing loosely related files. That is not proof the database contains nothing on the topic, only that the retrieval did not find it.

Counts, statistics, and charts are computed, not generated

Questions like "how many workers died of pneumonia?" or requests for a chart are answered by directly counting and aggregating the underlying data in the browser — the language model is not involved in producing the number at all. This avoids the most common failure mode of LLM-assisted data tools: a fluent, confident-sounding statistic that is subtly wrong. If a chart request doesn't match a dimension the tool can compute cleanly, it says so and lists what it can do, rather than silently substituting an unrelated chart.

The same applies to averages, medians, and highest and lowest values, which are calculated over every matching record. This matters: an earlier test showed a language model averaging the five records it happened to be shown and getting the Kru estate average wrong by half. Where causes of death are recorded as combinations, the tool reports both figures. For example, 161 workers have pneumonia as their only recorded cause, while 188 have it mentioned at all, and which number is right depends on the research question.

Open querying, gated publication

This dataset includes real causes of death, next-of-kin names, and estate details for real, deceased individuals. The tool is fully open for exploration, but carries a persistent, visible notice asking anyone intending to use specific personal details in a publication to contact me first — with consultation with the National Archives of Namibia suggested as a further step. This reflects the CARE Principles for Indigenous and postcolonial data (Collective Benefit, Authority to Control, Responsibility, Ethics) as a necessary complement to FAIR data principles — "open by default" is not automatically the same as "ethically appropriate."

Currency conversion and archival naming, surfaced rather than hidden

All monetary figures in the dataset were standardized into Pound sterling from multiple original currencies during its construction, with the possibility of minor inaccuracies. Rather than letting the model state a converted figure as if it were the original archival value, the interface and the model's instructions both surface this explicitly. Archival citations follow the exact convention used in Forged in Genocide — full name expanded on first use per repository, abbreviated after — generated automatically rather than left to the model to approximate.

Ethnicity phrasing follows historical convention, not raw field values

The dataset often records a specific Ovambo polity alongside the broader "Ovambo" label (e.g., "Oukwanyama; Ovambo"). Historically, individuals identified primarily with their specific polity, not the broader ethnolinguistic category alone. The model is instructed to phrase this accordingly — "an Ovambo man from Oukwanyama," matching the published scholarship's own convention — rather than presenting a raw, undifferentiated data field as if it were the full picture of someone's identity.

Narrow, specific questions — guided by subject knowledge — over open-ended ones

The article "Leveraging Open Source LLMs for Historical Databases of Agricultural Science Research" argues that LLMs are most useful to historians not as a substitute for close reading and critical judgment, but as a sparring partner: most reliable when guided by narrow, specific questions informed by real subject-matter expertise, refined through back-and-forth rather than posed once and trusted outright. This tool's retrieval-then-generate structure is a direct application of that idea — the model works within a bounded, specific set of records rather than being asked to reason freely over the whole archive at once, and its aggregate/chart answers are computed rather than inferred precisely because some questions are better answered by arithmetic than by a language model's judgment.

A demanding standard, honestly not yet fully met here

"Leveraging Open Source LLMs for Historical Databases of Agricultural Science Research" develops the framework of open history: adapting open-source, open-science, and FAIR principles specifically to LLM-assisted historical research. Its bar is genuinely demanding — models runnable locally, on any available hardware, with no dependence on a commercial AI product or subscription, for real long-term reproducibility independent of any one company's continued existence or pricing.

By that standard, this tool doesn't fully qualify yet. It currently runs on Mistral Small, an open-weight model from the French lab Mistral AI; earlier versions ran on Anthropic's proprietary Claude. I made the change because open weights and a European developer fit the project's values far better. But I reach the model through Mistral's hosted API, and that remains a commercial service dependency, not the self-hosted independence the framework actually calls for. Mistral describes its hosting as EU-based by default, while noting that some features can involve non-EU subprocessors, so the data does not stay in Europe in any absolute sense. In my Mistral account I have declined the option that would let questions sent through the tool be used to train Mistral's models. The route here was not smooth (a retired model, unclear free-tier limits, a rate-limit failure), and I document that friction rather than erase it, since it is itself informative.

The version that would genuinely meet this standard is a self-hosted, open-weight model — similar to the h2oGPT/Ollama-based approach used in my postdoc work on the Rice Knowledge database at the Universität Zürich — run on local or institutional hardware. That remains the concrete direction for this tool's next version, not an abandoned idea, and it aligns with data-sovereignty priorities increasingly relevant at European universities as well as with my own background and goals in open-source, open-access digital methods.