On this page
The short answer
Test time-sensitive RAG with an explicit as-of date and applicable source revision. Publication, ingestion, and effective dates describe different events; the answer must use the date relevant to the question.
What to take away
- Keep effective and ingestion times separate.
- Test date boundaries explicitly.
- Retain historical questions and sources.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Define the time model
Azure documents change tracking for indexed sources, but a recently indexed record is not necessarily the rule currently in force. Store source publication time, effective start and end, last update, and ingestion time separately when available. Define the timezone used for boundary comparisons. An application answering “what applied when I subscribed?” may need an older policy, while “what applies today?” requires the currently effective rule, excluding an already-published future-effective revision until its start date.
Evidence: Change and delete detection using indexers [1]Run or reset indexers [2]
Build a three-revision fixture
Author a subscription policy with a June rule, an August revision effective in September, and an October notice that only corrects formatting. Ask what applies on August 31, September 1, and at a stated historical purchase date. The acceptance rule follows effective periods, not the newest file timestamp. Add an unspecified “now” question and define the request-time reference used by the application. This makes apparent freshness testable rather than allowing the evaluator to assume its own clock.
Inspect retrieval eligibility and generation
Record the as-of date resolved from the user’s question, the eligibility filter, source revision, and the timestamp shown in the answer. Check both that applicable evidence is retrieved and that obsolete or future rules are not silently mixed into the response. An older source may be relevant background but should not override the applicable rule. If dates conflict or are missing, the expected response should state the uncertainty instead of guessing a chronology from document ordering.
Test update delays separately
Simulate a source change in a controlled test corpus and observe when the index and cached contexts reflect it. Measure that operational delay independently from whether the model chooses the right effective policy once both versions are visible. A slow index and a mistaken temporal inference require different repairs. Preserve old and new snapshots so historical evaluation remains reproducible. Avoid rewriting the expected answer on every run without recording why its date-dependent truth changed.
Set an evidence-based freshness requirement
Choose freshness targets from the business consequence of stale information rather than a universal number of minutes. A frequently changing inventory assistant and an archived handbook search have different needs. Require critical date-boundary cases to pass before adopting a new temporal filter or cache policy. Include the date basis in failure records and user-facing qualifications when necessary. A response should not claim “latest” merely because the retrieval call ran recently; it needs applicable evidence supporting that statement. Test an explicitly historical request after a new policy is published. It should still use the older applicable rule rather than treating freshness monitoring as a command to answer every question from the newest source.
Limits of the evidence
The dates and policies are illustrative. This is a temporal evaluation method, not legal advice or a claim about any provider’s indexing delay.
Common questions
Is the newest document always applicable?
No. Its effective date, question date, authority, and scope determine applicability.
Should archived documents be removed?
Not necessarily. Historical questions can require them, with eligibility rules that prevent accidental use for current questions.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- Change and delete detection using indexers Microsoft · Living reference · Maintained documentationReviewed: change tracking and explicit deletion detection requirements. Accessed October 16, 2026.
- Run or reset indexers Microsoft · Living reference · Maintained documentationReviewed: indexer change tracking, reset and resynchronization distinctions. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.