Cache key exact match may restore stale data despite dependency changes

Cache key exact match may restore stale data despite dependency changes

Goal: Understand whether CircleCI provides any built‑in safeguard that prevents the reuse of a cache when the restore_key matches exactly but the underlying dependencies have changed in ways not captured by the checksum (e.g., submodule updates or generated files).

Constraints: The cache key cannot be altered to include those untracked files without changing the workflow, and the 15‑day inactive‑deletion policy is fixed and not configurable.

Uncertainty: It is unclear if CircleCI evaluates cache freshness beyond the key match, or offers a TTL or validation step that would bypass an outdated cache.

Does CircleCI evaluate any metadata (such as creation timestamp) when deciding to restore a cache?
Is there a way to set a maximum age or TTL for cached artifacts?
If no such mechanism exists, what are the recommended patterns to detect or avoid stale cache usage without modifying the cache key?