Skip to content

Pages are not what *archivers think in*.

Search engines for archives think in pages. A query goes in, a page comes out, the user opens it. That works perfectly when the unit of meaning happens to fit on one page. It works badly the rest of the time, which is most of the time, because real documents in real archives almost never sit neatly inside a single page.

A set of council minutes runs across three to five pages. The first page lists the people present and opens with the date. The middle pages cover the motions and the discussion. The last page has the signatures and any disagreements. If you search the corpus for a name and only one of those pages comes back, the researcher has to open it, realise it’s the middle of something longer, manually flip backwards and forwards until they figure out which document it belongs to, and then read the document. Multiply by ten thousand searches and you have the experience most archive users describe as slow.

A last will and testament is the same problem at a different length: declarations, heirs, bequests, signatures, sometimes a later codicil. Five to ten pages. A baptism record is occasionally just one page, but sometimes it’s accompanied on the next page by the parents’ marriage record because the priest filed them together. Some pages, conversely, contain two unrelated documents because the scribe didn’t want to waste a half-empty sheet.

None of this is exotic. It’s how archives have always worked. The mismatch is on the software side: the software thinks pages are the unit; the field thinks documents are the unit. Every other tool we know about lives on the software’s side of that mismatch. We don’t.

In archAIc, a document is a first-class object — the package of one or more pages (or part of a page) that together form a single act: a meeting’s minutes, a testament, a parish entry. We call this internally a document logical unit; the user-facing word is just “document”.

A document carries its own metadata — type, date, the people and places it names — independently of which page each piece of metadata happens to be written on. Search results can be filtered by document type. The viewer can show the whole document as one scrollable thing with the page breaks marked, rather than forcing the reader to flip through pages by hand. Citations look like “Acta of 17 May 1783” rather than “page 143 of book 9 of collection RMCR”.

The page-level index doesn’t go away. It’s the foundation, and it still does everything a page-level index has always done. The document layer sits on top, and most of the time it just adds context: when the user lands on a page from a search, a small banner tells them what document the page is part of, and offers a one-click jump to read the whole thing.

If documents are first-class, somebody has to say where one ends and the next begins. That’s the question we spent the longest figuring out, because the answer changes per archive and sometimes per book.

Three ways to draw a boundary, in increasing order of automation:

  1. By hand. The curator selects pages in the editor, picks a document type from a list defined for their archive, fills in the basic metadata. This is the baseline. Every archive supports it. For a small collection or a particularly thorny libro, the curator just draws the boundaries.
  2. By rule. Some archives have conventions. Council minutes always start with “En la villa de…”. Testaments always start with “In nomine Domini…”. A regular expression on the first few lines of each page catches most boundaries; the curator confirms or rejects each proposal.
  3. By meaning. The interesting one. We reuse the meaning-vectors we already compute for semantic search. Adjacent passages of the same document tend to be semantically close — they share vocabulary, named people, the same topic. When one document ends and another begins, the meaning shifts sharply. We compute that shift across the whole book and propose boundaries wherever the shift spikes above a threshold.

A book split into proposed documents based on a meaning-shift signal, shown as a histogram across the book with vertical lines at each proposed cut. A book split into proposed documents. The histogram shows the meaning-shift signal across the volume; the vertical bars are the proposed cuts. The curator accepts, edits or rejects each one.

In every case the system proposes. The curator decides. We don’t commit a document boundary without an expert saying yes — the cost of a wrong boundary is high, and the cost of an unnecessary review click is low.

Once a document exists as a coherent thing, we can ask a language model to read the whole thing and pull out structured metadata — the title and date, the people named (with their role: testator, witness, godfather, mayor), the places mentioned, the organisations involved, the events that happened and the relationships between everyone.

A document's extracted metadata: type, title, summary, dates, plus tabs of people, places, organisations, events and relations, each with counts and an overall confidence score. Each document gets a type, title, summary, date range, plus its people, places, organisations, events and relations. Each tab carries a count and the document carries an overall confidence score. Everything starts in pending-review.

The rule we hold to is uncompromising: every extracted fact must point back to a specific line on a specific page. If the language model claims Don Emilio Romay was president of the sanitation commission, the system insists on knowing where on the page it saw that. The curator clicks the claim, the page image opens with the relevant line highlighted, and they verify against the original ink. If a claim doesn’t have a source, it doesn’t get into the database. We filter unsourced output both when writing it and when reading it. It’s the most important property of the system after probabilistic indexing.

A claimed entity highlighted on the original page image with the exact line that supports it framed. Click any extracted fact; the page image opens with the source line highlighted. No source, no fact.

Old records have a problem the modern world mostly doesn’t: the same person is named ten different ways across ten different documents. Don Emilio Romay Mosquera, Don Emilio Romay, D. E. Romay, Romay, sometimes simply el alcalde. The handwriting varies, the abbreviations vary, the deference varies.

So we keep three levels of identity for every named entity. What the ink literally says, what we think the person is called in this document, and (eventually) what we know about this person across the whole archive. The first level is always populated — it’s just whatever was written. The second is filled in by automation and confirmed by the curator. The third is the result of a separate, deliberate decision: the curator looks at twenty drafts of “Don Emilio Romay” across twenty documents and promotes them, by hand, to a single corpus-wide person record. From that moment on, every mention of him is linked to the same authority record, and any new document mentioning him is automatically attached.

This sounds laborious. It is — and it’s the work the field has always done. Every catalogue you’ve ever used relies on someone having sat down and decided that this Emilio Romay is also that Emilio Romay. We don’t shortcut that step. We make it faster.

The same anchored, sourced, expert-validated treatment applies to places and events. Every place mentioned in a document is geocoded against open mapping data and shown as a pin; the curator confirms or fixes the wrong pins. Every event extracted from the text is plotted on the page it came from, so the curator can see at a glance where in the document the action is.

Places named in a libro plotted on a map, each pin linked back to the page and line where the place is mentioned. Every place mentioned in a libro becomes a pin on the map. A national or regional archive suddenly has a geographic footprint — and the curator can correct the wrong pins with a click.

The interesting consequence of all this happens slowly. Each correction the curator makes is not just a fix to a single document. The corrections feed back into the system. A retrained handwriting model picks up the curator’s confirmed words. Sharper authority files improve the extraction on the next document. A better-tuned segmenter spots the next set of boundaries more accurately.

What the institution ends up with is not just a searchable archive. It’s a curated, exportable, growing knowledge graph of its own holdings — anchored to the original ink, mapped to the standards the rest of the cultural-heritage world uses, owned entirely by the institution. The longer the system is used, the more valuable that asset becomes.

The page-level search is the entry point. The document is what the user actually wants. The knowledge graph is what the institution gets to keep.


← Four ways to ask the same archive