A bookmark preserves the view, but the data keeps flowing, so its old conclusion may already be stale

What it is

A bookmark preserves the state, but the data flows: open last week's dashboard bookmark today and the data has refreshed — the conclusion captured then ("East has the highest growth") may already be overturned. This inherent property of live-link bookmarks must be managed explicitly — declare the data's time point to the reader, or an old link becomes forged evidence for an expired conclusion.

Why it happens

The root is the ambiguity of link semantics: a link reproduces a query, and a query's result moves with the underlying data. Most scenarios want exactly this liveness (dashboards refresh daily), but in citation and audit scenarios liveness is a defect — citing a conclusion requires freezing the evidence as it stood. Management therefore sorts into three freshness modes: pure live (link plus a timestamp declaring "data as of today"), point-in-time snapshot (the data slice at save time, permanently fixed), and live-with-comparison (current data side by side with the saved slice). The minimal interface move is showing two times on every bookmark — when it was saved and when its data was last updated; once both appear, the reader can immediately judge "is this conclusion fresh?"

Where it stops holding

Freshness declaration must reach data granularity, not page granularity: page-load time is not the data's time point, different sources update on their own schedules, and a rigorous declaration labels each dataset's snapshot time. Snapshot strategy has costs too — freezing everything consumes storage, so what gets frozen is usually the aggregate slice the conclusion needs rather than full detail. Broken bookmarks also need designed handling: when schema changes make a bookmark's query fail, show the explicit reason and a migration path — an error or silent blank is not acceptable.

Applying it

• Show two times on bookmark cards: when saved and the data snapshot point (or a "live data" badge).
• Default important conclusions to point-in-time snapshots; keep live links for monitoring scenarios.
• Verification: open a bookmark from a month ago — can the page directly state "what time is this data from"? If not, the freshness declaration is missing.

Related

• Same group: U6.10.1 Analytical state must be encodable as a reproducible link or snapshot · U6.10.3 Bookmarks must record filters and view configuration, not just page position · U6.10.4 A share-link recipient may see different data due to insufficient permissions · U6.10.5 Bookmarks need human-readable names to be findable again
• Nearby: U10.02.1 The chosen time window decides the trend's direction · U6.10.1 Analytical state must be encodable as a reproducible link or snapshot
• Search terms: bookmark staleness · data freshness · snapshot vs live link