After a structural change to the environment, old anchors should be invalidated, not silently kept
Aliases: map invalidation · structural change detection · voided anchors · stale map rejection
What it is
A partition comes down; a navigation arrow still points at a desk behind a wall that is gone. Localization may still lock onto leftover columns in the old map, so content keeps appearing — pinned in the wrong empty air. Anchor invalidation requires that once a structural change is detected or declared, old anchors are voided, not quietly reused on the next “close enough” match.
Invalidation is a binary: does this map still describe the place. It is not a gentle nudge of coordinates back into place.
Why it happens
Feature matching can still succeed locally. Take down a wall, swap a case, move a bench from the east wing to the west, and columns, light troughs, floor texture remain. The locator will match those leftover descriptors, return a high-confidence pose, and lay content out in the old topology. What people see is “the system is sure.” What they have is an old contract on new geometry.
Silent reuse is worse than a display failure. Failure at least sends people to their eyes; a misplacement walks them into a sealed hole, a pulled show, a powered-down machine. Structural-change signal arrives on two paths: geometric consistency (residuals between live depth/features and the map suddenly crossing a threshold, large regions unexplained) and external declaration (a work order, a hang schedule, a human mark “this place has changed”). Algorithm only, no declaration, misses changes that still look like the room but have a new function; declaration only, no algorithm, misses demolitions nobody filed.
Studying it
A reconfiguration experiment: remove or move a large structure (partition, cabinet) in a controllable room, comparing keep-old-anchors, void-on-residual, void-on-human-report. New arrivals follow the old navigation on a task.
Change types: local furniture, a full partition, function swap (same geometry, new use). Records: wrong-guidance counts, walks into a hazardous empty zone, whether the void cue appears on the first step, false-void rate (room unchanged, judged invalid).
Nudging a chair to stand in for “structural change” will mix this with slow drift. The change has to alter topology.
Where it stops holding
Day/night light, crowds, and a temporary pallet are not structural change; treating them as voids will wipe a venue every day — those go to rematching. Lifetime expiry can hide content without detecting a demolished wall; the calendar will not tell you it fell yesterday. Remote collaborators cannot see the site and must not void on behalf of the people there. Mirrored or highly symmetric renovations (the new wall looks like the old wall) fool appearance-based detection; declaration has to stack on top. Safety-critical sites should rather false-void and re-pin than misplace onto a sealed corridor.
Applying it
- Add a “possibly invalid” state: enter it when geometric residual crosses threshold or a reconfiguration is declared. Stop navigation and operation until a rescan or a human confirm.
- Give on-site staff a one-tap “this place has changed.” Do not wait for the algorithm. A declaration should void every old anchor in the region, not delete one row.
- Keep an audit after a void: which map, when, residual or declaration, so false voids and misses can be repaired separately.
- How to check: take down a partition on the task path, leave the map untouched, and send a new user along the old arrows. The system should refuse to guide before departure or on the first step. If they are led to the empty place the partition used to occupy and still see “you have arrived,” that is silent reuse.
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.3 Anchor lifetime needs an explicit policy, not a permanent-environment assumption · N5.09.4 Merging several local frames into a shared frame is the premise of multi-user persistence
- Nearby:N5.04 Spatial Anchors · N5.05 Shared Space
- Search terms:
anchor invalidation·map invalidation·environment change detection
Cards in the same group
- N5.09.1Cloud anchors let different devices at different times see the same content at the same place
- N5.09.2Persistent content must be periodically re-matched to the environment to stop long-term drift
- N5.09.3Anchor lifetime needs an explicit policy, not a permanent-environment assumption
- N5.09.4Merging several local frames into a shared frame is the premise of multi-user persistence