RAG Policies: Retrieve the Right Effective Date

An assistant can cite a real policy and still give the wrong answer. The policy might start next month, apply to a different business unit or have been replaced. Similarity search alone does not settle which rule governs the question.

Consider an example with three travel policies. Version 2 covers September claims. Version 3 applies from 1 October. Version 4 was uploaded yesterday but begins in January. Asked about a September expense, the assistant needs version 2. Asked what staff can claim today, it needs version 3. Sorting by upload time selects neither reliably.

Store business dates separately from file dates

At ingestion, distinguish at least four values: when the document was published, when its rules take effect, when those rules stop applying and when the pipeline last indexed it. Add the policy family, version, approval status and scope.

A small metadata record could contain policy_id, version, effective_from, effective_to, status, business_unit and source_uri. Copy the relevant values onto every retrievable chunk. A date present only on the cover page is easy to lose when a paragraph is retrieved on its own.

Choose one representation for open-ended validity, such as a null end date, and document it. Reject impossible intervals and unexpected missing start dates at intake. Do not ask the language model to quietly invent missing metadata from a filename.

Apply the rule before composing the answer

Azure AI Search supports filters on nonvector fields, including metadata associated with chunks. Its comparison operators support typed range comparisons. These provide the mechanism; the business must still define the interval it means.

For example, an application might use an inclusive start and exclusive end. This illustrative filter assumes matching, filterable fields and UTC date-time values:

status eq 'approved'
and effective_from le 2026-10-17T00:00:00Z
and (effective_to eq null or effective_to gt 2026-10-17T00:00:00Z)

This is a read filter, not a complete authorisation policy. Add the caller's permitted scope separately, and build expressions with the SDK's safe construction facilities rather than inserting arbitrary prompt text.

Bedrock also supports metadata filtering, with supported operators depending on the store. Its documentation illustrates time filtering using numeric epoch values. Check your backend's data types instead of copying the Azure expression into another API.

Decide what an undated question means

For “What is our travel allowance?”, a reasonable product default is the policy effective now, with the applicable date shown in the answer. For “Can I claim this September trip?”, use the event date if the policy owner says that is what governs entitlement. An invoice date, booking date and travel date can lead to different outcomes.

Resolve that ambiguity before retrieval. A short question asking for the travel date is more useful than a precise answer based on an unstated assumption. For a historical enquiry, display the historical date prominently so the answer is not reused as current guidance.

Keep this rule in the application workflow and the policy register. A prompt saying “use the latest information” cannot define whether a contract's signature date or service date matters.

Treat conflicts as an intake problem

Two approved versions with overlapping dates may indicate a real exception or a publishing error. Do not silently choose whichever has the higher similarity score.

Validate overlaps within each policy family and scope. If a regional addendum overrides one section, represent that relationship explicitly and preserve both source references. If two owners disagree, route the question to the policy owner and say which sources conflict.

The Claude Projects context note already explains why curated sources beat a drive dump. A production retrieval service needs the same ownership discipline encoded into metadata and intake checks.

Test the date boundaries, then the prose

Build a test set with questions for the day before a change, its first day and the last day of the old interval. Add a future version, a withdrawn draft, a missing date, an overlapping exception and a question without a date. Where the business uses local calendar days, include a timezone boundary rather than assuming UTC midnight always matches it.

Check the retrieved document IDs before judging the answer. The acceptance result should name the expected version and scope, not simply say that the response sounds correct.

Roll out the metadata filter in a test index or a small approved collection first. If it excludes too much, investigate the missing metadata. Removing the filter to regain a fluent answer hides the defect. A useful fallback is the policy owner's contact and the approved document list until the dates are repaired.

References

• Microsoft, Filters for keyword search in Azure AI Search. Accessed 17 October 2026.
• Microsoft, OData comparison operators in Azure AI Search. Accessed 17 October 2026.
• Amazon Web Services, Configure and customise queries and response generation. Accessed 17 October 2026.