What is archAIc
archAIc is a search and intelligence layer for handwritten archival documents. It sits between the HTR engine that reads the ink and the catalogue surfaces (web UI, MCP, IIIF, REST) that archivists, researchers, and downstream agents use. The product takes the probabilistic output of modern HTR, indexes every plausible reading instead of collapsing to one transcription, and lifts the result into a graph of typed documents, entities, events, and relationships that point back to the exact line on the exact page where each claim was found.
The three layers
Section titled “The three layers”The system is built as three layers on top of the same underlying ink.
The probabilistic index (PrIx). HTR doesn’t return text. It returns a lattice: a probability distribution over the words and characters the ink could be. archAIc indexes every path in that lattice with its probability, instead of throwing away the alternatives. The result is a keyword index (LMDB, FST, bitmap) that finds pages even when the top transcription was wrong, and a semantic index (Qdrant, dense plus sparse embeddings) that finds pages by meaning rather than spelling. Both layers carry confidence scores upward, from word to line to passage. See Probabilistic indexing.
The DLU graph. A Document Logical Unit is the archival object above the page: a council session split across five folios, a will and its codicil read together, an entry in a parish register that occupies the last six lines of one page and the first eight of the next. DLUs are typed, nested (collection contains libro contains segment), and carry the structured metadata cataloguers actually work with (title, dates, parties, scope note). Every DLU also carries its extracted property graph: persons, places, organisations, events, and the relationships between them. See Document Logical Units and Entities, events, relations.
The surfaces. The same data is exposed through a web application for curators and researchers, an MCP server for AI agents, IIIF endpoints for image integration, and REST endpoints for machine consumers. Nothing about the underlying model changes between surfaces. An agent talking to the MCP server sees the same (page, line) anchors, the same confidence scores, the same authority ids that the human curator sees in the web UI.
What archAIc is for
Section titled “What archAIc is for”The product is built for institutions whose holdings are mostly handwritten and mostly historical. Council books, parish registers, notarial protocols, court records, padrones, libros de actas. Material between roughly the 16th and the 19th century, where the transcription is hard, the catalogue work is expensive, and the existing tools assume one of those two problems away.
The intended users are the people who actually run an archive: cataloguers, researchers, archive directors, and the small number of engineers a heritage institution can keep on staff. The intended outcome is a searchable, curated, exportable corpus that the institution owns end to end.
What archAIc is not
Section titled “What archAIc is not”archAIc is not an HTR engine. It consumes the output of an HTR engine (today via the PrIx pipeline maintained by PRHLT and Transkriptorium). If you do not yet have HTR over your material, that is a separate procurement, and archAIc is downstream of it.
archAIc is not a cataloguing system in the AtoM or ICA-AtoM sense. It sits next to those tools and feeds them. A typical deployment exports curated DLUs as EAD, EAC-CPF, Linked Art, or AtoM CSV and ingests them into the institution’s existing catalogue. archAIc is the workbench where the catalogue records are built, not the public discovery layer that replaces them.
archAIc is not a generic large-language-model wrapper. Every extracted fact carries at least one (page, line) anchor with a confidence score. Unanchored output is dropped at write time and filtered at read time. See No anchor, no entry for why this rule is load-bearing.
How it ships
Section titled “How it ships”archAIc is sold and run self-hosted. The whole stack ships as a Docker bundle that runs on the institution’s own servers. A small municipal archive runs on a single workstation. A national archive spreads across a rack. Nothing leaves the building unless the institution decides it should.