RAG freshness: last month's PDF is not a lookup problem

The retrieval trace looks exemplary. Clause 12.3 ranked first, entered the context, and supports the answer. The answer is still wrong.

The signed amendment never reached the index.

RAG freshness is the managed agreement between an authoritative source and the index that answers from it. It says how old the indexed state may become, how changes reach it, and what the product does when that agreement is breached. Retrieval quality cannot recover a document the index has never seen. What is RAG? defines the architecture. This page defines the clock running underneath it.

Stale index and stale embeddings

A stale index no longer represents the source state you agreed to serve. The source was edited, replaced, deleted, or moved behind a new permission boundary, and the index still carries the older state.

The fault can live outside the vector store. Keyword indexes, metadata tables, reranking features, document caches, and generated summaries all retain superseded content. “We rebuilt the embeddings” is incomplete while an old lexical entry or a cached answer can still be served.

A stale embedding usually means one of three things:

1. The vector was computed from text that has since changed or been withdrawn.
2. The embedding model changed and stored document vectors were never migrated, so the index mixes vectors from two model generations and query vectors match neither reliably.
3. The preprocessing changed, with new chunk boundaries, a new analyzer, or a new cleaning step, while old vectors stayed in place.

Time alone does not spoil a vector. If the source text, the permissions, the preprocessing, and the embedding model are unchanged, re-embedding every night buys cost, not freshness. What goes stale is the relationship between the stored representation and the source it claims to represent.

TTL is the boundary, not the update

A time to live answers one question: how long may this corpus be served without a successful freshness check?

It does not detect a changed paragraph, fetch a replacement, remove a revoked document, or rebuild an index. Those jobs need a propagation path:

authoritative change
→ change signal
→ ingest or deletion event
→ transformed document and metadata
→ candidate index version
→ evaluation
→ atomic serving cutover

Every arrow can fail while the search endpoint stays healthy.

Use the best change signal the source offers: a version identifier, a modification timestamp, an ETag, an event, or a content hash. None is sufficient alone. A stable URL can change underneath you. A new timestamp can reflect metadata rather than substance. A deleted record needs a tombstone or an equivalent removal event, or the index never learns it is gone. Expiry should trigger verification, not blind re-embedding.

Index-wide changes get a stricter rule. A new embedding model, new chunking, or a new index architecture never modifies the live index in place. Build a candidate index, validate its counts and its retrieval quality on your own golden queries, then promote it in one atomic step. Rollback is then trivial: do not promote, or point the alias back.

Set TTL by corpus and by consequence. A product catalogue, a signed contract set, and a static technical manual do not share a change rate or a cost of error. A corpus that changes continuously, such as a ticket archive or a knowledge base three teams edit all day, needs event-driven sync and a lag budget rather than a TTL at all. This page cannot supply those numbers. The source owner and the product owner have to write them down.

The freshness contract

For each corpus, record at least these fields:

Field	The decision it forces
Authoritative source	Which system wins when copies disagree?
Source identity and version	How do you know this is the same object and the same state?
Change signal	What tells ingestion to fetch, replace, or delete?
Last successful ingestion	When did the complete path last finish, rather than merely start?
Maximum content age, TTL, or lag budget	When does silent use stop?
Serving response after breach	Warn, omit, retrieve live, refuse, or route to review?
Owner	Who responds when the freshness job misses its window?

The refresh schedule plus its worst-case run time must fit inside the window. A daily job with a two-day failure queue does not keep a one-day promise. And for policy, pricing, and deadlines, a breached window should not produce a disclaimed answer. It should refuse or route to a person.

Deletion and permission changes travel the same path as edits, with one extra demand: completeness. When a source disappears, its chunks, keyword entries, cached previews, citations, and any derived summaries have to disappear or become inaccessible everywhere they were copied. A retrieval system that remembers revoked content is not merely stale. It is an access-control failure with a friendly interface.

Where GRAIN puts freshness

The RAG Engineer defines GRAIN as Gather corpora, Rank and rerank, Assemble context, Inspect failures, Navigate freshness. It is the book’s own operating model, not an industry standard.

Navigate freshness owns the loop: TTL policies, re-ingest jobs, change detection, staleness detection, the user-facing freshness signal, and the record of what changed and when. In this grammar Navigate means freshness. It is not a synonym for choosing the next lookup.

The other letters carry their share. Gather records source identity, permissions, and update ownership in the corpus contract. Rank decides between old and new versions when both slipped into the index. Assemble carries the source version and the indexed-at time into the context. Inspect makes the miss visible in a trace. Navigate closes the loop by moving the current source state into service.

Diagnose the stale answer

Take one wrong answer and compare four states:

1. What did the authoritative source say at query time?
2. What source version did ingestion last observe?
3. What version was present and retrievable in the serving index?
4. What version and passage entered the generation context?

The first mismatch locates the repair. If state 1 never reached state 2, fix change detection. If state 2 reached storage but not state 3, fix indexing or the cutover. If the current version sat in state 3 but lost to an older duplicate, fix ranking and version filters. If it reached state 4 and the answer still contradicted it, the failure is grounding, not freshness.

That separation matters. Re-embedding cannot repair a missing deletion event. A larger context window cannot discover an amendment that was never ingested. A model upgrade cannot make an expired index current.

Freshness is complete when the system can name the source version behind an answer, show when it entered service, and behave deliberately once its allowed age expires. Until then, “current index” is an aspiration with a timestamp.

Cite this:RAG freshness: last month's PDF is not a lookup problem.Len P. van der Hof. https://lenvanderhof.com/en/blog/rag-freshness/ · Published 22 September 2026.