Which version is true
A corpus contains four copies of the same policy, two of them drafts, one never approved but circulated widely enough to look canonical. Ranking by relevance returns all four. Deciding which is current is not a retrieval question.
20 May 2026
Ask people what goes wrong with document search and almost nobody says it found nothing. They say it found the wrong version: a superseded policy, a draft nobody signed, a rate card from two price changes ago, all of it presented with the same confidence as the current one.
This is a hard problem dressed as an easy one. Sorting by date gets you maybe half way, and then three things break it. File dates lie. The newest document often isn't the answer. And supersession is a claim documents make about each other in prose. Metadata never carries it.
File dates lie routinely
Modification time is a property of the copy, not the content. A file copied to a new drive, restored from backup, or synced by a tool that rewrites timestamps carries a date that says nothing about the document. In one donated corpus, 34% of files had a modification time inside one three-day window, which is when the migration ran.
Creation dates inside a PDF are better and are still the date of the file's generation, so a scanned copy of a 2019 contract is dated the day someone put it on the glass.
What is reliable is the date written in the document by the person who wrote it: an effective date, a version line, a signature block, a revision table. Those are content, and content survives copying. So we extract dates from text and treat filesystem metadata as a weak fallback, never the primary signal.
| Signal | Coverage | Agreement with ground truth |
|---|---|---|
| Effective date in body text | 41% | 98% |
| Version or revision line | 29% | 96% |
| Signature block date | 18% | 94% |
| Date in filename | 37% | 88% |
| PDF creation metadata | 82% | 71% |
| Filesystem modification time | 100% | 52% |
Note the shape: the signals with the best coverage are the worst, and the best signals are present less than half the time. There is no single field to sort on. What works is combining several with their reliabilities, and keeping the uncertainty when they disagree rather than picking a winner and forgetting there was a question.
Newest is usually right and sometimes exactly wrong
"What is our parental leave policy" wants the current version. "What was our policy in 2023" wants the superseded one. "When did we change it" wants both, and the change between them. A recency prior that is hard-coded gets the second and third classes wrong; no prior at all gets the first class wrong — most questions.
So recency is a query-conditional signal. Questions carrying a time expression, an explicit past-tense frame, or a comparison suppress the prior. Everything else applies it. This is a classifier, it is not perfect, and when it is unsure the answer covers both. Worse to read, and much harder to be wrong with.
Supersession is written in prose
Documents announce their own obsolescence, in text: "supersedes the version dated", "replaces policy 4.2", "draft — not for circulation", "this agreement amends". These statements are extremely reliable when present, because nobody writes them by accident.
We extract them and build a supersession graph over the corpus. A superseded document isn't deleted or hidden. It stays retrievable, and stays correct for historical questions. But it won't be offered as current unless the answer says a later version exists and names it.
The failure is not retrieving an old document. It is retrieving an old document without mentioning that it is old.
Drafts are a separate axis
Draft status and recency are independent, and conflating them is a mistake we made for a while. The newest document in a set is frequently a draft, and a draft is often the version most people have seen, because it was the one that got emailed around. Draft markers (watermarks, filename conventions, status fields, an unsigned signature block) are extracted separately and never resolved by date.
Filenames are worth their own note. final_v3_FINAL_reviewed.docx is a joke because it is universal, and the convention actually carries signal: v-numbers, dates, and the words final and draft do correlate with reality, at 88% agreement. That is high enough to use as a tiebreaker and far too low to use as an authority.
What the answer looks like
When several versions are relevant, the answer states the position of the current version, cites it, and says how many other versions exist and what changed if the change is extractable. When the versions genuinely conflict and none is clearly current, the answer presents the conflict instead of resolving it. That is about 3% of version clusters in our corpora.
That last behaviour is the one people initially dislike and then come to rely on. A tool that always produces one confident answer over a corpus containing four contradictory documents is not doing the work. It is hiding it.
Version and supersession logic is in quire/index/versions. The date extractors are locale-aware and the locale list is incomplete; contributions there are always welcome.
Your RAG benchmark is measuring the wrong thing
Staleness, permissions and conflict recall: the properties public corpora do not have.
The Quire Note
One email a month, engineering-first.