Systems must actively mark context expired rather than carrying it forever

What it is

Context expiry needs an explicit state mark, not an implicit default behaviour. Judgements carry timestamps and validity windows; past the window, the system actively flips their state from "current" to "expired" — a definite event, not "nothing happens while the old value lies there".

Unmarked expiry is the dangerous default: the data stays in place, and every consumer improvises (some carry, some discard, some error) — expiry has no unified expression in the system. Marked expiry makes it a first-class citizen: all consumers face the same explicit signal, so disposal policies can be declared and audited uniformly.

Why it happens

Why must the marking be active, rather than letting each consumer compute it? Because delegating "is this expired" to every consumer guarantees fragmentation:

• Each consumer implements "timestamp compare + threshold" with thresholds copied from wherever (some from the producer's recommendation, some improvised), so the same data has different freshness in different rules — expiry loses its single source of truth.
• The more common outcome is nobody computes it at all: consumers use the value as received, implicitly assuming "what I'm given is fresh". "Carry the last known value forever" is nobody's design decision — it is the default artefact of nobody owning invalidation.
• Explicit marking executes invalidation once, centrally (the data side flips state and publishes an expiry event); consumers only declare "what to do on expiry" — policies may differ, but the recognition of expiry is necessarily uniform. Single recognition plus distributed policy beats distributed recognition plus chaos.

Marking has a second function: visibility of expiry. Once state flips to "expired", the fact enters the observable layer — dashboards show which judgements currently hang in expiry and for how long; a user querying the judgement sees "unknown (last confirmed home three hours ago)" rather than a confidently toned "home". Expiry moves from an internal convention to an honest expression consistent inside and out.

Where it stops holding

• The mark carries no new information. The timestamp was already there; marking only turns the derivable fact "over-age" into explicit state — it saves consumers from duplicated or absent computation, and does not grow the data. Expecting marks to fix "judgement quality" aims at the wrong tool: it exposes bad judgements as "unknown" sooner; it does not make them accurate.
• Expiry needs an exit path. A judgement flipped to "expired" is either refreshed by new sensing (back to current) or explicitly retired (deleted or archived) — without lifecycle management, expired states pile into a permanent haze of "unknown"; marking without lifecycle merely swaps "carrying old values" for "hoarding old values".
• "Unknown" and "conservative default" must be expressed separately. The semantics the mark outputs is "don't know"; what an automation should then do (not run, run a conservative action, ask a human) is the consumer's policy layer — fusing the two (auto-running some default on expiry) loads the marking mechanism with behavioural semantics it should not carry.

Applying it

• Add a state field to the judgement data model (current / expired / unknown) and an expiry event: flip state on timeout and broadcast to subscribers; consumers handle per their declaration, with the most conservative default for the undeclared.
• Make the user-facing judgement view show expiry honestly: "home (confirmed 2 minutes ago)" and "unknown (last confirmed home 3 hours ago)" are two displays that must not blur — the latter may never masquerade as the former.
• Monitor the expired state: track judgements lingering in expiry by type (which sensing class drops out most, which hangs most often); persistently expired judgements indicate a structural gap in the sensing chain — fix the chain, not the mark.
• How to check: a three-layer consistency audit — data layer: do expiry flips happen on schedule (sample timestamps against states); consumer layer: is the mark respected (no execution in trigger logs depending on expired judgements); presentation layer: is expiry distinguished (no confident tone in interface snapshots of expired judgements). All three passing means the marking actually runs through.

Related

• Same group: Z2.09.1 Context judgements expire and must stop being trusted past their validity · Z2.09.2 When the environment changes fast, context spoils faster than judgements refresh · Z2.09.3 Stale-context automation makes outdated decisions
• Nearby: Z4.02.3 Stale state must be explicitly marked · Z2.07.1 The system's current context judgements must be viewable by users
• Search terms: explicit staleness · data expiry · event-driven invalidation · state marking