Your AI database answer may be correct—and already stale

A database query can be correct when it runs and wrong for the decision five minutes later.

The customer changed status. A role was revoked. The reporting cutoff moved.

Then an AI assistant returns the cached result without saying that its data or policy context has expired.

For AI database tools, caching is a contract:

• define a freshness class per approved operation
• include tenant, environment, role or policy hash, normalized parameters, schema version, and operation version in the key
• recheck authorization before serving a cached payload
• invalidate on data, semantic-definition, and entitlement changes
• return cache age and source freshness with the result

The model should not decide whether a question is safe to cache.

A catalog summary may tolerate an hour. An incident queue may tolerate seconds. A balance, entitlement, or approval check may need a live query.

Time-to-live is also not enough by itself. It creates a known stale window. Event-driven invalidation, entity versions, policy versions, and a hard expiry give the workflow clearer bounds.

Most importantly, test scope failure:

1. run identical parameters for two tenants
2. create a cache entry, then revoke the user’s role
3. change a business definition without changing the table schema
4. retry while an invalidation event is delayed

And return evidence such as generated_at, source_fresh_through, cache age, maximum age, operation version, policy version, and trace ID.

That lets the final answer say “current through 01:05 UTC” instead of quietly presenting cached data as live.

Full guide: ChatGPT database connector caching: define freshness, scope, and invalidation