Find the layer still serving the old policy

Identify exactly what the reader received

Capture the answer identifier, request time and evidence revisions. Ask which statement is outdated and identify the expected replacement or withdrawal event. A report that "search is stale" is not enough to distinguish an old document from a current document containing an old rule.

Check whether the response came from an answer cache, a saved conversation or fresh generation. These paths can share the same interface while using different data. The quickest useful distinction is often whether retrieval ran at all.

Preserve minimal diagnostic records before invalidating anything. A broad cache flush may temporarily fix the symptom while removing the evidence needed to find the underlying defect.

Walk backwards from the answer

If the answer used a cached result, compare its dependency revisions with the current source status. Look for a missed invalidation event or a cache key that omitted the source generation. If it used fresh retrieval, inspect the returned passage records.

When the index contains the old revision, examine ingestion progress for that source. Did the connector observe the change? Did extraction fail? Was the write accepted but not yet visible? Did a delayed worker overwrite a newer result? These questions map to different records and should produce a specific failure location.

Also verify the authoritative source itself. Sometimes the expected correction exists only in a draft or a separate copy, while the connector is correctly reading the published file. Engineering should not silently substitute a document without the source owner's decision.

Contain the affected material

For an urgent withdrawal, use the application's supported source exclusion or stale-status control if available. Confirm that it affects cached answers and stored previews as required. If no reliable targeted control exists, a broader feature restriction may be necessary for the affected collection.

Do not repeatedly rebuild a large index while queries and ingestion are already under load. First establish whether a rebuild addresses the failed layer. Replaying a broken connector without fixing its checkpoint or ordering rule can reproduce the same stale state.

Keep users informed in terms of the affected information. A message that a particular policy collection is being refreshed is more useful than exposing internal queue names.

Repair and prove the revision path

Apply the smallest repair that addresses the cause, then run a query tied to the new revision. Test a previously cached question and an older saved answer too. Confirm that the late event or worker responsible for the incident cannot restore the old version.

Record the source event, failed boundary, containment interval and verification evidence. Add monitoring at the point that was previously invisible. The incident is closed when the expected revision is served consistently and the route that produced the stale answer has a tested correction.