"I counted the user's steps flawlessly and diagnosed their stress from a bumpy bus ride. One of those was worth shipping."
An Over-Eager AI Agent
Prerequisites
This section is a playbook, not a first pass. It assumes the inertial signal foundations from Chapter 23, the human-activity-recognition machinery of Chapter 26, and the cardiovascular biosignal chain (PPG, heart-rate variability) built in Chapter 30. Sampling, windowing, and synchronization come from Chapter 3. We do not re-derive a step counter or an HRV feature here; we decide how to assemble them into four products that share one wrist, one battery, and one consent form.
The Big Picture
A wearable is the hardest deployment target in this book disguised as the friendliest. It is always on the body, always running, always low on power, and always in motion, and the person wearing it did not sign up to be a data-collection subject. The same accelerometer and photoplethysmography (PPG) sensor must simultaneously serve four very different products: a fitness tracker that tolerates error, a fall detector where a single miss is a lawsuit, a sleep stager that runs eight silent hours, and a stress estimator whose ground truth barely exists. This section is the playbook: it shows why these four tasks demand different base rates, labels, evaluation splits, and power budgets from one shared sensing stack, and where each one quietly breaks.
The wearable design envelope
Four constraints define this domain and none of them are about model accuracy. First, power: a wrist device carries roughly \(0.3\) watt-hours of usable battery and must last a day or more, so the compute and the radio, not the algorithm's F1, set what is shippable. A continuous deep model on the main processor drains the battery in hours; the winning designs keep a low-power always-on sensor hub awake and wake the big processor rarely. Second, motion artifact: the wrist is the noisiest place on the body for optical heart-rate sensing, because every arm swing modulates the blood volume the PPG measures. Third, placement and fit variance: the same watch sits differently on every wrist and every band tension, so a model trained on tight-strap lab data meets loose-strap reality as distribution shift (the subject of Chapter 66). Fourth, consent and privacy: continuous biosignals are among the most sensitive data a person emits, and the clinical-grade obligations for handling them are set out in Chapter 34. A wearable design that optimizes accuracy without pricing these four into the loss function ships a demo, not a product.
Key Insight
The four flagship wearable tasks are not four difficulties of one problem; they are four different problems that happen to share a sensor. Fitness is high base rate, cheap errors, self-evident labels. Fall detection is vanishingly low base rate, catastrophic misses, and almost no real positives to train on. Sleep staging is long-horizon and label-starved (the reference polysomnogram is expensive and scarce). Stress has no agreed physical definition at all. A single architecture tuned for one of them will be miscalibrated for the other three. The playbook is to pick the base rate, the cost asymmetry, and the evaluation split per task before choosing a model.
Four tasks, four shapes
Fitness and activity (step count, workout type, energy expenditure) is the forgiving quadrant. Positives are frequent, a five-percent step-count error is invisible to the user, and labels come almost free from the activity itself. Here the classical HAR pipeline of Chapter 26, windowed accelerometer features into a small classifier, is genuinely sufficient, and the engineering effort belongs in duty-cycling, not in a larger network.
Fall detection is the opposite. A community-dwelling older adult falls on the order of once per several months, while the device evaluates a candidate window every second, so the negative-to-positive ratio is astronomical and, worse, you cannot collect real falls at scale: training data is dominated by actors dropping onto crash mats, which do not match real syncopal falls. The consequence is a brutal precision problem identical in shape to the base-rate trap of Chapter 65: a detector with a tiny false-positive rate still cries wolf many times per real fall. The standard answer is a two-stage cascade (a cheap impact-and-freefall trigger gating an expensive confirmation model) plus a human-in-the-loop delay: the watch counts down and asks "are you OK?" before it dials emergency services, buying precision from the user instead of the classifier.
Sleep staging is a long-horizon sequence problem. Consumer wearables estimate wake, light, deep, and REM from actigraphy plus PPG-derived HRV and respiration, against a polysomnography reference that is expensive, scarce, and itself imperfectly agreed between human scorers. The signal is strongly temporal (stages evolve in structured cycles), which is why recurrent and attention models over the whole night outperform per-epoch classifiers. Labels are the bottleneck, so this task leans hardest on the self-supervised pretraining of Chapter 17.
Stress is the quadrant to approach with humility. There is no ground-truth stress sensor; proxies such as electrodermal activity and reduced HRV correlate with sympathetic arousal, but arousal from a workout, a hot room, or a caffeinated afternoon is physiologically hard to separate from psychological stress. Reported labels are self-reports collected sparsely by prompts. A credible stress estimator therefore ships with wide, honest uncertainty (the conformal machinery of Chapter 18) and abstains rather than asserting a stress score during exercise.
Step-Through: a wrist fall detector that woke the whole retirement community
A vendor deploys a fall-detection watch across an assisted-living facility. In the lab the impact-plus-orientation model reports sensitivity \(0.95\) and specificity \(0.99\). With residents wearing it every waking hour, the arithmetic bites: at one genuine fall per resident per two months and a window every second, the \(1\%\) false-positive rate produces dozens of false alerts per resident per day, and the night nurses stop trusting the pendant within a week. The fix was not a bigger model. The team added a freefall-then-impact gate that only wakes the classifier on a plausible signature (cutting evaluated windows by three orders of magnitude), then a fifteen-second on-device countdown the resident can cancel, and only escalated to staff on an uncancelled high-confidence event. Sensitivity dropped to \(0.90\), but false alerts fell from dozens per day to a handful per month, and the system became trusted enough to actually save the falls it caught. The lesson: the shippable operating point came from the cascade and the human delay, not from the accuracy number.
The evaluation trap: subject and device leakage
Every wearable metric you will ever read is at risk of one specific lie: subject leakage. If windows from the same person appear in both training and test folds (the trivial outcome of a random split over windows), the model can memorize that individual's idiosyncratic gait, resting heart rate, and wrist anatomy, and the reported accuracy reflects re-identification, not generalization to a new user. The only honest protocol is a subject-wise (leave-subjects-out) split, reinforced by the leakage-safe dataset discipline of Chapter 5. Device and firmware are the second leak: a model validated on one watch generation can collapse on the next optical stack, so a serious evaluation also holds out devices. The gap between a random split and a subject-wise split on the same wearable dataset is routinely ten to twenty accuracy points, and that gap is exactly the number a field deployment will surrender.
import numpy as np
def cascade_report(subjects, impact_score, confirm_score, is_fall,
trigger_tau, confirm_tau, hz=25, wear_hours=15):
"""Two-stage fall cascade under a SUBJECT-WISE holdout.
Stage 1 (cheap) gates stage 2 (expensive); report wake rate + precision."""
subj = np.unique(subjects)
rng = np.random.default_rng(0)
test = set(rng.choice(subj, size=max(1, len(subj)//5), replace=False))
m = np.array([s in test for s in subjects]) # leave-subjects-out
woke = impact_score[m] >= trigger_tau # stage-1 gate fires
alarm = woke & (confirm_score[m] >= confirm_tau) # stage-2 confirms
y = is_fall[m].astype(bool)
windows_per_day = hz * 3600 * wear_hours
duty = woke.mean() # fraction waking big model
tp = np.sum(alarm & y); fp = np.sum(alarm & ~y); fn = np.sum(~alarm & y)
return dict(test_subjects=len(test),
wakeups_per_day=round(duty * windows_per_day, 1),
recall=round(tp / max(tp + fn, 1), 3),
precision=round(tp / max(tp + fp, 1), 3),
false_alarms_per_day=round(fp / max(len(test), 1), 2))
n, S = 200_000, 40
subjects = np.repeat(np.arange(S), n // S)
is_fall = (np.random.default_rng(1).random(n) < 5e-4).astype(int) # rare
rng = np.random.default_rng(2)
impact_score = np.clip(rng.normal(is_fall * 2.5, 1.0), -5, 8) # cheap trigger
confirm_score = np.clip(rng.normal(is_fall * 3.0, 1.0), -5, 8) # heavy model
print(cascade_report(subjects, impact_score, confirm_score, is_fall,
trigger_tau=3.0, confirm_tau=2.0))
wakeups_per_day is the battery-relevant quantity; stage two only runs when stage one fires. The returned false_alarms_per_day is the operational number the retirement-community example lived or died by.Code 71.1.1 makes both playbook moves mechanical at once: it splits by subject so the metrics are honest, and it reports the stage-one wake rate (which governs battery) alongside precision and false alarms per day (which govern trust). Swapping in a real detector's scores turns it directly into a deployment go/no-go table.
Right Tool: subject-wise splits and HAR windows for free
Hand-rolling grouped cross-validation, sliding windows, and per-subject aggregation is easy to get subtly wrong (an off-by-one in the window stride silently leaks). scikit-learn's GroupKFold and LeaveOneGroupOut guarantee no subject crosses folds in one call, and time-series toolkits such as tsai and aeon provide windowing and channel-wise transforms for wearable arrays out of the box. That replaces roughly 40 lines of manual index bookkeeping with about 4, and removes the most common source of an inflated wearable benchmark.
Shipping it: edge budget, cascades, and personalization
The deployment pattern that recurs across all four tasks is the tiered cascade, and it is a direct application of the edge-AI discipline of Chapter 59 and the TinyML sensor-hub work of Chapter 61. A tiny always-on model on the microcontroller-class sensor hub screens the raw stream; only interesting windows wake the main processor or the phone for the heavy model. This is what makes continuous sensing fit inside \(0.3\) watt-hours. The second deployment lever is personalization: because wearables are single-user devices, a brief on-device calibration to the wearer's resting heart rate and gait closes much of the subject-wise generalization gap, and doing it locally keeps the raw biosignals off the server, aligning with the federated and privacy-preserving approach of Chapter 64.
Research Frontier
The current frontier is the wearable foundation model: a single encoder pretrained self-supervised on massive unlabelled accelerometer and PPG streams, then adapted to fitness, sleep, and health tasks with little labelled data. Google's Large Sensor Model line (trained on hundreds of thousands of person-days of wrist data) and Apple's wearable-signal representations point the same direction, and the general recipe is developed in Chapter 20. The open problems are exactly this section's four constraints: making these encoders small enough for the sensor hub, calibrated enough to abstain on ambiguous stress windows, and private enough to train without exfiltrating raw biosignals.
Exercise
Take the cascade in Code 71.1.1. (a) Sweep trigger_tau and plot wakeups_per_day against recall; identify the knee where lowering the trigger threshold stops improving recall but keeps draining the battery. (b) Replace the subject-wise split with a naive random split over windows and re-run; report how much the precision inflates and explain the source in one sentence. (c) Add a fifteen-second user-cancel step to the model: assume the wearer cancels 80% of false alarms and 2% of true falls, and recompute the effective false-alarms-per-day and recall. Which single change bought the most trust per unit of lost recall?
Self-Check
- Fitness, fall detection, sleep, and stress share one accelerometer. For each, name the property (base rate, label cost, or definition) that most constrains its design, and say why a single model tuned for step counting would fail it.
- Why does a random train/test split over windows inflate wearable accuracy, and what is the one-line fix that makes the number honest?
- A stress estimator flags high stress during the user's morning run. Give the physiological reason this is likely a false positive and the design response (from this section) that prevents shipping it.
What's Next
In Section 71.2, we move the sensing off the body and onto a machine that must act on what it perceives. Robotics inherits the same power and real-time constraints but adds a closed control loop, the sim-to-real gap, and the need to recover gracefully when perception fails, turning the passive monitoring of this section into active, embodied perception.