Tracker or Model: The Wearable Fork

Mostafa Dhouib·September 8, 2026·7 min read

Tracker or Model: The Wearable Fork

The short answer. There are two products here. A tracker computes a quantity its sensing directly resolves, so the algorithm is signal processing and the claim is bounded by physics you can measure. An inferential device estimates a quantity the sensing cannot resolve, using a model to bridge the gap, so the claim is bounded by a statistical relationship that holds for some populations and not others. The fork is decided when the sensing approach is chosen, months before there is a dataset, and almost nobody writes down which product they are building.

The fork

Ask one question about the thing you intend to report.

Does the sensing directly resolve the quantity, at the amplitude, bandwidth, and noise floor you have?

Yes: you are building a tracker. The work is acquisition quality and signal processing. The model, if any, is small and its job is rejection: discarding intervals where the signal is unusable. The claim is defensible because the quantity is measured.

No: you are building an inferential device. The quantity is estimated from a correlate, and a model carries that estimate across a gap the physics does not close. This is a legitimate product and a completely different one, with a different evidence burden and a different failure mode.

The trouble is that this fork is usually crossed silently. A program begins as a tracker, discovers the sensing cannot resolve the target, adds a model to bridge the gap, and does not notice it has changed products, evidence requirements, and claim language in the same afternoon.

The decision table

The row that matters most is the failure mode. A tracker that cannot get a reading tells you so. An inferential device that meets someone outside its training distribution returns a number that looks exactly like every other number it produces.

The arithmetic that decides it

Available very early, before parts are chosen, and it is the highest-return hour in the program.

What is the amplitude of the phenomenon at the sensing site, in the units the front end sees?

What is the noise floor of your analog front end, including the electrode or optical interface, not just the amplifier datasheet?

What bandwidth does the feature occupy, and does your sampling and filtering preserve it?

What is the ratio, in the worst realistic condition rather than the bench condition?

If the feature sits below the noise floor in realistic conditions, no downstream processing recovers it. That is not a modelling challenge, it is an information one: the data was never acquired. A model trained anyway will learn whatever correlate is available, which is usually something about the person rather than something about the condition.

Why the inferential path gets chosen accidentally

The demo works. On the team, in the office, on the people who built it. A model that has learned the correlates present in a small, homogeneous group performs beautifully on that group.

The number is subject-inflated. If samples from one person appear on both sides of the train and test split, the score includes how well the system recognises that person. Biosignals carry strong individual signatures: anatomy, placement habits, skin properties, baseline physiology. Split by subject and the number drops for a system that is exactly as good as it was.

The gap is invisible in the metric. Accuracy does not distinguish "measured the thing" from "inferred it from a proxy that happens to correlate in this cohort," and only the second collapses on a new population.

Nobody wrote down which product it is. So the claim language, the evidence plan, and the maintenance model all default to the tracker version while the device is the other thing.

If you are on the inferential path

It is a real product. Build it as one.

Say estimates, not measures, in the claim and in the interface. This single choice governs how a clinician or user treats a reading, and it is the difference between a useful device and a misleading one.

Validate subject-disjoint, and report by slice. Skin tone, body habitus, age, activity state, device unit, placement. The worst slice with real volume is the shipping decision, not the average.

Design the refusal. An inferential device that knows when it is outside its competence is dramatically safer than one that always answers. That requires an input-quality check that is independent of the model, in code, and gets to veto.

Plan for retraining as a regulatory event. Every behaviour you can express as a deterministic rule should live in code rather than in the model, because everything in the model changes when you retrain and retraining a cleared device can require review.

Instrument the front end's own health. Electrode or optical contact quality, saturation events, invalid-interval count. These let a fielded device report degradation rather than report a confident wrong number.

The question for the program

Which product are we building, and is that written down anywhere?

If the answer differs between the engineering team, the clinical team, and the marketing copy, that gap is the risk. It is also cheap to close today and expensive to close near a submission, which is when it is usually discovered.

FAQ

What is the difference between a tracker and an inferential wearable? A tracker computes a quantity its sensing directly resolves, so the claim is bounded by measurable physics. An inferential device estimates a quantity the sensing cannot resolve, using a model to bridge the gap, so the claim is bounded by a statistical relationship that holds for some populations and not others.

When is the fork decided? When the sensing approach is chosen: the electrode or optical interface, placement, bandwidth, noise floor and sampling. That happens months before there is a dataset, and no downstream processing recovers information that was never acquired.

How do I know which one I am building? Do the arithmetic: amplitude of the phenomenon at the sensing site, noise floor of the whole front end, bandwidth the feature occupies, and the ratio in the worst realistic condition rather than the bench condition. If the feature sits below the floor, you are on the inferential path whether or not anyone said so.

Why does an inferential wearable fail invisibly? Because it returns a plausible number for someone outside its training distribution, and that number looks identical to every other number it produces. A tracker that cannot get a reading refuses, which is a visible failure the user can act on.

What should an inferential device do differently? Say estimates rather than measures, validate subject-disjoint and report by slice rather than as one number, build a model-independent input-quality check that can veto an output, keep every expressible rule in deterministic code, and instrument the front end so the device can report degradation instead of a confident wrong answer.