A policy document from three years ago and its current replacement describe the same subject in nearly the same words. To an embedding model they are almost identical, and a similarity search returns whichever happens to score marginally higher. Roughly half the time, that is the obsolete one — and the model then answers confidently from a policy that no longer applies.
This is one of the most consequential and least discussed failure modes in production retrieval.
What changed in 2026
- Metadata filtering became standard in vector databases. Combining similarity search with structured filters moved from a differentiating feature to a baseline expectation.
- Validity modelling got separated from document dates. Recognition spread that when a document was written and when its content applies are distinct, and both matter.
- Superseded-document handling improved. Explicitly marking replaced versions rather than relying on recency scores became the recommended approach.
- Date surfacing in context became normal. Including effective dates in the chunk text itself, so the model can reason about currency, moved into standard chunk construction.
The dimensions of time
| Dimension |
Meaning |
Why it matters |
| Creation date |
When the document was written |
Weak proxy for currency |
| Last modified |
When it was last touched |
Formatting edits inflate it |
| Effective from |
When the content started applying |
The one that usually matters |
| Effective until |
When it stopped applying |
Identifies superseded content |
| Superseded by |
Which document replaced it |
Enables clean exclusion |
| Query time reference |
What period the user is asking about |
Usually now; sometimes not |
Modification date is the trap. A document reformatted last month appears fresh and may describe practice from years ago. Effective dates describe the content; modification dates describe the file.
Making it work
Filter, do not just boost. If a document has been superseded, exclude it from retrieval rather than ranking it slightly lower. A recency boost still lets a strongly matching obsolete document surface, and users cannot tell from the answer that it was stale. Metadata filtering makes the exclusion definite.
Put dates in the chunk text. Storing an effective date in your index lets you filter; putting it in the text the model reads lets the model reason about it. Prefixing each chunk with its effective period costs a few tokens and enables the model to say a document applies to a period the user did not ask about — which is far better than silently answering from it.
Handle "as of" questions. Users occasionally ask what a policy was at a past date, and that requires retrieving the version effective then rather than the current one. Supporting this means keeping superseded versions accessible rather than deleting them, with the filter driven by the query's time reference rather than always by now.
Let recency break ties, not lead. Where two documents are genuinely both current and relevant, preferring the newer one is sensible. Using recency as a primary ranking signal buries older content that remains authoritative.
Combine this with the drift maintenance in embedding drift explained, since a corpus that accumulates versions without curation degrades on both axes at once.
Common mistakes
- No temporal metadata at all. The default, and the cause of confident stale answers.
- Using modification date as currency. A reformat makes old content look fresh.
- Recency boosting instead of filtering. Stale documents still surface.
- Dates only in the index, not the text. The model cannot reason about what it cannot see.
- Deleting superseded versions. Breaks legitimate historical questions.
- Ignoring the query's time reference. Most questions mean now; some do not.
FAQ
Where do effective dates come from?
Ideally from document metadata in your source system. Where absent, extraction from the document text works reasonably, with manual review for high-stakes content.
Should I delete outdated documents?
Usually not. Mark them superseded and exclude them from default retrieval, which preserves the ability to answer historical questions.
Does this apply to a corpus that rarely changes?
Less urgently, and even a slow-changing corpus accumulates superseded content over years.
How do I handle documents with no date?
Treat unknown as a distinct state rather than assuming currency, and surface that uncertainty in the answer.
Where to go next
For relationship-aware retrieval, read graph RAG explained. For index maintenance, embedding drift explained, and for grounding answers to sources, citation grounding in LLMs.