Conversation cache invalidation: freshness is scoped

A model to inspect

A cache entry follows its dependencies

01Bind access scope
02Record source versions
03Invalidate on change
04Reauthorize before reuse

Freshness and permission are separate checks. A cache hit is not proof of current authority.

Original conceptual diagram · not a live trace or measured result.

Cache a result with its permission

A conversation cache is not a bag of helpful sentences. Its key must say whose result it is: tenant or account, authenticated actor or role class, locale if policy differs by locale, query normalization version, source version, and authorization-policy version. Keep the cache scope no broader than the decision it serves. A cached policy excerpt might be safe for an anonymous public help page but unsafe for an employee-only answer.

Treat the cache entry as a derived view with a provenance record. Store the resource identifiers and validators it depended on, the creation time, a freshness deadline, and whether it contained a negative result. Do not use a model-written summary as the only dependency pointer: without source IDs, a document change cannot find the entries that need review.

Choose freshness by consequence

Freshness is a rule for a kind of fact, not a single application-wide duration. A navigation label can tolerate a revision window that a price, access grant, appointment slot, or incident status cannot. Name the owner who can change each fact and the event that makes it stale. If no event feed is trustworthy, use a short revalidation path and disclose uncertainty instead of extending a convenient time-to-live.

RFC 9111 distinguishes stored responses from validation and invalidation behavior. That is useful vocabulary, not a complete conversation architecture. A response being young is not proof that it remains authorized; a response being old is not proof that it is false. Combine freshness with a current authorization check before exposing protected material.

Invalidate dependencies, not a guess

Build a reverse index from a changed policy, document, role, or product record to dependent cache keys. A policy edit can invalidate extracted passages, answer summaries, citation locators, and negative results that said no evidence existed. For high-consequence facts, write the invalidation event and the completion result to an auditable queue. If delivery fails, mark entries for mandatory revalidation rather than leaving them quietly usable.

Hypothetical example: a support role receives a new regional eligibility rule. The system invalidates answers derived from the previous rule version, while preserving unrelated FAQ answers. It does not flush every conversation simply because one document changed. The next request checks the new version and gives a source-based answer or a clear unavailable state.

Negative caches need expiry too

A “no matching document,” “no available slot,” or “not permitted” result can protect a service from repeated expensive work, but it can become wrong quickly. Key a negative cache by the same scope as a positive result and give it an explicit, often conservative expiration. An authorization denial should be invalidated by a grant; an inventory miss should be invalidated by a stock update; a source-missing result should be invalidated when ingestion completes.

Counterexample: caching a denial only by user message makes a later authorized request look denied, while caching it globally can hide a newly published policy from everyone. Never allow a negative cache to become a silent substitute for an access check or source-health signal. The safe response is revalidation when dependency state is uncertain.

Test cache state transitions

Make fixtures for an answer before and after document replacement, grant and revocation, role change, source deletion, failed invalidation delivery, and a negative result that becomes positive. Assert that a post-revocation request cannot retrieve the old excerpt even if a warm entry exists. Assert that an unrelated change does not erase useful safe entries. Measure cache hit behavior separately from answer quality.

Acceptance checks: each entry has scope, dependencies, freshness rule, and invalidation owner; protected entries reauthorize at read time or under a documented equivalent control; negative entries expire or react to change; and unavailable invalidation moves affected content to revalidation. This is distinct from long-term model memory: memory may preserve a user preference under consent, while a cache is a disposable derived response.

Operate a cache review queue

When an invalidation cannot complete, place affected keys in a visible review state rather than deleting the evidence that they existed. The queue should identify dependency, scope, failure reason, and last safe validation without exposing protected answer text to unauthorized reviewers. Revalidate in priority order based on consequence, not cache age alone.

This operational path gives support staff an honest explanation: a result is being refreshed because its source or permission changed. It should never silently serve an old answer merely because the invalidation worker is delayed.

Take it into the review

Cache dependency ledger

Entry scope	Dependencies	Freshness rule	Invalidation trigger	Read-time access check
tenant-7 / policy answer	policy-44 v3; role-2	revalidate after policy edit	policy-44 published	required
tenant-7 / no-slot result	calendar-region-a	expires at declared window	slot-created event	not applicable
public FAQ summary	article-9 v8	validator check	article-9 replaced	public scope
agent draft	case-18 access grant	no reuse after session	grant revoked	required

A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.

Primary reading

Sources and limits

These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.

What the sources establish

RFC 9111: HTTP Caching

RFC 9111 defines HTTP cache invalidation and validation behavior.

Limits: It does not define conversational authorization, source lifecycle, or model memory.

Checked 2026-09-19 · IETF · source publication date not established.

Open original source ↗

W3C Trace Context

Trace Context standardizes propagation of a trace identity between services.

Limits: It does not define cache keys, cache freshness, or authorization policy.

Checked 2026-09-19 · W3C · source publication date not established.

Open original source ↗

Procedures and worked examples are editorial synthesis. Preparation/review dates are not claimed historical publication dates.