The standard approach to behavior recognition on a wearable is supervised multi-class classification: pick a fixed list of behaviors you want to detect (walking, running, scratching, eating), collect labeled training data for each, train a classifier, ship it. Whatever isn't on the list is invisible. Adding a new behavior means a new training run and a firmware push.

Three problems with this, all documented in the literature:

Static postures fail at the collar. The Helsinki group at Tampere ran sensors simultaneously on the harness (back) and the collar (neck) of 45 medium-to-large dogs. The harness sensor reached ~91% accuracy on a seven-class behavior set. The collar sensor topped out at 75%, with the failure mode concentrated in static postures — sit, stand, lie-on-chest are nearly indistinguishable from a neck-mounted IMU because gravity points in similar directions and collar rotation around the neck adds noise.

Stride frequency scales with body mass. Heglund's 1974 work established a log-linear relationship between body mass and gait transition frequencies across mammals. A 10kg dog's walk frequency overlaps a 40kg dog's trot frequency. Fixed-threshold gait classifiers cannot work across the size range that "dogs" covers.

The interesting behaviors are per-dog. The behaviors a customer most wants to detect — counter-surfing, the pre-bathroom signal, the specific way their dog asks to go out — are by definition not in any fleet-wide training set. A classification platform can't learn them without a custom model per dog, which doesn't scale.

The on-device model produces a hybrid motion-state representation: 6–10 named, interpretable features (activity intensity, postural angle, gait frequency, vocalization intensity, rotational energy, etc.) plus a learned residual embedding that carries whatever the named features don't capture. The interpretable layer carries most of the weight early; the residual earns its keep over time as fleet data accumulates.

This estimator is what the collar actually runs continuously. Its output isn't behavior names — it's a continuously-updating vector describing what the dog's body is doing right now, regardless of whether anyone has labeled that pattern.

On top of the estimator runs the behavior library. Each library entry is a prototype trace through motion-state space, plus a name, plus optional context predicates (location, time-of-day) and an optional response (notification, automation hook). Recognizing a behavior is a matching problem: does the recent motion-state trace look like any library entry?

The library lives partly on the collar (for hot, frequently-matched entries) and partly in the cloud (for rare or per-dog entries). Adding a behavior to the platform is a library update — a few-shot training on new prototype traces, packaged as a small bundle, OTA'd to relevant collars. It is not a firmware revision and it is not a base-model retrain.

Novelty detection is the inverse: the matcher reports when current motion-state is far from any library entry. These unmatched traces queue up as candidates for new library entries. This is how the library grows from beta data — and eventually, how it grows from production user data.

Continuous inference at full quality would burn the battery in hours. Instead, inference is staged: the cheapest possible classifier runs always-on inside the IMU itself, and each subsequent tier is woken only when the tier below it sees something interesting. The MCU spends most of its life asleep.

The dominant battery sink is none of the above. It's GPS — running it continuously costs ~10 mA. Aggressive gating (off at home; on outside the home fence; LoRa beacon if completely lost) is the actual driver of the < 5 mA 24-hour average target.

Rev 6 (shipping today) and Rev 7 (in design) share the same MCU, the same wireless stack, and the same battery system. The differences are concentrated in the IMU and in the addition of a microphone — and those differences are what make Tier 0 and Tier 2 possible.

The LSM6DSV320X selection is the most consequential decision in Rev 7. The SFLP block alone removes one of the firmware-side rotation-invariance layers, lets Tier 1 features consume a chip-native gravity-aligned reference frame, and reduces MCU compute. The ±320g channel means impact events have their own non-blocking data path — they don't compete with the low-g/MLC pipeline for ODR or tree budget. The FSM lets Tier 0 express compound temporal patterns the MLC's decision trees can't.

Most wearable HAR systems window data on the device — capture a 2-second slice, extract features, throw the raw stream away. This is great for storage and bandwidth, and it's a one-way door for the model. You can't redo feature extraction with better techniques two years later, and you can't change your mind about window length.

OneCollar's data pipeline preserves raw streams at full fidelity: IMU at 104–200 Hz, audio (Rev 7) at 16 kHz, synchronized phone video, extracted pose keypoints. Labels from three sources — user tap, pose-derived, and model-predicted — are all first-class. Windowing happens in the cloud, at training time, against a re-extractable corpus.

This costs more storage and more bandwidth than a windowed pipeline. We're paying that cost deliberately. Pose models will get better. Foundation models for wearable IMU are emerging at scales we can't approach in-house. When those land, the training corpus we built in 2026 should still be usable in 2030 — re-windowed, re-extracted, re-pretrained.

The platform is currently being built around supervised classification (Option A) — the standard approach: collect labeled examples, train a classifier, deploy. This works, it's well-understood, and it gets a model shipped on Rev 7.

The aspirational track (Option B) trains the on-device model with multi-task supervision: simultaneously predict behavior labels AND predict pose keypoints derived from synchronized video. Pose is a much richer ground-truth signal than behavior labels — it directly constrains the geometry the IMU is indirectly observing. Multi-task training against pose has been shown to substantially improve representation quality on related problems.

The reason we mention this on a beta page: data collection has to preserve Option B optionality. If we collect IMU-and-labels-only, Track B becomes unavailable. So even if we ship Track A, every Founders Pack session captures synchronized video. The video feeds Track A indirectly (humans label faster with video to reference) and Track B directly.

Rev 6 ships Track A on a constrained sensor stack. Rev 7 ships Track A on the full sensor stack with audio. Rev 8 (TBD) likely consolidates around field learnings and may ship Track B if evaluation favors it. None of these are the product. The product is the behavior library and the platform that grows it.

That platform is intentionally extensible past dogs. The same motion-state-plus-library architecture works for any quadruped — cats, horses, cattle, working farm animals — with a species-specific base model and a species-specific set of library prototypes. The hard parts (sensor fusion, on-device inference budget, training data pipeline, library management) are species-invariant.