Reusing one sensor across functions may require different false-positive tolerances

What it is

One optical heart-rate sensor can feed “auto-detect a workout,” “stress nudge,” and “unusual heart-rate flag” at once. The three functions do not share a false-positive tolerance: an extra workout badge is small; an extra health scare is not. Reusing hardware is not reusing an operating point. Each function needs its own cut and suppression.

Why it happens

The sensor emits one score stream; each function attaches a different loss matrix. Sharing one threshold forces every downstream to accept the same error orientation. Worse, functions contaminate each other: lowering a global gate to make fall detection more sensitive makes stress notifications louder, and the user kills the whole sensor, taking all three functions with it. Reuse also blurs accountability: someone tuning a threshold thinks they are fixing activity detection and has changed a medically flavored hint. The right structure is shared scores, separated decisions—calibration may be shared; firing must not.

Studying it

On one hardware log, sweep thresholds per function and draw each interruption–miss curve; see where a global optimum sits on each. Factors: the function set, whether per-function thresholds are allowed. Outcomes: per-function loss, and survival of other functions after one of them is turned off. Interviews should ask whether people disabled “notifications” or “the watch’s health.” Hardware-level accuracy alone hides the cross-function clash.

Where it stops holding

Under extreme compute or battery limits there may be only one detector; per-function thresholds then become different cooldowns or different copy after the fact, not different classifiers. If a regulated function must coexist with an entertainment one, the regulated path should not be overridable by consumer settings. If two functions’ labels are in fact the same event (“heart rate too high”), splitting thresholds produces two stories for one event; unify the event definition first.

Applying it

• Give each product function its own trigger config; forbid reading and writing one global constant.
• Turning a function off should stop only its decision, not sensor sampling—unless the user explicitly asks to stop sampling.
• In release review, list which functions a threshold change will move, and take cross-function sign-off.
• Verify by making only workout detection more sensitive and checking whether health-scare notifications rise with it; if they do, the operating point is still being reused.

Related

• Same group: C9.06.1 False-positive and false-negative costs are asymmetric · C9.06.2 Threshold choice is a product decision, not an algorithm decision · C9.06.3 High-consequence actions must not be decided by a single sensor · C9.06.4 Medical alarms usually prefer false positives over false negatives; consumer settings often reverse that · C9.06.5 Cost asymmetry should appear as a concrete classification threshold, not only as a stated principle · C9.06.7 Evaluating false-positive cost must include long-term trust loss, not only the harm of a single error
• Adjacent: C9.08 Sensor Fusion · C9.03 Heart Rate and Electrodermal Activity
• Search: per-function threshold · sensor reuse · false-positive tolerance