Every Claim Needs a Return Address: How Citation Grounding Works in Practice
An AI system that produces correct answers is useful. An AI system that produces correct answers with traceable sources is auditable, retractable, and trustworthy in production. The gap between those two things is not a retrieval problem. It is an architecture decision, and it runs through every linked-data project in this portfolio.
Fluent output without provenance is not evidence
The core failure mode of AI-assisted content is not the hallucination that is obviously wrong. It is the hallucination that sounds right, cites a plausible source, and ships into a page that will be read by someone who trusts the platform it came from.
Consider what happens when a language model writes about a 19th-century Hawaiian chieftain. The model has absorbed enough text about Hawaiian history to produce a fluent, confident paragraph. It may even produce a citation, naming a book or a document that sounds credible. The problem is that the model cannot verify whether the citation resolves to a real record, whether the record says what the model claims it says, or whether the subject of the article is actually who the model thinks they are.
A citation that the system cannot verify is not a citation. It is a rhetorical gesture. The difference between a rhetorical citation and a real one is whether the pipeline ever checked.
Every linked-data project in this portfolio treats citation verification not as a post-hoc quality check, but as a gate that governs what enters the system at all.
Claim-level grounding, not document-level trust
The standard approach to grounding an AI output is to retrieve relevant documents before generation, then hope the model stays close to them. Retrieval-augmented generation is better than pure generation, but it still leaves verification to the model's judgment. The model decides whether it is saying something the retrieved documents support.
A citation gate works differently. Instead of asking the model to stay grounded and trusting that it has, the pipeline requires the model to produce structured output that pairs each claim with a specific source reference. The pipeline then independently verifies that each reference resolves to a real record with the claimed content. If a claim cannot be verified independently, it does not enter the system.
This is claim-level grounding rather than document-level trust. The distinction matters because models fail at the claim level, not the document level. A model can retrieve the right document and still produce a sentence that misrepresents it. Claim-level verification catches that. Document-level retrieval does not.
Three systems, three citation architectures
Each implementation below illustrates how the same pattern adapts to a different source type: a structured knowledge graph, an open SPARQL endpoint, and a research interface built for evidence inspection.
"From Wikidata" as a constraint, not a badge
The badge on each MetaHistoryBook dossier that reads "From Wikidata" is not decorative. It is a constraint enforced at the pipeline level: every claim in an AI-generated dossier must trace to a real Wikidata entity, a verified Wikipedia passage, or an attributed Wikisource quote.
The agent produces structured output pairing each sentence with its source reference. The pipeline verifies each reference before the dossier can enter the review queue. A dossier with a single unverifiable claim does not enter the queue at all.
The practical effect is that the human reviewer is never in the position of checking whether sources exist. The mechanical gate handles that. The reviewer decides whether the AI's interpretation of a real source is accurate and appropriate, which is a judgment call a human can make well.
SPARQL as the source of record
Every article that Artwork of the Day publishes is built from SPARQL queries against Wikidata WDQS. Painting metadata, artist biographical data, movements, institutions, and geographic context all come from Wikidata properties with explicit Q-number identifiers.
Every fact on the page has a Wikidata entity as its source of record, which means every fact can be independently looked up, verified, and traced back to its origin. The SPARQL query that produced the article is the citation.
This is the most minimal form of citation grounding: use a queryable, open knowledge graph as the sole data source, and make the query the evidence. No model inference. No rhetorical citations.
Making the evidence chain inspectable
Wikidata Explorer is built for researchers who need to see the evidence behind a claim, not just the claim. Every entity in the explorer surfaces its Wikidata properties with P-numbers, statement qualifiers, and references. The linked-data research view makes the provenance chain legible to a human without requiring them to write SPARQL.
The AG2-backed research agents follow the same principle: when an agent assembles a cited research summary, it is required to surface the Wikidata entity identifiers and property paths that support each statement. The summary is a structured navigation of evidence that already exists in a public, verifiable graph, not a synthesis.
Rights and subject provenance as pipeline properties
Images are harder than text. A IIIF manifest may describe a work in detail without resolving the specific reproduction rights for that exact image URL. MetaMuseum handles this through a dedicated agent, Themis, whose only job is provenance and rights review. Every image and object record carries a rights state that must be resolved before the record is eligible for human review.
The Big Aloha Guide image pipeline handles a different provenance question: subject identity. The ledger it maintains is keyed on image URL and subject, so wrong-subject rejections are remembered across pipeline runs. Provenance here means not "is this image rights-clear" but "has this image been verified to show what we say it shows."
Provenance as a persisted property, not a pipeline run
Both the rights state and the subject identity examples above share a structural feature: the provenance judgment travels with the record. It is not recomputed on each pipeline run. Once Themis resolves a rights conflict, that resolution is persisted. Once the Big Aloha Guide image ledger records that an image of Kīlauea depicts the wrong crater, that record is available the next time the same image surfaces in a different article.
This is the difference between provenance as a pipeline property and provenance as a record property. A pipeline property is ephemeral: it exists during the run and is discarded afterward. A record property is durable: it accumulates over time and can be consulted before any future work begins.
The practical consequence is significant. A pipeline that treats provenance as ephemeral will rediscover the same rights conflicts and wrong-subject associations on every run. A pipeline that persists provenance judgments stops making the same class of mistake twice. The ledger is not a quality report. It is a memory that the pipeline consults before it acts.
What citation grounding requires from the architecture
Citation grounding is not a quality initiative applied to an existing pipeline. It is an architectural constraint that shapes what the pipeline can produce from the start. Four decisions determine whether a system has it.
- Structured output with source pairing. The model must produce output that pairs each claim with a source reference. Free-form generation with citation instructions does not guarantee pairings that can be independently verified. A structured output schema with required source fields does.
- Independent verification before queuing. The pipeline verifies each source reference independently, before the item enters any queue or review stage. This is not a model self-check. It is a deterministic lookup by the pipeline against the actual source, whether a Wikidata SPARQL endpoint, a Wikipedia API, or a rights database.
- Claim-level rejection, not document-level rejection. An item that contains one unverifiable claim is rejected at the gate, not flagged as mostly verified. Partial verification is not a weaker form of verification. It is a different system with different guarantees.
- Provenance as a persisted record property. Once a provenance judgment is made about an item, it travels with the item across all future pipeline runs. The ledger that holds the judgment is the source of record for that item's provenance state, not a log file.
The practical result of these four decisions is a system where the question "where did this fact come from" is always answerable by the pipeline, before a human ever sees the item. That is a different class of system from one where the answer is "the model said so."
Systems built with citation grounding produce less, more slowly, and more reliably. That tradeoff is the whole point. A fact that cannot be sourced does not belong in a production system. The pipeline enforces that, so the humans reviewing the output do not have to.