"How old is this?" is the question builders hear as distrust and serious users mean as hygiene. They ask it because too many AI products collapse different kinds of drift into one polished sentence: stale facts, stale deploys, stale search indexes, stale auth, stale local assumptions. The answer can be articulate and still be expired.
Serious users ask how old the answer is because freshness is part of truth. Dependable tools do not just emit an answer. They expose the source date, the live revision, and the refresh path that tells the operator whether the claim is still safe to trust.
The rude follow-up is usually the right one
A demo wants applause for being correct once. A workflow needs to survive being correct at the wrong time. That is why the awkward follow-up keeps showing up after the polished moment: "When was this checked?" "Is that the live route or the local build?" "Did you verify the current page or the cached one?" "Are you answering from memory or from a current source?"
Socially, that question feels expensive because it punctures momentum. It makes the builder admit the answer might be right in substance and still wrong for the job. But that is exactly the point. In operations, finance, medicine, deployments, search, and agent workflows, age is not metadata stapled on later. Age changes the meaning of the answer.
The fact changed after the answer was learned.
Markets move, docs update, policies change, and "latest" quietly becomes a historical answer.
The public surface is serving yesterday's object.
The deploy may be real while the route the user sees is still stale at the edge.
The authority expired even if the explanation did not.
A confident answer about a live action path means little if the token, profile, or session has already aged out.
The surrounding receipts no longer agree.
Search index, blog archive, route HTML, and public revision can silently disagree unless freshness is checked on the whole path.
The infrastructure world already has a vocabulary for this
The web stack is surprisingly blunt about freshness. RFC 9111 defines the difference between a fresh response and a stale one. That is not a philosophical distinction. It is an operational one: can this object be reused as-is, or does it need validation before someone trusts it again?
AWS says the quiet part even more directly in the current CloudFront caching docs: edge caches can keep serving stale content under `stale-while-revalidate`, and in the object update guidance AWS recommends version identifiers when content changes. In other words: the platform already assumes age matters. AI products get into trouble when their interface pretends that it does not.
Even current model tooling admits the same thing. OpenAI's official web search guide exists because some questions are time-shaped. The issue is not that the model cannot compose a sentence. The issue is that a sentence alone cannot prove current truth when the world has moved.
Local-first does not remove the clock
This matters in Chopshopr's world because local-first agents tempt builders into a new category error. Privacy and locality reduce one class of dependence. They do not erase time. A local model can still be reasoning over stale docs. A local MCP stack can still point at an expired profile. A local build can still be newer than the public route. A local search result can still route someone to yesterday's "latest article" unless the archive, search index, and runtime all move together.
That is why the builder quickstart is only half the work. The harder half is proving freshness after the setup: not just which local stack to start, but when the answer was checked, which route is live, and how the next operator can refresh the proof without guessing.
The freshness receipt serious users are actually asking for
Chopshopr's rule is getting simpler
A public claim is not fresh because the local tree is green. It is only fresh enough to trust when the route, archive, search index, and live domain agree on the same answer. The repo's worktree-first build and autoship contract already points the right way: verify the branch, ship the branch, then prove the public surface instead of treating local success as the final story.
The older checklist note and proof-surface note both arrive at the same conclusion from different angles: if the user still needs a side channel to answer age, revision, or live-route questions, the product has not absorbed enough of the work. A good AI surface should volunteer freshness before the operator has to ask for it.
The rule I want to keep
If the answer can drift, the age belongs in the product. Not hidden in internal logs, not implied by confidence, and not deferred until a skeptical user asks. Put the date on the fact. Put the revision on the route. Put the refresh path beside the claim.
That is why serious users keep asking the rude question. They are not sabotaging the AI moment. They are trying to recover the missing part of truth. The more expensive the workflow becomes, the less "correct once" is enough. Fresh enough to trust is the real bar.
Source list
- RFC 9111: HTTP Caching
- AWS CloudFront docs: manage how long content stays in the cache
- AWS CloudFront docs: use file versioning to update existing objects
- OpenAI docs: web search tool
- Chopshopr README: worktree-first build and autoship
- Builder quickstart without guesswork.
- Why is the old checklist still alive after the AI shipped?
- If your agent is so smart, why does the work still end in grep, curl, and a screenshot?