The default business model in consumer technology is to collect. Gather as much data as you can, keep it, and treat the pile as an asset for whatever turns out to be valuable later — a better model, a new feature, a future product. For a system that watches people exercise at home, following that default would mean quietly assembling a library of footage of people’s bodies. We decided not to build that library.

This was not a values statement bolted on after the product worked. It was a constraint we set before the build started, and it shaped everything underneath. The system runs on-device and streams: it reads how your body is moving in the moment, uses that to coach you, and does not keep a recording of you in order to do it. Understanding a movement and storing a video of it are two different things, and we deliberately kept only the first.

It is the harder road, and that is the point

It is worth being straight about the fact that this is the harder road, because the trade-offs are real and pretending otherwise would be dishonest. A stored archive of user footage is the single most convenient thing an engineering team can have. It is how you retrain a model, reproduce a bug after the fact, or add a feature that needs history. Giving it up means solving all of those a harder way — on the device, inside its compute and latency budget, getting the behaviour right in the moment because there is no tape to review later. We took those constraints knowingly. They are the price of the position, and the position is worth the price.

None of this requires inventing new physics, either — the broader field has spent years showing that useful learning does not depend on hoarding raw user data in one place. Federated approaches, for instance, train a shared model while the underlying data stays on each user’s device rather than being shipped to a central server (McMahan et al., 2017). We are not going to describe our own internals here, and this is not a claim about which specific techniques we use. The point is narrower and more important: minimising what you collect is an engineering path with real precedent, not a marketing constraint accepted at the cost of the product.

The reason it is worth the effort is trust, and in this category trust is not a soft word. You are asking someone to let a system observe their body, at home, while they train — often at the moment they feel least composed. The most reassuring thing such a system can offer is not a policy that promises to look after a recording responsibly. It is the plain fact that there is no recording to look after. A promise can be rewritten, broken, or sold with the company. A design that never captures the data in the first place has nothing to leak.

Why we call it an engineering claim

This is what we mean by engineering ethical intelligence, and why we insist it is an engineering claim rather than a slogan. Ethics that live only in a policy document are a statement of intent, revisable at will. Ethics that live in the architecture are a property of the system: they hold whether or not anyone is watching, because the alternative was designed out. It is the same instinct regulators eventually wrote into law — collect only what you actually need for the thing you are doing, and no more (the data-minimisation principle, GDPR Article 5(1)(c)). We simply preferred to make it true in the build rather than promise it in the footer.

We will not pretend this is the whole design, and we are not going to publish the parts that are not ready. What we will say now is the shape of the decision: on-device, streaming, consent-based, and deliberately not the data-accumulation model most of the industry defaulted into. It is the choice we are most sure of, and the one we would make first all over again.

References

·       McMahan, H. B., Moore, E., Ramage, D., Hampson, S., & Agüera y Arcas, B. (2017). Communication-efficient learning of deep networks from decentralized data. Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS), PMLR 54.

Regulation (EU) 2016/679 (General Data Protection Regulation), Article 5(1)(c) — the principle of data minimisation.