Telling the model when things were true

The model does not know what day it is

A model’s weights are frozen at training time. Whatever it believes about dates comes from the training distribution, and it will happily reason about “last year” using a year that is not the current one. Everything time-dependent in your system has to arrive through the context.

The minimum viable version is one line near the top of the instructions:

Today is 2026-09-08. Treat any date after this as a future date.

That single line prevents a family of bugs: relative date arithmetic against the wrong anchor, “the latest version” meaning whatever was latest in training, and a model politely correcting a user’s correct date because it looks implausible from where it is standing.

Inject it, do not hardcode it, and remember the earlier lesson: putting a timestamp near the top of a cached prefix destroys the cache below it. Put the date at the boundary between stable and variable material (after the cached instructions, before the variable content) and you get both.

Every passage carries its date

The second rule follows from the previous lesson. If several retrieved passages can disagree, each needs its date attached to it, immediately.

[7] Refund policy — updated 2026-03-14 — source: help/refunds
Customers may request a refund within 30 days...

Not in a metadata block at the top of the request. Adjacent. A model resolving a conflict between passage 3 and passage 7 has to have both dates within reading distance of both texts, and a header 4,000 tokens earlier is not within reading distance in any practical sense.

Recency as a ranking signal, not a filter

The earlier lesson on filters applies here in its sharpest form. Recency is almost always a preference and almost never a constraint. A hard updated_after filter is how a system becomes unable to answer questions about anything that has not changed recently, and stable documentation is stable precisely because it is correct.

A soft version, applied to the score after retrieval:

age_days = (now - doc.updated_at).days
score = sim * math.exp(-age_days / HALF_LIFE_DAYS)

Choose the half-life from the domain, not from taste. Prices and availability might use 30 days. Engineering documentation might use 700. Legislation might use none at all, because a 1998 statute is not less applicable for being old.

The honest caveat: exponential decay on a similarity score mixes two incomparable quantities, and the result is a heuristic rather than a principled ranking. It works well enough in practice, and you should verify on your evaluation set that it does not push out old documents that were the right answer.

Freshness of the index, not just of the document

Three different clocks, and teams usually track one:

1. Document age: when the content was last changed by its author.
2. Index age: when your pipeline last read it. A document updated an hour ago and indexed nightly is stale in your system regardless of its own timestamp.
3. Cache age: when this particular retrieval result or generated summary was computed. A semantic cache serving yesterday’s answer to today’s question is an index-freshness failure hiding behind a latency optimisation.

Monitor the second: the median and 99th percentile of now - indexed_at across the corpus. It is the number that answers “why does the assistant not know about the change we shipped this morning”, and almost nobody has it on a dashboard until the first time somebody asks.

Live data does not belong in the index

A balance, an order status, an inventory count, today’s price. These change faster than any indexing pipeline and should be fetched at request time through a tool or a direct query, never embedded and retrieved.

The symptom of getting this wrong is distinctive and worth recognising: an assistant that is confidently, specifically wrong about a number, and whose wrongness has a consistent lag. If the answer is always right as of some hours ago, the value is coming from an index that should have been a lookup.

The instruction that helps, and its limit

When conflicting dated passages must both be present, an explicit rule helps:

When sources disagree, prefer the one with the most recent date and say which
you used. If the dates are the same, say that the sources conflict.

It improves the outcome and it does not solve it. Models are unreliable at comparing many dates scattered through a long context, and the failure is silent. Where correctness matters, resolve the conflict in code before assembly (keep the newest per document family) and use the instruction only as a second line of defence.