Context judgements expire and must stop being trusted past their validity
Aliases: stale context · context expiry · validity window
What it is
A context judgement is "a conclusion about a situation at some moment", and its credibility decays with time: "person in the living room" from two minutes ago probably still holds; from two hours ago it approaches a coin flip. The validity window is the timescale over which the judgement decays to unusable — set by the rate of change of what is being judged (activity expires in minutes, presence in hours, routines in weeks).
Past the window, the correct handling is invalidation: demote from "known current state" to "expired history", and stop feeding it to automations and inference. The common anti-pattern treats "last known state" as "current state" — last sensed "home" means home forever, until the next sense overwrites it.
Why it happens
Why must judgements carry expiry? Because a judgement is a sampled snapshot of a dynamic system, and the gap between snapshot and reality grows with the rate difference between the two:
- The faster the object changes, the faster the snapshot spoils — "where is the person" expires quicker than "where is home" not because of data quality but because of what the objects are.
- In sensing gaps, the error grows at the object's rate of change: in two hours the person could be anywhere; the snapshot's information content tends to zero.
- Humans bridge gaps with an inertia assumption ("was home just now, probably still is") — an assumption that holds for slow objects and frequently bankrupts for fast ones. A system that hard-codes the same heuristic without checking its expiry condition has frozen a fallible heuristic into automation.
The operative phrase is "stop being trusted": expiry is demotion, not deletion — the judgement remains historical data (for audit and analysis) while losing the standing of "current". Demotion differs from deletion in being recoverable: the next successful sensing restores the judgement's standing. Managing that standing is exactly what the system must do explicitly; the default, absent such management, is "trusted forever".
Studying it
- A general anchor: in activity recognition and presence detection, the decay curve of judgement quality against sampling interval is a standard measurement — one sensor, reading intervals stretched from seconds to minutes to hours, with inference accuracy tracked; the interval at which the curve falls below the usability threshold is that judgement's measured validity.
- Stream-processing and database research offer ready conceptual tools: freshness and timeliness have formal definitions (timestamp-age based), borrowable to define "context age".
- Evaluation paradigm: inject sensing outages (deliberately pause a sensor, then resume) and observe how the error rate at the moment of resumption grows with outage length — directly pricing the cost of carrying old judgements through unmonitored intervals.
One methodological caution: measure validity across the object's abnormal changes too — decay curves from everyday routine run optimistic (people mostly stay put); holidays, sudden events, and guest arrivals are precisely the low-frequency fast changes where stale judgements cause incidents. Evaluations without such trials overestimate validity systematically.
Where it stops holding
- Validity is not a global constant. The same "at home" judgement has minute-scale validity for the hallway-light automation and month-scale for an insurer's "usual residence" — validity follows the precision the consumer needs, and is not intrinsic to the judgement. Each consuming scenario declares its own tolerable staleness ceiling.
- Well-supported slow judgements extrapolate longer. A judgement cross-confirmed by multiple sources (phone + car + door lock all indicating away) starts with higher confidence and retains more of it after the same interval — validity can float with evidence strength, but the float needs a model behind it, not hand-waving.
- Expiry does not apply to static facts. Floor plan, room count, device inventory — near-invariant objects get super-long cycles; short windows on them only manufacture pointless re-surveys. The expiry mechanism earns its keep on fast variables.
Applying it
- Attach two metadata fields to every class of context judgement — timestamp and validity window; consumers (automation rules, recommendations, security logic) declare their tolerance ceiling and reject judgements beyond it, following a demotion path (don't fire / fall back to conservative defaults).
- Calibrate validity per judgement type from measured decay curves, not one global value; calibration data comes from real households' change-interval distributions.
- Freeze, don't carry, through sensing outages: when a sensor drops out, mark its judgements "no update" and let consumers apply demotion policy — a deliberate break from "hold last state".
- How to check: audit automation-trigger logs for the distribution of "age of the judgement relied upon at fire time" — any sample at or beyond that class's validity fails the audit; then sample the post-hoc error rate of over-age triggers as evidence of what the tolerance costs.
Related
- Same group: Z2.09.2 When the environment changes fast, context spoils faster than judgements refresh · Z2.09.3 Stale-context automation makes outdated decisions · Z2.09.4 Systems must actively mark context expired rather than carrying it forever
- Nearby: Z2.06.2 Static context like location changes slowly; dynamic context like activity changes fast · Z4.02 State desynchronisation
- Search terms:
context staleness·data freshness·sampling interval·presence detection