Unrecognized baseline drift is misread as a state change

What it is

A rise relative to baseline is written as “stress up” or “attention down” only if the baseline is still where it was. If the baseline has walked and the detector does not know, ordinary circadian or hydration wobble becomes a state event. The misread is not a noise spike. It is treating the slope of slow drift as a task-related step.

Why it happens

State detection is usually: mean of the current window minus calibration zero, event if over threshold. If that zero moves by some units per hour, a long enough window integrates across the line even with no phasic response and no event. A high-pass can cut slow drift and will also cut truly slow load build-up. Unrecognized drift shows up as events that still appear by the clock in no-task periods, in phase with a known circadian curve, without the expected phasic waveform. Detecting drift needs a parallel estimator (baseline tracking with a slow time constant) and events only on the fast component. When the two timescales are not split, a product “discovers” stress on time every afternoon.

Studying it

Run the product’s state detector on a long no-task record, mark every alert, and align with an independent circadian or activity log. Factors: drift tracking on or off, high-pass cutoff. Outcomes: alert rate in no-event periods, recall of truly elicited events. Using only short laboratory elicitation as positives will not see the afternoon false states. Adding a known ramp into rest in synthetic data is a clean unit test.

Where it stops holding

Some states are slow by nature (anxiety that warms up); cutting the slow component misses them. That case needs another stream of evidence (self-report, task performance), not only a harsher high-pass. A step baseline from hardware slip, if eaten into the new baseline by slow tracking, will then understate true later events. Drug onset is “legitimate drift” and after recognition should be tagged as a baseline update, not as affect.

Applying it

• A state event must also check that a fast component (phasic or short window) exists; a slow ramp alone is a baseline update, not a state alert.
• Treat alerts in no-task periods as defects, not as “background insight.”
• Show the user the baseline window (this morning / sliding hour) so “relative to what” is visible.
• Verify on an afternoon record with no task and stable environment: if the product still emits strings of state changes, drift is being treated as events.

Related

• Same group: C9.10.1 Resting physiological baselines differ across people; absolute values cannot be compared across users · C9.10.2 After calibration sets an individual baseline, affect, fatigue, and time drift the baseline itself · C9.10.3 Long-term use needs periodic recalibration; a one-shot calibration does not last
• Adjacent: C9.03 Heart Rate and Electrodermal Activity · C9.06 Cost of Sensor False Positives
• Search: drift versus event · tonic-phasic separation · false state change