The measured signal is small, the body it is measured on is moving, and the claims made about the output are ones somebody is held to. The product spans three genuinely different disciplines: analog sensing, real-time signal processing inside a battery power budget, and application software. Almost nobody holds all three, so they are usually contracted separately, and the decisions made at the bottom silently set the ceiling for everything above.
The expensive decisions are made in the hardware, months before anyone can tell whether they were right, and are irreversible by the time evidence arrives. The physics sets a hard ceiling: what the sensing can acquire, given placement, what it senses through, and the sampling, bounds what any downstream stage can recover, and no processing recovers information that was never acquired. Motion is not ordinary noise either, because it correlates with exactly the activity the product cares about. And every processing decision is simultaneously a power decision, so the signal chain cannot be designed as though compute were free and ported down later.
The reflex, and the fix.
Treat it as an application with a sensor attached
Select a sensor module on datasheet specifications, hand the output to an integrator, build the product on top. Faster to start, and how most of these programs begin.
It commits the ceiling before anyone has established where the ceiling is, and distributes the three decisions that matter most across three parties who will each make them correctly and incompatibly.
Establish the physical ceiling, then design against it
A longer architecture phase before anything was built, and the discipline to rule some product claims out at design time.
A product whose limits were known at design time rather than discovered at validation, with the irreversible decisions made once instead of three times and reconciled after the hardware was committed.
Find out what is actually recoverable first, because every claim above depends on it and none of them can exceed it.
Establish the recoverable ceiling before designing anything above it
The first architectural question is not what to build but what is recoverable: what the sensing approach can actually acquire under real wear rather than bench conditions. That answer bounds every claim the product can make, so it is established first and everything above it is designed against it rather than around it.
Treat the signal chain as a first-class layer with an explicit budget
Conditioning, artifact rejection, and extraction are not glue between the hardware and the app. They are where the product is made or lost, and they run inside a power and latency envelope fixed by the form factor. The chain is specified with that envelope as an input rather than discovered against it.
Partition the compute deliberately
What runs on the device and what runs off it is an architectural decision with power, latency, connectivity, and privacy consequences that all point in different directions. Made once, explicitly, with all four visible. Made implicitly, it gets made four times by four people optimizing for one consideration each.
Carry uncertainty across every interface
The application does not only need the value. It needs to know when the value was not trustworthy, because the signal was degraded, the device was poorly seated, or the wearer was doing something the chain cannot see through. An interface carrying only the measurement forces the application to treat every reading as equally good, which is the most common way a technically sound wearable becomes an untrustworthy product.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
Ongoing. Described at architecture and outcome level; no client-identifying detail, no biosignal, no anatomical site, and no sampling rate appears here.
Three internally coherent designs that meet at interfaces nobody owned, with the incompatibility discovered during validation, which is the most expensive place to find it and the point at which the hardware is already committed.
The architectural foundation for the product: the sensing approach and its established bounds, the signal chain and its budget, the compute partition, and the interfaces between the layers including how uncertainty is carried across them. That foundation de-risked the build and continues to drive it forward.
What it owns, and what it hands to a person.
An architecture bounds a product; it does not build one. The physical ceiling is real and does not move, and part of the value of establishing it early is that some things the product might have wanted to claim were ruled out at design time. That is a better outcome than discovering them at validation, and it is still a constraint rather than a solution.
Every significant decision on this program sat on a boundary between two disciplines: the sensing against what the application needs to claim, the signal chain against the power budget, the compute partition against four competing constraints, and the interfaces against how uncertainty propagates. Not one belongs cleanly to a hardware firm, a DSP specialist, or an application team, and each determines the others. The discipline carries to any hardware-to-software product: establish the physical ceiling first, budget the layer in the middle rather than treating it as glue, make the partition deliberately, and specify uncertainty as part of every interface.