RAG Deletion Propagation: Make Removed Documents Stay Removed

An employee deletes a confidential handbook page from the source repository. Search no longer finds the file, yet the assistant still quotes a chunk preserved in a vector index and a semantic response cache.

RAG deletion propagation is a distributed-systems problem. A document can survive as raw text, parsed content, chunks, embeddings, keyword indexes, reranker features, prompt traces, caches, evaluation fixtures, replicas, and backups. A successful delete must address each representation according to policy.

Build Lineage Before You Need a Purge

Assign every ingested source an immutable document version ID. Derived chunks should carry the source ID, version, tenant, authorization scope, ingestion job, index generation, and content digest. Embedding records need the same lineage rather than only opaque vector IDs.

Record which caches and downstream datasets may contain derived content. Exact per-answer lineage is ideal for high-risk systems; dependency tags by corpus generation may be sufficient for lower-risk workloads.

Do not use a filename as identity. Files can be renamed, paths reused, and two connectors can expose the same underlying document. Maintain a canonical source identity plus connector-specific aliases.

The lineage graph should answer a concrete question: given deletion event D, which live serving objects can still disclose information derived from the target?

Use Tombstones, Not Silent Absence

A source connector that simply stops emitting a deleted record leaves downstream systems unable to distinguish deletion from a delayed crawl. Emit a signed or authenticated tombstone with source ID, deleted version, event time, reason class, and required purge deadline.

Consumers process the event idempotently. Mark the source unavailable first, then remove or hide chunks from retrieval, delete embeddings and keyword entries, invalidate response and retrieval caches, and advance any corpus generation that cannot support selective deletion.

During propagation, retrieval should fail closed. A deny set keyed by source and version can block results before every physical replica finishes cleanup. Keep the deny set until deletion completion is verified across regions.

Handle updates explicitly. Replacing version 7 with version 8 is not always permission to preserve derived content from version 7. If the old version contained incorrect or restricted data, issue a tombstone for it as well as publishing the replacement.

Define Scope for Logs and Backups

Serving indexes should have a short deletion service-level objective. Operational logs, security audit trails, and backups may follow different retention rules, legal obligations, and access controls. Document those boundaries instead of claiming that every bit vanished instantly.

Minimize prompt and response logging in advance. Redaction, encryption, short retention, and separated access reduce the number of systems a purge must touch. A hash may remain useful for audit correlation without retaining the deleted text.

Backups should age out under a defined schedule and must not silently restore tombstoned records. A restore procedure needs to replay the deletion ledger after the snapshot is loaded and before serving resumes.

If model training or fine-tuning consumed the content, index deletion is not model unlearning. Treat that as a separate governance path with its own feasibility, commitments, and evidence.

Prove Non-Retrievability

Test deletion using canary documents with unique phrases. After issuing a tombstone, query exact phrases, paraphrases, metadata filters, alternate tenants, stale regions, and direct object IDs. The result should be denied or absent within the stated deadline.

Track tombstone lag by consumer, orphaned chunks, unknown-lineage records, cache purge latency, replica completion, backup expiry, and restore-replay tests. Block new ingestion deployments if lineage coverage falls below the level required to execute deletion safely.

Produce an audit record containing the deletion event, systems targeted, counts removed or blocked, verification queries, exceptions, and responsible owner. Do not put the deleted content itself into the certificate.

Deletion works when it is designed as a durable event, not a button on the source document. Lineage finds the copies, tombstones communicate intent, deny sets protect the propagation window, and adversarial verification proves that the retriever can no longer bring the material back.