Working with the rest of the *archival world*.

Apr 30, 2026

Vicent Bosch

archAIc

The principle

A new tool in an archive’s stack is only as valuable as the tools it can pass data to. We could have invented a tidy, opinionated, proprietary representation of everything archAIc extracts. It would have made our lives easier and the archivist’s life harder. So we didn’t.

Every output of archAIc lands on a public, named standard. The catalogue records flow into the same systems archivists already use to describe their holdings. The page images and transcriptions can be viewed in the same image viewers the rest of the field has standardised on. The knowledge graph fits inside the ontology museums and libraries have been refining for decades. Where there is a standard, we conform to it. Where there isn’t, we wait — we don’t invent new ones.

Who decides what’s true

Before any of that matters, there’s a more important question: who decides what the catalogue record says? Our answer is the one the field has agreed on for centuries.

archAIc proposes. The expert decides. The exporter writes down whatever the expert signed off on.

The system extracts entities, dates, types and relationships. It scores each one with how confident it is. Every output starts in a pending review state. The subject-matter expert — the archivist, the curator, the scholar — works through the proposals and either accepts them, edits them, or rejects them. Only what the expert has confirmed leaves the system.

This sounds obvious, and it isn’t. The temptation in a system like ours is to dress automated extraction up as professional curation. We refuse. Whatever archAIc produces without expert review is a draft. The exporter doesn’t smooth over the rough edges or guess at fields the expert hasn’t filled in. It serialises exactly the state the expert signed off on, and labels everything else as draft.

Catalogue records: ISAD(G) and AtoM

The international standard for archival description is called ISAD(G). It defines twenty-six elements an archival record can carry; six of them are required for any record to be considered complete. archAIc produces all six for every document it describes, plus as many of the optional twenty as the expert has filled in.

The most widely used software for managing archival descriptions is AtoM (Access to Memory), an open-source platform used by national archives, university collections, and institutional records offices around the world. archAIc emits records in AtoM’s own import format — the catalogue manager doesn’t have to do anything special to ingest them. They import a CSV; the records appear in their existing catalogue alongside everything else.

The flow looks like this. The expert reviews a document in archAIc. They confirm the title, the date, the type, the parties named. They press export. archAIc writes a CSV row that AtoM reads. The catalogue grows by one record, with the same shape as every other record in it. From AtoM the record is then visible to whatever else the archive runs — the public access site, the preservation system, the national aggregator. archAIc disappears into the background; the catalogue is what the world sees.

Page images and transcriptions: IIIF

The cultural-heritage world has converged on a family of standards called IIIF (the International Image Interoperability Framework) for serving images of cultural objects. Any modern manuscript viewer — Mirador, Universal Viewer, dozens of others — speaks IIIF. Point one of them at an archAIc archive and everything just works: the pages load, the deep-zoom works, the search works, the place names appear on a map of the world.

A standard IIIF viewer, talking to archAIc. The user typed a name; the viewer highlights every page that mentions it.

The transcription floats over the page as line-level annotations. Click any line; the viewer pans to it. Works in any IIIF-compatible viewer.

Every place named in the book becomes a pin on the map. Click the pin; the viewer jumps to the exact page and line where it’s mentioned.

None of this is bespoke integration. The viewer doesn’t know it’s talking to archAIc. It’s talking to a IIIF-compliant service, and archAIc happens to be one. National aggregators like Europeana and DPLA harvest the same way — they expect a IIIF manifest, archAIc produces one, the records flow.

Knowledge graphs: CIDOC-CRM

Behind every catalogue record is a network of people, places, organisations and events. Historians have spent decades building shared ontologies for describing that network — names of conceptual entities (a person, a group, a place, an event) and the relationships between them (someone participated in something, somewhere is located in a region). The most widely adopted of these ontologies is CIDOC-CRM, originally developed for museums and now used across libraries, archives and cultural-heritage projects of every size.

The entities archAIc extracts are typed against CIDOC-CRM from the start. A person becomes the standard concept of a person; a place becomes the standard concept of a place. When the expert promotes a draft entity to a corpus-wide authority record — once they’re confident this Don Antonio mentioned in fifteen documents is one and the same person — the record fits into the same graph any other CIDOC-CRM-aware system uses.

What that buys is interoperability with the wider linked-data world. Authority records can be linked to Wikidata, to national authority files, to the Getty’s vocabularies of artists and place names. The archive stops being an island and becomes a node in a network.

A working surface for AI assistants

The most recent addition to the list of standards we support is the Model Context Protocol — an open way for AI assistants to interact with external tools. An assistant connected to archAIc can search the archive, browse it, extract entities from any document, run statistics, and cite its sources. The conversation that follows is one a researcher could have had with a particularly patient assistant — except the assistant has read every page.

An assistant asked for a report on a surname across the corpus. With no custom code it picks the right archAIc tools, runs them, and writes a report with citations.

The same rule applies as everywhere else: nothing leaves the system without a source. Every claim in the assistant’s response carries a page and a line. The user verifies in seconds. The system enforces it; the assistant cannot decide to skip it.

The operational side

Beyond the cultural-heritage standards, archAIc supports the things every responsible system supports these days. Authentication and single sign-on tie into the institution’s existing user directory. Every action is logged in a way auditors can read. The system can be run completely air-gapped, never reaching out to any external service, for archives whose materials cannot leave the building. It complies with the EU’s data-protection framework and with the recent EU AI Act’s transparency and human-oversight requirements, both of which fall out naturally from how we designed it — confidence on every claim, a human in the loop on every decision, an audit trail on every change.

---

The short version: archAIc is built to disappear behind the standards. The catalogue manager imports records into the platform they already use. The researcher views pages in the viewer they already use. The aggregator harvests metadata in the format it already understands. We provide a piece of the stack the field was missing — the intelligence layer that turns scanned ink into structured knowledge — and we hand the result to the rest of the world in the languages it already speaks.

← Four ways to ask the same archive

What's *new*.

Four ways to ask the same *archive*.