Khronos: the paleography we lack and the one AI can give

We know little about Costa Rica between 1500 and 1821, but not for lack of documents. We lack readers. The notaries’ protocols, the town council minutes, the parish books and the files of the Audiencia exist; they sit in the National Archives, in the Archivo General de Centro América and on microfilm. What does not exist is the capacity to read them: paleography, the craft of deciphering old scripts, is taught to few people, takes years to learn and is practised one page at a time. There are more folios than paleographers will have time to read in their lives.

Khronos is a personal project born from that arithmetic that does not add up. The question was never whether an artificial intelligence can replace a paleographer, but whether it can supply the capacity no human has: reading tens of thousands of pages without tiring, at marginal cost, with three centuries of context loaded in memory. A first result is live at basetlabs.com/khronos: a map, a timeline and a people network built from 11,053 notarial records and a manuscript from 1617. The code and data are on GitHub. This post tells how far that capacity reaches today, where it breaks, and how the missing part gets built.

A task that asks for more than one human

Reading a colonial document is not reading. It is recognising a procesal hand in which the letters chain together without lifting the pen, expanding abbreviations that change from one notary to the next, knowing that “v.ro” is vecino and “ss.no” is escribano, spotting an opening formula so you can skip it and an exception so you can stop, keeping in mind who was alcalde that year and where Pacaca was. And then doing it again on the next page, and on the ten thousand after that, with the same attention on the last as on the first.

An expert paleographer does all of that better than any current machine. What they cannot do is scale it. The task demands expertise and volume at the same time, and those two things almost never come together in one person. That is where a language model brings a genuinely more-than-human element, though not the one usually imagined: it is not smarter than the paleographer, but it does not tire, does not charge by the hour, reads in any language and arrives at every page with everything it has ever read about the period. The useful question is which part of the craft can already be delegated to that capacity and which part remains irreducibly human.

Khronos answered it at two levels of difficulty.

Level one: reading through the noise

Level one is not a manuscript but a printed book that already summarizes manuscripts: the Índice de los Protocolos de Cartago, published by the National Archives of Costa Rica in the early twentieth century. Entry by entry, it condenses the protocols of the notaries of Cartago: powers of attorney, sales, wills, debt obligations, dowries, letters of manumission. Each entry gives the folio, the date and a paragraph naming the people, the places and the matter at hand. It is a first-rate source for genealogy and colonial social history, but it can only be read front to back.

I started from the five volumes digitized on the Internet Archive. The OCR text runs to about 140,000 lines and carries the noise of an old printing: swapped letters, accents turned into digits, page headers mixed into the content. A human reads through that noise without noticing; a regular expression does not. A language model does.

A Python script splits the text into 100-line chunks and sends each one to Gemini 2.5 Flash with a Pydantic schema describing what I want back: a list of events (year, day and month, places, people involved and a two-to-three sentence summary) and a list of person profiles (name, role or occupation, inferred age or birth, and relationships to other people in the chunk).

1 En.  24—El Capitán Francisco de Ocampo Golfín;, enco
mendero de esta ciudad, da poder general 4 Gó-
mez Arias, procurador de causas en la Audiencia
de Guatemala.

{
  "year": "1607",
  "date": "Jan 24",
  "locations": ["Cartago", "Guatemala"],
  "people_involved": [
    "Capitán Francisco de Ocampo Golfín",
    "Gómez Arias"
  ],
  "summary": "Captain Francisco de Ocampo
    Golfín, an encomendero of Cartago,
    granted general power of attorney to
    Gómez Arias, a legal procurator in the
    Audiencia of Guatemala."
}

Here the capacity is already superhuman on the axis that matters: volume. No person would have indexed 140,000 lines at that level of detail; the model did it in a process that runs on its own, with retries and progress saved to disk so an interruption never means starting over, and a second pass in batches of 50 events translated the summaries into Spanish. The result: 11,053 events and 23,811 distinct person names, from five volumes that until then could only be leafed through.

The five volumes, digitized on the Internet Archive:

• Índice de los Protocolos de Cartago, Volume I
• Índice de los Protocolos de Cartago, Volume II
• Índice de los Protocolos de Cartago, Volume III
• Índice de los Protocolos de Cartago, Volume IV
• Índice de los Protocolos de Cartago, Volume V

What the model does not know

The human part of the craft came straight back, but somewhere else: not in the reading, in the context. A second script turns the model output into three compact JSON files, and that is where what reading alone cannot solve gets solved:

• Missing years. Only 4,294 events carry an explicit year. Because the index is chronological, the remaining 6,759 inherit the year of the previous dated entry and are flagged with a ≈ symbol in the interface. A human reader would do that without thinking; the model, chunk by chunk, has no such memory.
• Colonial geography. No model knows where Pacaca or Landecho were. I built a gazetteer of about 165 places with coordinates (the Central Valley, Guanacaste and the Pacific, the Kingdom of Guatemala, Spain) plus an alias table that ignores accents and old spellings. With that, 6,645 events land on the map and 4,408 remain without coordinates, almost always because they mention farms, rivers or spots I have not been able to identify. It was the slowest part of the project and the one that adds the most value.

The lesson of level one: with a clear schema, the model absorbs the tedious work of reading noisy text at scale, and the human effort shifts to validating, completing and saying what is not known. Inferred years are flagged, unlocated places are counted, and the footer warns that AI-assisted extraction may contain errors.

Level two: the manuscript

