HomeJournalThis post

RAG Citations That Survive Document Change

Build citation receipts that stay verifiable when a source moves, changes, disappears, or is re-indexed.

JP
JP Casabianca
UI/UX designer and full-stack engineer · Bogotá

RAG citations fail quietly when a source document changes after an answer is published: a page number moves, a paragraph is rewritten, or the corpus is re-indexed while the interface still presents the old link as proof. The answer is a citation receipt that binds each supported answer span to a source revision, quoted evidence, a relocatable locator, and an explicit validation state.

This article defines a citation receipt that binds an answer span to a document revision, quoted evidence, locator, and validation state. The goal is not permanent coordinates. It is an honest chain that can say verified, moved, changed, or unavailable after the source evolves.

The implementation vocabulary is retrieval provenance, document versioning, citation validation, and source grounding: four related concerns that must stay connected from indexing through revalidation.

RAG citations: citation evidence survives movement Revision moves to Passage, then Answer, and ends at Recheck; the return path carries evidence back to the first decision. RevisionPassageAnswerRecheckEvidence returns to the next decision.
Figure 1: A citation braid connects the indexed revision and evidence passage to the answer span, then returns through live validation when the document changes.

RAG citations need a receipt

A useful citation record starts with identity: corpus revision, document ID, source URL, retrieval timestamp, and a digest for the bytes or normalized representation that was indexed. Add the chunking strategy and version because a chunk number means nothing after tokenization or overlap rules change. Those fields identify the material the retriever actually saw.

The receipt also needs evidence identity. Store the short quoted passage, its digest, a structural locator such as heading path plus paragraph index, and a byte or character range in the normalized document. Then map that evidence to the exact answer span it supports. RAG citations become auditable when the reader can see which words are grounded by which passage, not merely which documents appeared in retrieval.

My position is that a citation is a claim about provenance, not decoration. The boundary is practical: not every conversational sentence needs sentence-level mapping. Claims that affect money, policy, health, access, or a durable decision deserve the stronger receipt; low-consequence brainstorming can use lighter source grouping.

RAG citations should also identify the retrieval run that selected each passage. Store query or query digest, filters, ranking configuration, and the passage rank when those details can be retained safely. That receipt distinguishes a grounding failure from a later generation failure and makes corpus migrations easier to compare.

Reference note. original retrieval-augmented generation paper is the primary standard, model, or research source for the implementation claim immediately above.

Separate identity from location

Document identity should survive a move. A canonical record ID or content-management identifier is stronger than a URL, because redirects, locales, and navigation change. Location is a separate concern: heading path, page label, DOM selector, timestamp, or bounding box helps a reader reach the evidence inside that identified revision.

Do not depend on one coordinate system. Page numbers work for a fixed PDF but fail after reflow. Character offsets work for normalized text but shift after a heading is inserted. Quote matching survives movement but can become ambiguous when boilerplate repeats. Combining a structural path, local quote, and digest gives revalidation several independent signals.

The trade-off is storage and privacy. Keeping every retrieved passage forever can retain material after its source owner expects deletion. Mitigate that by storing the minimum quote needed for audit, encrypting protected evidence, applying source-specific retention, and preserving a digest-only tombstone when the text must be removed. Provenance does not grant unlimited retention.

Illustrative TypeScript — an interface sketch, not a compiled implementation.

type CitationReceipt = {
  corpusRevision: string;
  documentId: string;
  contentDigest: string;
  chunkerVersion: string;
  locator: { headingPath: string[]; paragraph: number };
  quote: string;
  quoteDigest: string;
  answerRange: [number, number];
  state: "verified" | "moved" | "stale" | "unavailable";
};

Reference note. W3C PROV-O recommendation and RFC 9530 digest fields are the primary standard, model, or research source for the implementation claim immediately above.

SignalDecisionProof
Same digestResolve stored locatorQuote hash matches
Moved passageSearch within new revisionUnique quote re-located
Changed claimMark citation staleContradiction review opened
Figure 2: A stable document, a moved passage, and changed evidence need different outcomes; silently pointing to the newest page is not validation.

Build the first RAG citations fixture

Start with a policy document whose revision A says refunds are allowed within thirty days. Index it, generate an answer that cites the sentence, and save the receipt. In revision B, insert a new introduction so the sentence moves but stays identical. A successful validator should find the old digest is gone, relocate the unique quote under the expected heading, and mark the citation moved but still verified.

Revision C changes thirty days to fourteen. That is not a moved citation. The quote digest no longer matches, and a similarity search now finds contradictory evidence. The correct outcome is stale: keep the historical answer visible if product policy allows, show that its support changed, and offer regeneration against the current corpus. Do not silently attach the new sentence to the old answer.

Add two adversarial cases. Duplicate the same sentence in an appendix so quote matching is ambiguous, then delete the source entirely. The validator should require structural agreement for the duplicate and report unavailable for deletion. This four-revision fixture is small enough to run in CI and specific enough to catch citation laundering.

