Following the merge of SEP-2549 (#2549), one small clock-source detail in the freshness section might be worth a clarifying note before the SDKs settle.

The spec defines t_received as "the local time at which the response was received" and checks freshness with now < t_received + ttlMs. It doesn't say whether "local time" means a wall-clock or a monotonic clock. With a wall-clock, an NTP step or a manual time or timezone change between receipt and check can make a still-fresh entry look stale (or a stale one look fresh), whereas a monotonic clock measures elapsed time correctly regardless of system-clock changes.

A one-line note recommending a monotonic clock for the freshness comparison would make this consistent across SDKs. This is doc-level only and orthogonal to the caching.mdx edits in #2890 (which touch the Cache Key section, not Freshness Calculation). Would a short spec note here be welcome, or is the clock choice intentionally left to implementers?

Disclosure: this issue was drafted with AI assistance and reviewed by me before posting.