Active-Map Status Indicator¶
Status indicator — instantiates Context-Keyed Representation Switching
Makes the currently-active representation continuously visible — which map is live, and which version of it — so no one acts on a silent or stale switch.
A switch that happens invisibly is a trap: the moment the active representation changes without anyone noticing, people keep operating on the map they think is live. Active-Map Status Indicator is the always-on, read-only display that answers one question at a glance — which representation is active right now, and which version of it — and that flags the instant it changes. Its defining property is that it is a witness, not a chooser: it never selects the map, it reflects the ground truth of what is actually active (not what was requested), and its whole value is making an implicit switch impossible to miss.
Example¶
A glass-cockpit airliner has a Flight Mode Annunciator (FMA) — a strip along the top of the primary flight display showing exactly which lateral, vertical, and autothrottle modes are armed versus engaged. When the autopilot captures a new vertical mode, the FMA changes and briefly boxes the new mode so the crew's eyes are drawn to the transition. The reason this matters is mode confusion: acting as though the aircraft is in one mode when it is actually in another is a well-documented class of automation error. The FMA does not fly the plane or choose the mode; it exists solely so the active map is never a mystery. An Active-Map Status Indicator is that idea generalized to any context-switched system: a persistent, salient readout of the live representation and its version.
How it works¶
Its distinguishing constraints are that it is read-only, always-on, and bound to actual state. It reports what is genuinely active — not what was commanded, requested, or last configured — because the whole point is to catch the case where those diverge. It surfaces transitions with extra salience (the dangerous moment is the switch itself), and it shows enough provenance that "map v3" is never mistaken for "map v2." It deliberately does no selection, no validation, and no correction; adding those would make it a different mechanism and dilute the one job it must do perfectly.
Tuning parameters¶
- Salience — how loudly it signals, especially on change. Louder reliably catches silent switches but risks alarm fatigue that trains people to ignore it.
- Latency — how quickly it reflects a switch. Any lag is dangerous, because during the lag people act on the old map believing the indicator is current.
- Granularity — just the active map, or map plus version plus why-selected. More context builds trust and aids diagnosis but clutters the display.
- Ground-truth binding — whether it reads commanded or actual active state. It must read actual; an indicator wired to the command is confidently wrong exactly when it matters.
When it helps, and when it misleads¶
It helps anywhere an implicit or automatic switch can lead someone to act on the wrong representation — the more the switching is automated and invisible, the more it is needed.
Its cruel failure mode is that a stale or lying indicator is worse than none: because operators come to rely on it, an indicator that lags or reflects commanded-rather-than-actual state induces exactly the wrong-map action it was meant to prevent, now with false confidence (a form of automation complacency). The classic misuse is the decorative indicator — present but so unsalient no one reads it, or never tested against ground truth. The discipline is to bind it to actual state, test that it tracks real switches, and design for the change-moment rather than the steady state.[1]
How it implements the components¶
active_representation_indicator— it is the indicator: the continuous, salient signal of which representation is currently active.version_and_provenance_trace— it surfaces the version and lineage of the active map, so a switch between versions is as visible as a switch between maps.
It does NOT choose the map — that selection is Context-to-Map Routing Table's and Gated Expert Router's — and it does not own the full version history, which lives in Versioned Map Registry; it only displays the current entry.
Related¶
- Instantiates: Context-Keyed Representation Switching — it makes the "which map is active" invariant observable, which every other switching control depends on.
- Consumes: Versioned Map Registry for version and provenance data.
- Sibling mechanisms: Context-to-Map Routing Table · Versioned Map Registry · Finite-State Map Selector · Context Reinstatement Protocol · Safe Default-Map Fallback
Notes¶
It reports; it never decides. An indicator is only as truthful as its binding — one wired to commanded rather than actual active state will read correct precisely until the moment a switch fails, then lie at the worst possible time. Pairing it with the selector is essential: the indicator and the thing it watches must read the same underlying state.
References¶
[1] Mode confusion / mode awareness — the human-factors term for operating a system as if it were in a different mode than it actually is. Salient active-state indication is the standard mitigation, which is why the change-moment, not the steady state, is what an indicator must be designed around. ↩