Indicators must track actual capture, not burn always-on or always-off

What it is

A capture indicator fails at both ends: always-off (never lighting when it should — equivalent to no indicator) and always-on (lit continuously, regardless of capture state). Always-on is the sneakier failure: the device uses a permanently burning light to stage the appearance of having an indicator, but the light carries no correlation with capture — users can read no state change from it, and an always-on light transmits exactly zero information.

"Strictly correlated" means: the light comes on when capture starts, goes off when it stops, edges aligned (latency too small to perceive), and intermediate states (standby-but-not-collecting) do not occupy the "on" signal. Correlation quality is the indicator's information value — this light is a communication channel with a capacity of one bit, and that bit cannot be wasted.

Why it happens

Why always-on is a hidden design failure:

• Correlation drops to zero. An indicator's value equals its correlation with the indicated state. An always-on light has zero correlation with capture and is pure decoration — worse than no light, because it occupies the position of "indicator": users believe a notice channel exists while the channel carries no signal.
• Negative training. Users learn on other devices that "lit = collecting"; on your device "lit = powered". The cross-device generalised expectation is systematically destroyed. An always-on light is not merely useless itself — it corrodes trust in all indicator lights: if this one can burn while not capturing, what about that one? The shared trust in indicator language is a commons, and always-on designs draw it down.
• The attention cost self-destructs. A permanently lit light is a continuous source in the environment — the bedroom-at-night pain point drives users to tape over it. They tape over "constant noise", but the consequence is that a true indicator gets taped over too: by the time this light becomes correlated, the user's eyes already have tape on them. Always-on design ultimately blocks its own repair channel.

The mirror problem — the light lingering long after capture stops — is equally corrosive: it manufactures false impressions of recording, training users to ignore the light ("it's always on, disregard"), drowning the true signal in a sea of false alarms.

Studying it

• Device audits: inventory indicator behaviour across commercial devices — powered-on / capture-correlated / always-on / configurable — and measure correlation latency (capture start to light change); such audits reveal how prevalent always-on design is.
• Semantic comprehension tests: show users different indicator behaviours (always-on, capture-correlated, blinking, breathing) and ask what each means — "what does it say when this light is on?". Cross-device semantic conflicts (same behaviour, different meanings) yield the key error-rate measure.
• Attention and habituation studies: decay curves for correlated versus always-on lights over long cohabitation — how quickly an always-on light disappears from awareness (habituation), and whether correlated lights retain noticeability through their change signal.

One methodological caution: include bystanders with no experience of the device in semantic tests — the guest's reading is the real test of an indicator's public language; the owner's reading has already been calibrated by the manual.

Where it stops holding

• Correlation does not preclude multi-level indication. Breathing = standby, solid = collecting, blinking = fault — tiers can carry more information, but beyond three levels the semantics become unlearnable; and "collecting" must be the most discriminable tier (exclusive brightness or colour).
• Semantic multiplexing is the standard trap. One light expressing pairing mode, network state, low battery, and capture (by colour and blink pattern combinations) — each state definable alone, unreadable together. Capture deserves a dedicated colour or dedicated light, not shared space with low-frequency states.
• Night handling is not indicator shutdown. Address light pollution with adaptive brightness (dim at night, bright by day), not with an "turn off the indicator" option — the latter is a self-silencing switch that contradicts the purpose of capture visibility.

Applying it

• Design an explicit state machine for the indicator: at least one dedicated state (colour/brightness combination) per capture channel, capture edges aligned with light edges within sub-second latency; put the state machine in the spec and cover every edge with test cases.
• Reserve the strongest signal for "collecting": highest brightness or an exclusive colour for the capture state; standby, pairing, and fault stepped down — a glance answers "is it collecting", and finer distinctions require a closer look.
• Forbid "lit whenever powered" as a default: power-on feedback (two blinks at boot) separate from the capture indication; if the device cannot distinguish "online" from "collecting", that is an architectural defect to fix, not a compromise to paper over with a steady light.
• Adaptive night brightness, not an off switch: photocell- or time-based dimming that keeps the state legible while removing the light pollution.
• How to check: start and stop capture at random, measuring the latency and error rate from light change to correct verbal report; then test semantic exclusivity — mix the device among other common devices and ask "which one is collecting"; the misidentification rate measures semantic pollution directly.

Related

• Same group: Z6.08.1 A physical indicator is the notice channel least dependent on network and software · Z6.08.2 Software-level indicators can be bypassed by failure or malware · Z6.08.4 Without a physical indicator, users must assume the device is always collecting
• Nearby: Z1.02 Peripheral and centre attention · Z6.06.3 Notice must match the situation; dense terms do not work
• Search terms: indicator fidelity · state-aware LED · always-on indicator · notification habituation