No anchor, no entry

archAIc treats unanchored extraction as hallucination. Every entity, every event, and every relationship that the system stores or returns must carry at least one mention: a (page, line) reference, with an anchor confidence score, pointing at the ink that supports the claim. Records without that anchor are dropped at write time and filtered at read time. There is no path through the API that exposes them.

This is the product’s most important property after probabilistic indexing. Everything else in archAIc, the DLU graph, the entity layer, the timelines and maps and exports, leans on this single rule.

What the rule actually says

The rule is enforced in two places.

At write time. When the autofill pipeline extracts persons, places, organisations, events, and relationships from a DLU, the reconciliation pass walks the LLM output and discards anything without at least one valid (page, line) mention. The prompt itself tells the model: if you cannot cite specific lines, do not include the item. Items that come back without anchors are dropped before the database insert. The unanchored rows are not stored, surfaced, queued for review, or counted toward extraction yield.

At read time. Every query that returns entities, events, or relationships filters on mentions being non-empty. The DLU detail endpoint, the cross-DLU rollup, the search API, the MCP tools, the IIIF annotations, and the exports all read through the same gate. A row that somehow survived write-time enforcement (an older migration, a manual SQL insert, a bug) is still invisible to every consumer. The defence runs at both ends.

Why this matters

LLMs invent things. They invent confidently. An extraction pass over a 19th-century notarial protocol will routinely produce entities that the LLM constructed from context, from its training data, or from inference (“if there is a marriage there must be a priest, so here is a priest with no name on the page”). Those entities look superficially the same as the real ones. A cataloguer who sees twenty extracted persons on a screen cannot tell, by reading the screen, that three of them have no actual evidence in the document.

The no-anchor rule removes the ambiguity at the structural level. If a record is in the database, it has a (page, line). If it has a (page, line), a cataloguer can click it. If a cataloguer can click it, the page image opens with the source line highlighted. The cataloguer is judging a real extraction against real ink, not chasing the LLM’s confident inventions.

The rule also disciplines the LLM. Telling the model “you may only include facts you can cite specific lines for” measurably reduces the rate at which it invents intermediate entities. The prompt is not just a polite instruction; it is the contract that the rest of the pipeline enforces. The LLM learns that unanchored output is wasted output, and behaves accordingly.

How this differs from generic LLM RAG

Most retrieval-augmented generation systems treat citations as a polish layer. The LLM produces an answer, the system asks the LLM to add citations, the citations are returned alongside the answer, and the user is mostly expected to trust both. If the LLM cites the wrong passage, the answer still ships. If the LLM cites no passage, the answer still ships. Citations are a confidence cue, not a structural invariant.

archAIc inverts that relationship. The mention is the primary key on the record. The mention is what the schema demands, not what the model is asked to volunteer. There is no path through the system that returns an unanchored fact, because there is no row in the database without mentions. The model can refuse to produce a claim. It cannot produce a claim that the system silently strips of its evidence.

The downstream effect is operational, not just philosophical. A discovery portal that consumes archAIc through its MCP server or its export package does not need to teach its agent to verify citations. The citations are guaranteed to exist. An archive director writing a grant report can promise that every named person and place in the published catalogue is backed by a folio reference, because the database structurally cannot say otherwise.

What the cataloguer sees

The visible consequence of the rule is the click-to-image action everywhere in the UI. Every extracted person in the drawer, every event on the timeline, every place on the map carries a “go to source” link. The link opens the IIIF viewer at the right (page, line) with the ink highlighted. If a record has several mentions (a person named three times across four pages), all three are jumpable.

The badge next to each extracted record also reads off the same anchor. An anchor confidence of 0.86 means the PrIx evidence on those lines is strong; 0.31 means the lines were noisy and the extraction is a candidate for skepticism. The number is not a generic LLM self-report. It is the score the system computed against the actual ink at the actual (page, line) the record points at.

What the rule excludes

The rule excludes a class of work the institution has to do another way. A person mentioned obliquely (“the alcalde”) but never named is not an extracted entity in archAIc. The cataloguer can add an annotation, can create the entity manually after locating the relevant line, can resolve “the alcalde” against the council’s contemporary records by hand. What the cataloguer cannot do is let the LLM produce un alcalde con nombre y apellido with no line to defend the name on.

That tradeoff is deliberate. The institution gets a smaller, slower-growing graph than a generic LLM extractor would produce. It also gets a graph that survives audit, that can be cited in a thesis or a court filing, and that is structurally exportable to Linked Art, EAD, or EAC-CPF without an extra verification pass. Every claim ends at ink on a folio. That is what makes the catalogue worth keeping.