What is RAG, and why do versioned documents need dates?
Retrieval-augmented generation, or RAG, lets a language model answer using material retrieved from external sources. In an enterprise assistant, those sources might be policies, procedures and product manuals. Document versioning tracks the changing text of a document alongside the circumstances in which each version applies. Combining the two requires more than finding a relevant paragraph: that paragraph must be valid for the event being discussed. A clear answer with a working source link can still lead to the wrong decision when it relies on the wrong version.
For example, today's travel policy and last year's policy may use almost identical language. Semantic search can rank the old paragraph more highly and answer a current question using an obsolete limit. Upload time, modification time and effective date are different facts. A file uploaded in August might have been effective since July, while the current file may be inappropriate for a historical event. Resolve the question's date, region and controlling date type before choosing sources. A user's role can affect a rule's applicability; permission to read the document requires a separate check. Do not leave validity to the model's intuition or a filename containing the word final.
Effective-date retrieval rules
Complete the following decision table for each document family. For current questions, make the organisation's date and time zone explicit. For historical questions, retrieve the version effective when the event happened rather than automatically showing the newest text. If a policy uses submission date instead of travel date, verify that choice in the controlling source. Ask a clarifying question when a missing date or region would change the answer. These rules determine which documents are eligible before semantic relevance decides their order.
| Question context | Retrieval rule | Expected behaviour |
|---|---|---|
| Current rule | Effective today and applicable to scope | Show the chosen date and version |
| Event on a specified date | Version effective on the event date | Preserve access to historical text |
| Event and submission dates differ | Date type defined by the policy | Escalate if the rule is missing |
| Start or end boundary | Inclusive start and exclusive end | Verify exactly one version applies |
| Overlapping effective versions | Approved priority or exception rule | Explain unresolved conflicts |
| Missing validity metadata | Exclude from automatic policy answers | Request confirmation from the owner |
An inclusive start and exclusive end is a suggested implementation convention, not a universal policy requirement. Follow the source if it defines boundaries differently. The convention prevents both versions from being treated as active on the handover date. Selecting only the highest version number can also miss regional exceptions or include a document whose effective date is still in the future.
Make the resolved date visible in the answer interface. If the user says last month and the policy changed during that month, do not silently choose one day. Ask for the event date or narrow the period before answering. Preserve the user's original date wording and the resolved date separately in the log so reviewers can inspect that interpretation.
How to store document and passage metadata
Assign a stable identifier to each policy and a separate version identifier to each text revision. Retain the original file, parsed text and content hash so you can confirm that a citation has not silently changed because a different file was later uploaded to the same address. Record region, product, applicable role, owner, approval status, effective start, effective end and the relationship to the replacement version. A missing end date may mean open-ended validity; a missing start date must not automatically mean the document applies throughout all history.
Carry those fields into every passage when you split the file. Preserve heading, clause number and page or paragraph range. Do not separate a table from a footnote that controls its exceptions without retaining their relationship. Avoid combining text from two versions into one passage. A change history can be stored separately, but distinguish the operative rule from material that merely explains a revision. The citation should open the exact clause in the selected version rather than a generic page for the document family.
Where several scopes overlap, do not invent a general rule that the newest document always wins. Ask the policy owner to approve the relationship between a country appendix, departmental exception and main policy. Dates alone may not be enough: a draft, an approved future policy and a withdrawn policy are different states. Ingestion validation should report overlapping intervals, reversed start and end dates and replacement relationships pointing to missing versions. Resolve those defects as data issues before the assistant starts using the documents.
Connecting retrieval, updates and caching
At request time, resolve the effective date, controlling date type and scope into structured fields. Combine them with access controls to define the eligible set; semantic similarity then ranks relevance inside that set. Azure AI Search's filtering documentation describes how metadata conditions restrict eligible documents. For vector retrieval, check the product's filtering stage and choose a configuration that searches the valid candidate set. Do not execute free-form user text as a filter expression. Validate dates and identifiers through application rules and construct the query from known fields.
Validate a new version, generate its passages and check it with trial queries before making it active. Apply the old version's end date and the new version's activation through a consistent transition. Preserve separate timestamps for ingestion and query execution. Microsoft's indexer troubleshooting guidance explains that scheduling, processing limits and mappings can leave a source document missing from the index. A successful file upload therefore does not demonstrate that the correct policy is searchable. Verify the actual passages and their metadata, rather than relying only on an ingestion job's summary.
Invalidate current-answer caches when a policy changes. For historical answers, include document family, selected version, effective query date, scope and permissions in the cache identity. If new information is delayed, show the last verified index time and avoid presenting an unverified rule as settled for a consequential decision. Logs should preserve the selected date, applied filter, returned version identifiers and citations. These records make it possible to determine why an obsolete passage was used and whether the fault was interpretation, filtering, indexing or caching.
Hypothetical example: a June trip submitted in August
Suppose a fictional company's travel policy version 3 requires approval for domestic accommodation above 4,000 TRY per night. Version 4, effective on 1 July, raises the limit to 5,000 TRY. An employee submits a 4,500 TRY stay from 20 June on 5 August. If the policy explicitly uses travel date, version 3 is the correct candidate; asking the question in August does not make version 4 applicable. The answer should explain that approval is required and show the controlling date and clause. It should not infer the date rule merely because one version appears more recent.
Create three cases with the same amount for 30 June, 1 July and 2 July. Under the suggested half-open interval, version 3 ends on 1 July and version 4 starts that day. Approval is required for the first stay; that amount alone does not require it for the other two. Preserve any separate conditions that can still require approval. If submission date controlled instead, version 4 would apply even to the June trip submitted in August. If neither document states the controlling date, return the relevant clauses and ask the policy owner to resolve the ambiguity. All amounts and policy terms here are illustrative, not an account of a real organisation or a legal requirement.
A test plan for version correctness
- Test boundary dates. For every handover, ask questions for the preceding day, effective day and following day. Verify expected document and version identifiers in raw retrieval results, before judging the generated answer.
- Change the scope. Ask the same question for different regions, products and roles. An inapplicable passage must not become eligible simply because it has a higher similarity score.
- Exercise ambiguity. Add missing dates, conflicting versions, drafts and withdrawn documents. Specify the expected clarification or abstention instead of rewarding a confident answer.
- Separate support from validity. The Ragas faithfulness metric checks whether claims are supported by retrieved context. Also measure whether the selected version actually applies to the event.
- Measure update delay. Record the time from policy approval to the first verified query using the correct version. Include stale caches, partially indexed revisions and access changes in the test.
Common mistakes
- Using the upload timestamp as the effective date and leaving version metadata incomplete.
- Keeping only the newest text and deleting the evidence needed for historical questions.
- Letting vector similarity determine validity and retrieve obsolete but closely matching passages.
- Interpreting start and end boundaries inconsistently and making two versions active together.
- Treating a good faithfulness score as proof that the answer is current and applicable.
How Hatson Tech builds this
We start with document owners to agree on controlling dates, scope and version transitions. We carry those decisions into the index schema and acceptance tests in our RAG and semantic search solutions. For source scope, see our article on RAG with Turkish legal data; for enforcing access boundaries, see permission-aware retrieval. A technical pilot verifies historical answers as well as current ones and ensures that an unresolved policy ambiguity does not silently become a definite rule in the assistant's response.