Anchor lifetime needs an explicit policy, not a permanent-environment assumption

What it is

A gallery label is “pinned here forever.” Three months after the show comes down, a card describing a removed work still floats over empty floor. Anchor lifetime is an explicit survival policy: session, day, this run of the show, until someone revokes — not a default that the room never changes and the content should always appear.

Lifetime is a product decision, not a localization-accuracy problem. The solver can still match that floor. Whether the card should still show is a separate gate.

Why it happens

Persistence systems are good at remembering and poor at forgetting. Once a map and an anchor are written to the cloud or the device, a successful localize brings the content back. With no expiry field, the only stop is someone remembering to delete. They will not: the installer leaves, the next event reuses the app, and the old anchor is treated as valid the moment localization succeeds.

Time expires even when geometry does not. A meeting slot ends, a temporary hoarding comes down, a promotion rolls to next week: the semantics die first, the coordinates stay alive. Equating “can localize” with “should display” keeps performing a spatial contract that is already void. Policy has to write a life cycle onto the anchor: creator, expected takedown, behaviour on timeout (hide, demote to confirm, delete).

Studying it

Run expiry scripts in the field: the same anchor tagged “two hours,” “today,” “this week,” “no expiry.” Before and after the deadline, new arrivals report what they see and whether they treat it as still in force.

Policy factors: expiry grain, hide versus “may be stale” after expiry, whether the creator must confirm a renewal. Observations: fraction still treated as current after expiry, time until users judge it stale themselves, actions taken on expired content (walking to a removed work, waiting for a meeting that has ended).

“How long should it stay” on a questionnaire is not the same as the misbelief rate. Watch the action.

Where it stops holding

Building-scale fixtures (a hydrant label, a permanent hang) can live in years, but someone still has to renew; do not encode “infinite.” Clinical and construction anchors are often bounded by a shift or a work order; a gallery “this season” will leave a dismantled pipe note on site. A wrong device clock or unset timezone fires expiry early or late; a clear policy then executes at the wrong moment. Invalidation on a structural jump is event-driven, not calendrical; both must exist, and neither replaces the other.

Applying it

• Require a lifetime at creation, default short (today, or this event). Permanent must be an explicit choice with a named owner.
• Hide on expiry by default; do not leave a translucent pin. Review belongs in an “expired” list, not in the room.
• Notify the owner before expiry; no renewal means takedown. Do not treat silence as consent to stay forever.
• How to check: plant a two-hour meeting mark, then send someone else in after it dies. They should not see it. If the newcomer still waits for a meeting that has broken up, lifetime was never separated from a successful localize.

Related

• Same group：N5.09.1 Cloud anchors let different devices at different times see the same content at the same place · N5.09.2 Persistent content must be periodically re-matched to the environment to stop long-term drift · N5.09.4 Merging several local frames into a shared frame is the premise of multi-user persistence · N5.09.5 After a structural change to the environment, old anchors should be invalidated, not silently kept
• Nearby：N5.04 Spatial Anchors · N5.05 Shared Space
• Search terms：anchor lifetime · persistence policy · spatial content TTL