How do you handle superseded regulatory documents in a RAG system?

A vector index ranks by semantic similarity. Nothing in that operation knows about time, authority or revocation. Ask about a procedure and the index returns the passages that discuss it best — which will include the 2023 circular that the 2025 one replaced, often ranked above it, because the older text is longer and more explicit.

The generation step then makes it worse rather than better: it synthesises fluently across both, producing an answer that reads as authoritative and quietly merges two regimes. This is the failure mode that matters in regulated work, and it is not a hallucination in the usual sense — every sentence is grounded in a real document. The document is simply no longer in force.

The unit that matters is not the document, it is the lineage: the sequence of versions through which an obligation has passed. Each version needs four properties, and they have to be established at ingestion, because reconstructing them later from PDFs is guesswork:

• —Lineage identifier. What thing is this a version of. Two documents with different titles can belong to the same lineage; two with the same title often do not.
• —Version identifier. Immutable, and referenced by every chunk derived from the document, so a retrieved passage can always name its origin exactly.
• —Validity interval. From when, and until when — where the end is open until a successor closes it. This is what makes 'in force' computable.
• —Relation to the predecessor. Replaces, amends, integrates, or revokes. The distinction changes the answer: an amendment leaves most of the earlier text standing, a revocation does not.

Where the source publishes structured metadata, use it. Where it does not — which is most sectoral publishing — extraction of these four fields is a task worth doing with review in the loop, because an error here propagates into every answer the lineage ever grounds. In the Federfarma deployment the version chain is explicit and visible in the answer, so the reader can check the claim rather than trust it.

The temptation is to retrieve everything and instruct the model to prefer recent documents. This does not work reliably and cannot be audited: the instruction is a request, not a constraint, and nothing in the record shows which documents were in play.

The correct place is metadata filtering in the retrieval query itself. A question is evaluated against a reference date — normally today, but explicitly the date in question when a user asks about the past — and only versions valid on that date are eligible. Superseded versions remain in the index, retrievable when a historical question calls for them, and marked in the result so that neither the model nor the reader can mistake one for current.

Two refinements matter in production. Retrieve the successor alongside a superseded hit, so the system can say what replaced it rather than simply refusing. And keep the eligibility decision in the record — an answer that cannot show which versions it was allowed to see is not reconstructable, whatever else it logs.

The last part is interface, and it is where the burden actually shifts. An answer that cites “Circular 12/2025, in force since 3 March 2025, replacing Circular 7/2023” with a link to both is checkable in ten seconds. An answer that cites a title and a page number asks the reader to trust it, and in a regulated environment the reader is the one carrying the professional responsibility for acting on it.

This is the difference between a system that reduces compliance burden and one that merely moves it: the burden of establishing what is current sits in the system, and the evidence for it is on the screen.