Inject the literal date, never "today"¶
Problem¶
A prompt says "set the last-updated field to today's date". The model writes a date. It is frequently wrong, and wrong in a way nothing catches: it is plausible, correctly formatted, and often close.
The model has no clock. Asked for today, it produces a date that looked like "now" in its training data, or infers one from context in the document. Both produce a confident answer with no error.
Technique¶
Resolve the date in code and put the literal value in the prompt.
Not "set last_updated to today's date".
This is small, and the reason to write it down is that it is not obvious in the moment: "today's date" reads like a perfectly clear instruction. It is clear — it is just addressed to something with no way to answer it.
The general form: never ask a model for a fact your program already has. Timestamps, version numbers, the current branch, the caller's identity, a file count. Every one is a chance to be plausibly wrong where the program would be right for free.
When it applies¶
Every generated artifact carrying a date, version, or environment fact — frontmatter, changelogs, release notes, report headers, commit messages.
When it does NOT apply¶
Where the date is genuinely the model's to determine: extracting a date from a document, reasoning about a schedule, or generating an example where any plausible value is fine.
Nor does it help when the program's own value is wrong. Injecting a literal date from a container with a skewed clock produces a confidently wrong date with an extra step.
Evidence¶
A documentation pipeline set last_updated from a prompt instruction. The
dates drifted — never absurd, so no reviewer flagged them, which is why they
persisted. One document's frontmatter said March while its body said the
previous November.
The fix was one f-string. It has not recurred, and staleness checks that compare the stamp against git history became meaningful, because the stamp finally meant something.