The index was print. The real test of paleography was a manuscript, and I chose a hard one on purpose: the Libro Once de Cabildo of the city council of Santiago de Guatemala, the minutes from 1617 to 1626, because Costa Rica depended on that Audiencia and because it is an edge case. It is 208 microfilm images from the Archivo General de Centro América (A1, bundle 1773, file 11767), nearly all two-page spreads, in chained procesal script. The digitized roll is on the Internet Archive.

A new script sends each image to Gemini 3.1 Pro with a schema much like the one used for the index: a diplomatic transcription of each page, marginal notes, a list of dated matters with people and places, and a legibility estimate. It resumes where it left off, records what every page costs, and stops when it reaches a budget. The result is in the app as a second collection: 504 matters, each with its leaf, its folio and the legibility the model assigned to the page.

Read the last row carefully. Ten years of council minutes, in procesal script, read cover to cover for under four dollars. That is the economic dimension of the more-than-human capacity: at that price, the limit on reading an entire archive stops being the budget. But the manuscript taught two lessons the printed index had not, and the second one defines where the frontier is today.

Cost runs away quietly. The first pass used temperature 0.1, the setting that had worked for the index. On Gemini 3 that temperature triggers repetition loops: the model starts transcribing, falls into a cycle and keeps generating up to its output limit, and every token is billed. Fifty leaves cost 35 dollars before I understood why. With temperature 1.0 and a cap on output tokens, a page costs two cents and the whole book under four dollars.

A fluent reading is not a reading. To measure quality without a paleographer at hand, I reread the same pages several times and compared the transcriptions with each other. Two readings of the same page agree on one word in ten, including on pages the model rates at 0.95 legibility, and including when each page is sent alone at full resolution. What the model knows comes back the same on every read: the opening formulas, the dates, the structure of a minute. What the model has to see changes every time: the names of the council members. A cheaper model went as far as inventing an entire council with plausible names of the period, among them the Count of La Gomera, who really was president of the Audiencia in those years, which is exactly what made it believable.

This is the exact opposite of a novice paleographer, who deciphers the letters but does not understand the document. The model understands the document and does not decipher the letters. Its “superintelligence” is one of context, not of sight: it arrives at the page knowing what a cabildo is, how a minute opens, who governed the Audiencia, and fills in with that culture whatever the microfilm does not show. For a fluent reading that is a virtue; for a transcription it is the worst possible flaw, because the error does not look like an error.

The consequence is that this collection is a finding aid, not a citable source: it locates which leaf deals with an election or a feast, and gives the date, but every name has to be checked against the image before use.

How the missing capacity gets built

If the model already brings volume, cost and context, and what it lacks is the paleographer’s fine eye, the question is how to teach it to see. The literature’s answer is well known and modest: a handwriting recognition model, like those in Transkribus, trained on about fifty pages of that same book corrected by hand. Fifty pages are two or three weeks of one expert’s work. In return, the trained model reads the remaining 400 and, in principle, any other book in the same hand.

That is the point I find important. The more-than-human capacity does not come from a model alone, nor from a paleographer alone. It comes from a system in which the expert corrects little and teaches much, and the machine multiplies that teaching by the size of the archive. The paleographer stops being the bottleneck of reading and becomes the teacher of a reader that never tires.

Khronos is building the pieces for that:

• A ground truth. Pages of the Libro Once corrected by hand, against which a second script measures each model’s error rate instead of trusting the legibility the model assigns itself.
• An honest division of labour. The language model keeps what it already does well: dating, classifying, summarising and flagging which leaves deserve an expert’s time. Transcribing names is delegated to a trained model or to a person until the metric says otherwise.
• A community that corrects. Duplicate names (Francisco de Ocampo Golfín and his spelling variants are still separate nodes in the network), places the gazetteer does not recognise, misread dates: the people who work with these sources know them best.

What changes if it works

Meanwhile, what has already been read can be explored. The interface is a React 19 app built with Vite and Tailwind, designed so each view loads only what it needs:

• Map. MapLibre GL over a dark basemap, with bubbles clustered by place, a year slider with an adjustable window and auto-play, and a popup listing the records of each site.
• Timeline. A searchable list, accent-insensitive, with a decade filter and incremental rendering, to walk the records in the order they appear in the index.
• Network. A co-occurrence graph: two people are connected when they appear in the same record. You can see the most connected people or explore the network around one person.

The three views share the same event detail and jump between each other; the language choice is remembered between visits and Spanish is the default. Next come deduplicating people, growing the gazetteer, linking every record to the scanned page of the original volume and, in time, reconstructing family trees from the relationships the model already extracts. The code remains open at github.com/fabiomurillo-baset/khronos.

If the capacity gets built, the change is not that one book gets read faster. It is that three centuries stop being a void for lack of readers and become a searchable archive, where a family can look up its surname, a town its first mention, and a historian the question nobody has asked yet.

Take part

An index of 11,053 records does not correct or enrich itself, and fifty pages of ground truth do not transcribe themselves. Much of what is missing —variants of the same name, places the gazetteer does not recognize, misread dates, the link between a record and the scanned page of the volume— is best known by the people who work with these sources: paleographers, genealogists, local historians, families who keep documents. That is why Khronos is opening a Discord community, Historia Documental Costa Rica, built on three levels:

1. Public conversation. Comments, questions and corrections in the open, so every finding is on record and others can join in.
2. Contributions. A forum where each post is a record, a family or a place, with its documents, photographs and transcriptions attached. Reviewed contributions are folded into the data, and the record shows who enriched it.
3. Working groups. When a topic gathers several people —a family, a town, a century— it gets a space of its own to work at a slower pace.

Join the server at discord.gg/Hedm7gsH5. Corrections and ideas are also welcome in the GitHub repository.