On-device AI for a wearable is a pipeline, not just a model file. The result depends on which measurements reach the model, how they are grouped, what the hardware can execute, and how the application handles uncertainty. A model that runs once on a development board has cleared an early technical milestone. It has not yet established dependable behavior during everyday wear.
This guide uses a hypothetical activity classifier to connect those decisions. Start with the wearable AI device overview if you are choosing where inference should run. Here, the objective is a small, inspectable system with measurable operating limits.
Define the task before selecting a model
Write a plain-language decision: “During a user-started recording, classify each eligible interval as walking, running, stationary, or unknown.” Specify the intended users, device placement, supported activities, and acceptable response delay. Avoid starting with a broad promise such as understanding the user's health or detecting every possible behavior.
Then define the consequence of an error. An activity label used to organize a workout diary can tolerate different behavior from a notification that interrupts someone. Decide whether a wrong label, a delayed label, or an unknown result causes more friction. That judgment determines which evaluation results matter.
Establish a simple baseline, such as a rules-based movement threshold, using the same evaluation data as the model. The comparison should reveal whether machine learning improves the actual feature enough to justify its memory, testing, update, and support requirements.
Construct sampling windows deliberately
Define the model's input clock separately from the API delivery schedule. A batch arriving once per second might contain samples acquired at a much higher frequency. Use acquisition timestamps and documented sampling behavior rather than assuming that network arrival intervals describe the underlying signal.
As a hypothetical configuration, consider three accelerometer channels sampled at 50 samples per second with a two-second window. Each window contains 100 time steps and 300 scalar channel values. At four bytes per value, the input values alone require 1,200 bytes before metadata or model working memory. These numbers illustrate arithmetic, not a recommended sampling rate.
Choose whether windows overlap and explain the latency implications. If you advance that two-second window every half second, adjacent examples share much of their content. Track missing samples and define when a window becomes ineligible. Filling a long gap with repeated values can manufacture a stationary pattern that the wearer never produced.
Keep preprocessing identical across environments
Make channel order, units, coordinate convention, normalization, and filtering part of the model contract. A model trained on one axis order should not receive another because a device adapter returns fields in a different order. Likewise, document whether acceleration includes gravity and how device orientation is represented.
Use representative recorded windows as test fixtures. Process the same window through the training pipeline and the device implementation, then compare the resulting tensors within a justified tolerance. Test missing values, clipping, and values near the sensor's documented range limits. This catches errors that a successful model load cannot reveal.
Choose between direct time-series input and engineered features based on the task and hardware. Means, variation, or frequency features can be useful candidates, but each creates assumptions about the signal. Keep the transformation understandable enough that you can diagnose a misclassified recording without retraining blindly.
Check the runtime and hardware together
Google's LiteRT for Microcontrollers overview describes inference on constrained devices, a limited set of supported operations, and manual memory management. Its workflow trains and converts a model before deployment; on-device training is not supported by that runtime. These constraints make operator compatibility and memory planning early design questions.
Measure the complete firmware image and peak working memory on the target hardware. Include sensor buffers, Bluetooth activity, application state, and the inference runtime. A small model download does not establish that the application fits in RAM or that its worst-case execution time meets the sampling schedule.
If conversion fails, inspect unsupported operations before changing the whole architecture. If execution succeeds, compare converted-model outputs with the development version on recorded examples. Quantization or another optimization should earn its place through measured behavior, not file size alone.
Evaluate on people and sessions held out
Plan the dataset split before generating overlapping windows. Group recordings by participant when evaluating performance on unfamiliar people, and consider additional separation by session, device, or environment according to the product claim. Randomly mixing near-identical windows across training and evaluation can give an unhelpfully easy test.
Keep label provenance: who labelled the recording, what reference procedure they used, and which intervals were ambiguous. Review transitions between activities instead of retaining only clean examples. The eventual product will encounter someone slowing down, moving a hand while seated, or wearing the device differently.
Report the errors relevant to each class and the number of examples behind them. An overall score can conceal failure on an uncommon activity. Also inspect results across the participant and hardware conditions that you intended to support. Document unsupported conditions explicitly in the feature specification.
Allow the system to abstain
A classifier output is evidence for an application decision, not automatically a reliable confidence percentage. Determine whether its scores are useful for selecting uncertain cases on held-out data. Choose any acceptance threshold using that evidence and the cost of errors in your feature.
Combine model uncertainty with acquisition quality. A confident label from a window containing a sensor dropout should not pass merely because the model returns a large score. Treat input eligibility and output acceptance as separate gates, with distinct reasons for an unknown result.
Define how the interface presents that outcome. “Not enough usable motion data” can prompt a different action from “Activity outside the supported set.” Avoid turning either case into a fabricated zero. The wearable data quality guide provides related patterns for preserving missingness and provenance.
Test the behavior across time
Evaluate the sequence of displayed labels, not only individual windows. A model that alternates between walking and running on every update can create a distracting diary even when most window labels are acceptable. Consider a persistence rule or another documented temporal policy, then test how much delay it introduces when the activity actually changes.
Keep the raw inference result separate from that application policy during evaluation. This makes it possible to identify whether an unwanted transition comes from the model or the smoothing logic. Include the beginning and end of a recording, short activities, and unknown intervals in the test set. Do not let a smoothing rule carry a confident activity label across a long period without usable input.
Measure the whole power budget
Record energy use for sensing, buffering, preprocessing, inference, display updates, and radio transfer under realistic operating conditions. Reducing inference frequency may help one design but barely affect another if its main cost lies elsewhere. Make the measurement answer which component actually controls the budget.
Test continuous activity, idle wear, disconnection, and recovery. A retry loop can produce a worse battery experience than the normal inference path. Establish what happens as power falls: lower sampling, pause optional processing, finish a recording, or ask the user to recharge. Any fallback must preserve the meaning of the outputs.
Consider local processing and transmission together. Sending a compact activity event can reduce transfer volume compared with uploading every sample, but it also removes information that might support later debugging. Decide which diagnostic samples, if any, are necessary and permitted before choosing a retention policy.
Version the complete inference contract
Attach a model version and preprocessing version to derived results. Maintain a compatibility record for device capabilities, firmware, sensor configuration, and supported labels. This lets the application distinguish a product change from an apparent change in the user's activity history.
For updates, validate compatibility before activation and retain a known working recovery path. Test interrupted installation, restart, and a device with insufficient space. Keep previous evaluation results so a new release can be assessed against the same important failure cases.
Choose launch gates for task usefulness, input handling, execution time, memory, energy, and user-visible uncertainty. The WearAPI.com integration notes can help organize the surrounding data contract. Ship the smallest supported capability whose behavior you can explain, then expand it with evidence from additional devices and real recording conditions.
