Retrieval freshness

Name the owner of a stale-answer incident

Source editors, ingestion engineers and application teams each control part of freshness. Give support one route to coordinate them when an old answer is still being served.

In this article

Start with the user's report

A user usually knows that an answer is outdated, not whether a connector, cache or document owner caused it. The handover should name the team that accepts that report and follows it to resolution. Internal ownership boundaries should not become a sequence of tickets the user must navigate.

Give that team a minimal evidence checklist: answer identifier, affected claim, expected source revision and time observed. Explain how to obtain these details without copying confidential text into a general support system.

Keep a clear route to the source owner. Sometimes the published material itself is wrong or the expected update was never approved. Engineering can diagnose delivery, but it should not decide which policy is authoritative.

Transfer the source contract

For each connector, document how changes and deletions are discovered, which identifiers remain stable and what retention or checkpoint limits apply. Include known gaps such as sources that overwrite files without preserving versions.

Describe the freshness classes and their agreed intervals. State what happens during delay: continued service with a notice, exclusion of affected material or another defined behaviour. A schedule without a reader-facing rule leaves the receiving team to improvise during an incident.

Provide the location of revision and dependency records. An operator should be able to trace one answer back to its passages and source without reading the entire ingestion codebase.

Practise the exceptional paths

During handover, have the receiving team process an ordinary update, withdraw a source and recover a deliberately failed extraction. Include a delayed old event so they can verify that replay does not restore superseded content.

Ask them to identify the oldest pending change and explain why it has not completed. This tests whether dashboards show useful per-source state rather than only aggregate success rates. Fix confusing labels and missing links revealed by the exercise.

Transfer the rebuild and rollback procedure as well. The team needs to know how a replacement index catches up with source changes and how cached answers are treated at activation.

Keep ownership current

Assign maintenance of the connector inventory, freshness probes and source classification. New collections should not enter the system with an assumed default that nobody has accepted.

After an incident, update the runbook at the boundary that failed. If a source system changes its deletion behaviour or an application adds a new cache, revisit the freshness path. Ownership is complete when someone is responsible for the end-to-end outcome and the supporting teams can identify their part in restoring it.

Primary sources

Microsoft Learn: monitor indexer statusOWASP: logging guidance

References checked 11 September 2026.