# Deleting a policy should also retire its cached answers

Removing a document from search does not remove the answers already built from it. Design freshness around the complete route from source to reader.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## There is more than one copy

A policy owner withdraws an outdated procedure. The source file disappears, and the next indexing job removes it from search. A staff member then asks a familiar question and receives yesterday's cached answer, complete with instructions from the withdrawn procedure. The index is current, but the product is not.

Retrieval systems commonly retain information in several forms: extracted text, passages, embeddings, search results, generated answers and saved conversations. Each copy has its own update behaviour. A freshness requirement that only describes the index leaves the other copies without a clear rule.

Start by distinguishing a correction from a withdrawal. A correction may allow a brief period of old information while an update propagates. A withdrawn safety procedure or access revocation may require the application to stop serving affected material immediately, even before background deletion finishes.

## Give derived records a source relationship

Store source identity and version with every passage. For reusable answers, retain the identifiers of the evidence used. This dependency information lets the application find answers affected by a source change. Without it, invalidation becomes a broad cache flush or an unreliable text search.

A source event can mark dependent answers stale while a worker updates the index. The query path should respect that state. If an answer cannot be revalidated within the request, explain that the evidence has changed and offer a fresh search or review path.

### A withdrawal reaches every serving layer

The source change updates an application-owned status before background work removes derived content.

1. **Source change**: Identify the document and new revision or withdrawal
2. **Serving status**: Mark affected evidence and reusable answers stale
3. **Background repair**: Update passages, vectors and caches
4. **Verification**: Query as a reader and confirm old material is unavailable

The status check is a proposed application control, not a guarantee supplied by an arbitrary search platform. Its reliability depends on receiving source events and enforcing the check on every relevant serving path.

## Decide what historical answers mean

An old conversation may be a record of what the system said, not an answer that remains suitable for use today. Preserve that distinction visibly. A timestamp alone is easy to miss and does not tell a reader that the source was withdrawn.

For some products, marking an old answer as outdated is sufficient. Others need to hide restricted excerpts or prevent reuse. Retention and access decisions should be explicit because deleting operational search content is different from retaining an authorised audit record.

## Verify from the reader's side

Test an edit, a withdrawal and a permission change after an answer has been cached. Exercise a new query, a repeated query and an old conversation. Check the evidence identifier in each response so a plausible new sentence cannot hide use of the old source.

Measure from the source event to the last point where stale material can still be served. An indexing job's completion time is only one part of that interval. The requirement is met when the reader-facing behaviour matches the business rule across the entire path.

## Sources

- [Microsoft Learn: changed and deleted source blobs](https://learn.microsoft.com/en-us/azure/search/search-how-to-index-azure-blob-changed-deleted)
- [Microsoft Learn: index updates and rebuilds](https://learn.microsoft.com/en-us/azure/search/search-howto-reindex)