Appsec deletes a sensitive PDF from object storage but finds its vectors still return in similarity search. What consistency control is missing?
Select an answer to reveal the explanation.
Short Explanation
Trashing the PDF but leaving the embedding is like shredding the letter and keeping the carbon copy in the search drawer. Deletion has to hit the index too—right-to-delete means purge both.
Full Explanation
Purge consistency between object storage and the vector index so deletions remove embeddings as well as files is the missing consistency control. Deleting a sensitive PDF from object storage while its vectors still return in similarity search leaves searchable residues of content the county intended to remove. Right-to-delete and incident cleanup fail if only the blob store is updated. Deletion workflows must remove or tombstone related vectors, sparse indexes, and caches in the same control plane.
Claiming object-store deletes always cascade to every vector index by default fails by concept: many RAG stacks require explicit index deletes or reindex jobs. Asserting vectors expire automatically one hour after any PDF deletion fails as an assumed default that must be engineered and verified. Claiming similarity search cannot return content after the source PDF is unlinked fails because vectors and stored chunk text often remain independently queryable.
Exam caveat: Storage delete ≠ knowledge delete. Civic RAG needs dual-write deletion or verified cascade across object store and vector index.
Operational check: Delete a fixture sensitive PDF, immediately query the index for unique tokens from that file, confirm zero hits, automate cascade delete in the ingest service, and include vector purge proofs in records-deletion runbooks.