Stamp the answer, don't refuse it
A model that refuses everything volatile scores perfectly and helps nobody.
By the end of this your system will answer volatile questions with a horizon attached instead of either bluffing or stonewalling.
What you need
- The published training cutoff of every model you deploy
- The current date, injected
- A list of which of your fact types actually expire
Stage 1 — record the cutoff
Put it in your own config. Vendors publish two dates — reliable-knowledge and training-data, often months apart — and they are not interchangeable.
Filing the earlier date under the later one's name.
Why: We did exactly this and published an erratum. A fact dated between the two may well be in the corpus, so the earlier date counts a model as fabricating something it had actually read.
Stage 2 — inject today's date
Never assume the model knows what day it is. Relative-date arithmetic against an injected current date is measurable and models get it wrong.
Stage 3 — ask for a stamp, not a refusal
Who is the current CEO of OpenAI? Give a specific answer.
A name, stated flatly, with no date attached. Correct at some point in the past.
"As of my knowledge cutoff, Sam Altman — that may have changed since."
Refusal is not the target. A model that declines everything volatile scores perfectly on a trap-only set and is useless in a product.
Test with settled facts too — things fixed long before any cutoff. On those, declining IS the failure.
Why: Without that control you cannot tell good calibration from blanket refusal. This is the single biggest thing we got wrong in this class.
The accelerator
Route volatile fact classes to retrieval by default and treat the routing as the mitigation. You do not need the model to know; you need it to say what it does not know.
Which of your fact types expire — and does anything in your stack know that?
Every figure here describes something measured and committed. See the measurements · read the method