Revalidate with bounded relocation

Validation should first request the exact revision. If its document digest matches, resolve the stored locator and compare the quote digest. That fast path gives the strongest evidence. If the revision is unavailable but a successor exists, search only within the same document identity and a bounded structural neighborhood before expanding to the whole document.

Relocation needs a confidence rule the application owns. Require a unique quote match plus compatible heading path, or a normalized passage match above a reviewed threshold with no conflicting candidate. A language model can help propose a match, but deterministic checks should decide whether the system labels it verified. Otherwise fluency becomes provenance.

The failure mode is newest-source substitution. A pipeline cannot find the historical passage, retrieves the latest document, and displays its link beside an old answer. The consequence is a visually valid citation that supports a different claim. Mitigate it by preserving revision identity in the UI and refusing to upgrade state when quote or meaning changed.

Design visible citation states

RAG citations need more than linked and broken. I use four states: verified on the original revision, verified after movement, stale because evidence changed, and unavailable because the source cannot be checked. Each state needs plain language and an inspectable detail view. Color can reinforce the distinction but must not carry it alone.

Show the evidence excerpt near the claim, then offer document title, revision, source date, and validation time in progressive disclosure. For a moved passage, explain that wording is unchanged but location moved. For stale evidence, preserve the old quote and show the current conflicting excerpt side by side. That comparison helps a reader understand the change instead of merely distrusting the system.

Avoid a green check that implies the answer is true. The receipt proves a relationship between claim and source; it does not prove that the source itself is correct. A careful label says source match verified. That smaller promise is both more honest and more useful during review.

Give RAG citations a keyboard-operable return path from evidence to the exact claim. A reader who opens a source drawer should not lose their place in a long answer. Preserve focus, announce state changes sparingly, and let copied citations include source title, revision, and stable public URL when one exists.

  1. ResolveResolve

    Load the exact indexed revision when it remains available.

  2. CompareCompare

    Recompute the evidence digest and structural locator.

  3. RelocateRelocate

    Find an unchanged quote in the new revision if it moved.

  4. DeclareDeclare

    Expose verified, moved, stale, or unavailable state.

Figure 3: Revalidation prefers the original revision, attempts bounded relocation, and declares staleness rather than laundering changed evidence.

Measure validation, not citation volume

Counting answers with links rewards decoration. Better measures follow the receipt lifecycle: percentage mapped to answer spans, percentage resolvable on the indexed revision, relocation success for unchanged passages, false-verification rate after contradictions, time to detect source change, and reader success when inspecting evidence. The false-verification metric should carry the highest consequence.

Run the revision fixture whenever chunking, parsers, embedding models, or corpus storage changes. A chunker upgrade can preserve answer quality while destroying old locators. Version both systems and replay receipts before migration. If historic validation cannot be preserved, record the boundary and mark affected citations unavailable rather than pretending compatibility.

Sample real receipts for editorial review, but remove protected content from test artifacts. Compare what the answer claims, what the mapped quote says, and what the current source says. Two concrete observations matter: moved text should not reduce trust when its identity holds, while changed text must reduce trust even when semantic retrieval still ranks it first.

Ship deletion and failure behavior

Source deletion should propagate to stored evidence. Depending on policy, remove the quote, retain a digest and tombstone, and mark every dependent answer unavailable. Keep the dependency index so one document event can find affected claims. A background job without a completion receipt leaves the interface unable to distinguish deletion pending from deletion complete.

Design for partial outages too. If the validation service cannot load the source, say validation temporarily unavailable rather than stale. Cache the last successful validation time but do not convert it into a current check. RAG citations should degrade with explicit state, not disappear and make a sourced answer look unsourced.

Before release, test original, moved, contradicted, duplicated, deleted, private, and temporarily unreachable sources. Inspect the page at narrow widths so quotes and revision details do not overflow. Confirm that keyboard users can move from claim to evidence and back without losing context. Provenance is only useful when a reader can operate it.

Conclusion and implementation references

Reliable RAG citations bind an answer span to a versioned source, preserve enough evidence to recheck the relationship, and show when the source moved, changed, or disappeared. The durable feature is not the locator; it is the honest validation state.

Start with the four-revision policy fixture. Prove that unchanged evidence can move, contradictory evidence becomes stale, duplicate quotes stay ambiguous, and deleted sources become unavailable. That test will expose whether your current citations are provenance or simply links.

This method also sits beside five related Journal notes: AI trace redaction contracts, Merkle inclusion proofs, technical writing as infrastructure, executable API examples, data deletion contracts. Each expands one boundary that this article deliberately keeps narrow, so the links are supporting material rather than competing actions. The three authoritative references are placed beside the specific claims they support above; the framework, examples, failure modes, and implementation judgments are my synthesis.

Use the conclusion as a release boundary: reproduce the named fixture, preserve its evidence, and record any exception before extending the pattern to a higher-consequence workflow. That final receipt makes the method reviewable by someone who did not build it and gives a future update a concrete point of comparison.