The signal is small, the body it is measured on is moving, and someone is held to the claims made about the output. Three different disciplines sit inside the product: analog sensing, real-time signal processing on a battery budget, and application software. Few people hold all three, so they are usually contracted separately, and the decisions made at the bottom quietly set the ceiling for everything above them.
No amount of processing recovers what the sensor never acquired.
A biometric wearable measures something faint happening inside a body that is moving, warm, sweating and shifting against the device. The physiological signal is a small variation riding on top of much larger things: the wearer's own movement, changes in how firmly the sensor sits, interference from the electronics around it. The first job of the hardware is to capture that small variation faithfully enough that it can later be separated from everything else.
Capture happens in a chain. The sensor converts a physical quantity into an electrical one. An analog front end amplifies and filters it, and an analog-to-digital converter samples it at fixed intervals with a fixed resolution. From that point on the signal is a stream of numbers, and every later stage works only with those numbers. If the source was too faint against the noise, the sensor was coupled poorly to what it measures, or the sampling was too coarse to follow the signal's changes, the information is simply absent. Filtering can reduce noise it can characterise. It cannot reconstruct detail that never reached the converter. This is the physical ceiling, and it is set before a line of firmware is written.
Above the ceiling sits a choice about where the computing happens. Processing on the device costs battery with every operation, but it sends less over the radio and keeps working without a phone nearby. Sending raw data off the device saves local compute, but the radio is often one of the hungriest parts of a wearable, and raw physiological data leaving the device raises privacy questions of its own. Latency pulls in yet another direction. Each of these is a separate budget, and the split between on-device and off-device work is the one decision that has to balance all of them at once.
The expensive decisions are made in hardware, months before anyone can tell whether they were right, and they cannot be undone by the time the evidence arrives. Physics sets a hard limit. What the sensing can acquire, given where it sits, what it senses through and how it samples, bounds everything downstream, and no processing recovers information that was never captured. Motion is no ordinary noise either, because it rises and falls with exactly the activity the product cares about. And every processing decision is also a power decision, so the signal chain cannot be designed as if compute were free and squeezed onto the device later.
Wearables fail where one discipline hands over to another.
A biometric wearable spans three disciplines that rarely sit in one head: analog sensing, real-time signal processing on a battery budget, and application software. Each is usually contracted on its own, and each team makes sound decisions inside its own layer. The failures appear where the layers meet, and they appear late, during validation, when the hardware has already been committed.
Motion makes this worse. In most measurement problems the noise has nothing to do with the quantity being measured, so averaging or filtering removes it. On a wearable, movement changes how the sensor sits and produces artefacts at exactly the moments the product cares about most, when the wearer is active. Noise that moves with the signal cannot be filtered away by assumption. It has to be detected and labelled, and the application has to be told.
The reflex, and the fix.
Treat it as an application with a sensor attached
Choose a sensor module from its datasheet, hand the output to an integrator, and build the product on top. It starts fast, and most programmes in this space begin that way.
It fixes the ceiling before anyone knows where the ceiling is, and spreads the three most important decisions across three parties who will each make them well and make them 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, with each irreversible decision made once, in one place, and never reconciled across three teams after the hardware was fixed.
Find out what is recoverable first. Every claim the product makes depends on it and none of them can exceed it.
Establish the recoverable ceiling first
The first architectural question was what the sensing approach can actually acquire under real wear, on a moving person and away from the lab bench. That answer bounds every claim the product can make, so it came first, and everything above it was designed against it.
Give the signal chain its own budget
Conditioning, artefact rejection and extraction are where the product is made or lost. They run inside a power and latency envelope set by the form factor, so the chain was specified with that envelope as an input before a line of it existed.
Partition the compute on purpose
Where each piece of processing runs has power, latency, connectivity and privacy consequences that point in different directions. The split was made once, explicitly, with all four in view. Left implicit, it gets made four times by four people, each optimising for one.
Carry uncertainty across every interface
The application needs the value, and it needs to know when the value should not be trusted: a degraded signal, a poorly seated device, a wearer doing something the chain cannot see through. An interface that carries only the measurement forces the application to treat every reading as equally good, which is the commonest way a technically sound wearable becomes an untrustworthy product.
What each choice cost, and what it bought.
AEstablishing the ceiling before choosing anything
The fastest start is to pick a sensor module from its datasheet and build upward. The architecture phase began instead by establishing what the sensing approach could actually acquire under real wear. That cost time before any hardware was committed, and it meant some claims the product might have wanted were ruled out on paper. What it bought was a set of limits known at design time. The alternative discovers the same limits at validation, after the hardware is fixed and the claims have been made to someone.
BBudgeting the signal chain as its own layer
Conditioning, artefact rejection and extraction are often treated as glue between the board and the app. Here they were specified as a layer with its own power and latency budget, fixed by the form factor and handed over as an input. That made the chain harder to design, because every operation had a cost attached from the start. It also meant the chain would fit on the device when it got there, and the product would not have to give up capability after its claims were set.
CMaking the compute partition once, in the open
What runs on the device and what runs off it touches power, latency, connectivity and privacy, and they pull in different directions. Decided implicitly, it gets decided four times by four people, each optimising one of them. Making it one explicit decision with all four visible cost an argument up front about which constraint gives way where. It bought a split everyone could reason about, and one that would not be quietly reversed by whichever team touched it next.
DCarrying trust across every interface
Every interface between layers carries the measurement and also a statement of how far to trust it: whether the signal was degraded, whether the device was seated well, whether the wearer was doing something the chain cannot see through. This adds work to every layer and every contract between them. Without it the application has to treat every reading as equally good, and a product that displays a bad reading with the same confidence as a good one loses the trust of the people wearing it.
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 designs, each coherent on its own, meeting at interfaces nobody owned. The incompatibility surfaces during validation, the most expensive place to find it, after the hardware is committed.
The architectural foundation of the product: the sensing approach and its established limits, the signal chain and its budget, the compute partition, and the interfaces between the layers, including how uncertainty travels across them. That foundation took risk out of 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 finding it early was that some things the product might have wanted to claim were ruled out on paper. That is a better place to learn it than validation. It is still a constraint, and no amount of design work removes it.
Every significant decision on this programme sat on a boundary between two disciplines: the sensing against what the application needs to claim, the signal chain against the power budget, the partition against four competing constraints, the interfaces against how uncertainty travels. None of them belongs cleanly to a hardware firm, a signal processing specialist or an application team, and each one shapes the others. The approach carries to any product that runs from hardware to software: find the physical ceiling first, budget the layer in the middle as a layer in its own right, make the partition deliberately, and put uncertainty in every interface.
No amount of processing recovers information the sensor never captured. Establish what the hardware can acquire under real use before committing to what the product will claim.
Noise that moves with the activity you are measuring cannot be filtered away by assumption. It has to be detected, labelled and passed on.
On a battery-powered device every processing choice is also a power choice. Give the signal chain a budget from the start and design inside it.
Decide where computation runs as one explicit decision that weighs power, latency, connectivity and privacy together, or it will be decided piecemeal by whoever touches it.
An interface that carries a value without saying how far to trust it makes every reading look equally good. Put uncertainty in the contract between layers.