Your Body, Your Data

Somewhere, in a climate-controlled room humming with the particular white noise of computational infrastructure, there exists a server farm. And on one of those servers, in a database table that no human being will ever examine directly, there is a record—precise, timestamped, utterly banal in its formatting—of your resting heart rate at 3:47 AM last Tuesday. Your skin temperature fluctuations over the past menstrual cycle. The exact moment you fell asleep and the architecture of your dreams as approximated by motion sensors. This information exists not because anyone particularly wanted it, but because the default settings made collection automatic and nobody thought hard enough about whether anyone should possess it.

This is the bargain we have all accepted with technology: convenience in exchange for the comprehensive documentation of our biological existence. We do it with our locations, our messages, our search histories. But there is something categorically different about health data—and something even more different about reproductive health data—that makes this particular exchange feel less like a transaction and more like a trap whose dimensions only become visible in retrospect, usually at the worst possible moment.

The Default Settings

Most health apps operate according to what might be called the Principle of Maximum Convenience, which is also, not coincidentally, the Principle of Maximum Data Extraction.

When you log something—a symptom, a cycle date, a mood—that information travels. It moves from your device across the internet to a server operated by the company that made the app. There, it joins a database containing the intimate biological details of millions of other users. The company can see it. Their employees can see it, or at least some employees can see some of it. Machine learning engineers need access for training models. Customer support needs access for troubleshooting. Analytics teams need access to understand user behavior. Each of these access points is individually reasonable; collectively, they create something nobody explicitly designed but everyone implicitly enabled.

This is not malice. This is the default. Cloud-first architecture is how software gets built because it is faster, cheaper, and easier. Processing data on a server is computationally simpler than processing it on a phone. Syncing across devices is trivial when everything lives in the cloud. From an engineering perspective, this makes perfect sense.

The problem is that "easy for engineers" and "safe for users" are not the same thing, and the gap between them tends to become visible only under conditions that nobody anticipated when the terms of service were drafted.

When your health data lives on someone else's server, you are making a bet. You are betting that the company will remain trustworthy, indefinitely. That their security will hold, indefinitely. That their business model will not change in ways that make your data suddenly valuable to monetize. That the regulatory environment will not shift in ways that make your data dangerous to have created. That the company will not be acquired by someone with different values. That their employees, all of them, forever, will behave ethically.

That is a lot of bets. And you made them all the moment you clicked "Accept" on a 47-page document you scrolled through in approximately four seconds.^[1]

The Particular Case of Women's Health

Women's health data occupies a strange position in the landscape of personal information. This is not an abstraction; it is a technical and legal reality with concrete consequences that have become increasingly visible since 2022.

Consider what a period tracking app actually knows about you. It knows your cycle length and its variations, which shift based on stress, illness, travel, hormonal conditions. It knows when you log symptoms. It knows your pregnancy test results. It knows when you missed a period. And—perhaps most significantly—it knows when you stopped logging entirely, which is itself a data point pregnant with inference.

Put these pieces together and the app can calculate something profound: the probability that you are pregnant, were pregnant, or were trying to become pregnant. It can infer miscarriages from patterns. It can infer terminated pregnancies from the same data. The information exhaust of simply using the app creates a detailed reproductive timeline that you probably did not intend to create and almost certainly did not intend to make available to interested parties you have never met.

Researchers have demonstrated that pregnancy can be predicted from period tracking data with high accuracy, weeks before the user herself knows.^[2]

In 2022, the regulatory landscape shifted dramatically with the Supreme Court's decision in Dobbs v. Jackson Women's Health Organization. Within months, digital records became newly relevant evidence in ways their creators never anticipated. Companies began receiving legal requests they were compelled to fulfill.^[3] The theoretical risk had become operational.

This is not about any particular position on reproductive rights. This is about the design of systems that collect intimate data without considering the full range of parties who might eventually want access, and what they might do with it.^[4]

The Wearable Complication

Fitness wearables introduce what physicists might call an observer effect, except in reverse: the device observes you continuously whether you are observing it or not.

A wearable does not just record what you tell it. It records what your body tells it, involuntarily, around the clock. Your resting heart rate varies across your menstrual cycle. Your skin temperature rises after ovulation. Your heart rate variability shifts with hormonal changes. Your sleep architecture transforms during your luteal phase. These signals are subtle, but they are consistent, and they are remarkably informative.

We know this because we built Clair to read these signals. Research has demonstrated that machine learning models can identify menstrual cycle phase from wearable biometric data alone with accuracy rates approaching 90%.^[5] That accuracy is a feature when the user controls the data. It becomes something else entirely when someone else does.

A wearable that sends continuous biometric data to the cloud is creating a physiological record that can be analyzed retroactively for purposes the user never imagined. Even if the company never intended to track reproductive health, the raw data to do so exists. Even if the company promised never to share it, promises are not physics. Even if they encrypted it, they hold the keys.

The standard wearable architecture creates a persistent, intimate, involuntary record of your biology. It exists on servers you do not control, protected by policies that can change, accessible to parties you will never meet.^[6]

We looked at this architecture and decided it was not acceptable.

A Different Question

We started with what seemed like a simple question but turned out to be the kind of question that restructures everything downstream of it: what if we built a health platform that genuinely could not access your health data?

Not "would not" access it. Not "promises not to" access it. Cannot access it. Architecturally. Cryptographically. Mathematically.

This is not a marketing position. It is an engineering constraint with specific technical implementations that make certain outcomes impossible regardless of anyone's intentions—including ours. You do not have to trust us, which is precisely the point, because the system does not require trust to function correctly.

Here is how it works.

Edge-First Architecture

The AI that powers Clair—the model that interprets your biometric signals and predicts your hormonal state—does not run on our servers. It runs on your phone.

This is harder than it sounds, which is why almost nobody does it. Machine learning models are typically large and computationally demanding. Running them on-device requires compression, optimization, and careful engineering to make inference fast enough to be useful without draining your battery.^[7] We spent considerable effort making this work because the alternative—sending your raw biometric data to the cloud for processing—was not something we were willing to build.

When your Clair wearable captures your heart rate, temperature, and other signals, that data travels via Bluetooth to your phone. It never travels any farther. The AI processes it locally, generates insights locally, and stores results locally. Our servers never see your biometric data because your biometric data never leaves your device.

This is not a privacy policy. It is physics. Data that does not leave your phone cannot be intercepted in transit, cannot be obtained from a server, cannot be accessed by our employees, cannot be leaked in a breach of our systems. The attack surface is your phone and your phone alone.

Local-First Storage

Your health data is stored in an encrypted database on your device. The encryption key is derived from your credentials and never leaves your phone. We do not have a copy. We cannot generate one. There is no "forgot password" recovery mechanism that involves us decrypting your data because we cannot decrypt your data.

If you lose your phone without a backup, your data is gone. This is a real trade-off. We chose it deliberately because the alternative—holding keys that could decrypt your health history—creates risks we are not willing to impose on users.

Some people will find this trade-off unacceptable. They want cloud backup, seamless device syncing, the safety net of knowing their data survives a lost phone. We understand. We built something for them too.

Zero-Knowledge Backup

If you choose to enable cloud backup, here is what happens: your phone encrypts your health data using a passphrase you create. The encrypted blob—meaningless without your passphrase—uploads to our servers. We store the encrypted blob. We have no idea what is in it.

This is called zero-knowledge encryption.^[8] It means exactly what it sounds like: we know nothing about your data except that some encrypted data exists. We cannot decrypt it. We cannot analyze it. We cannot read it. If someone issues a legal demand for your data, we can hand over the encrypted blob, but without your passphrase, it is cryptographic noise indistinguishable from random numbers.

Your passphrase never touches our servers. The encryption happens entirely on your device before anything uploads. We designed it this way specifically so that "we cannot access your data" is not a promise requiring your trust but a mathematical fact requiring only that standard cryptography works as intended.

There is a cost: if you forget your passphrase, we cannot help you recover your data. It is gone. This is the trade-off that zero-knowledge encryption requires. The same property that protects your data from us also protects it from you if you lose the key. We believe this trade-off is worth it. You may disagree, which is why backup is optional.

What "Cannot" Means

Precision matters here, so let me be precise about what we mean when we say we "cannot" access your data.

We cannot access your raw biometric data because it never leaves your phone. The architecture makes transmission impossible.

We cannot access your health insights because they are processed on-device. There is no server-side processing of personal health information.

We cannot access your encrypted backups because we do not have your passphrase and cannot derive it. The cryptography makes decryption computationally infeasible.

We cannot comply with a demand for your health data because we do not possess it in a usable form. You cannot be compelled to do something you are technically incapable of doing.

This is different from most privacy policies, which describe what a company chooses not to do with your data. Choices can change. Policies can be updated. Business models can pivot. Leadership can turn over. What we have built is not a choice; it is a constraint. The architecture enforces what policies can only promise.

The Research Problem

There is a genuine tension here that deserves acknowledgment: health research requires data, and data requires users to share something. If everyone's data stays completely private, collective knowledge does not advance. Women's health has already suffered from decades of underfunding and insufficient research. We do not want to make that worse.

We resolved this tension with a three-tier consent system for research participation.

Tier one: local-only. Your data never leaves your device. You contribute nothing to research. This is the default.

Tier two: aggregated statistics. You allow us to collect aggregated, anonymized statistics—computed on your device and contributed in a form that cannot be traced back to you. We use differential privacy, a mathematical technique that adds calibrated noise to individual contributions, making it impossible to reverse-engineer any individual's data from the aggregate.^[9]

Tier three: encrypted research contributions. You allow your anonymized data to be included in research datasets for academic studies. Your data is encrypted before it leaves your device. It can only be decrypted by approved researchers operating under institutional review board oversight, not by us.^[10]

Every tier requires explicit opt-in. The default is maximum privacy. Participating in research is a choice you make actively, not a box you forgot to uncheck buried in page 34 of terms nobody reads.

What This Actually Means

Numbers and architecture are abstract. Let me make them concrete.

It means that if you are tracking fertility, that information exists only on your device. If your circumstances change in ways that make that history suddenly sensitive, there is no server to obtain records from, no company to pressure, no data trail to follow. The information lives and dies on a device you control.

It means that if you live somewhere with restrictive policies and your health history becomes legally relevant, your tracking data cannot be used because it was never recorded anywhere accessible.

It means that if we are acquired, if our investors pressure us, if our business model fails and we need to pivot, if our employees are compromised, if our servers are breached, your health data remains unaffected because it was never in our possession to begin with.

It means that the bargain you make when you use Clair is fundamentally different from the bargain you make with most health technology. You are not trading privacy for functionality. You are getting functionality without giving up privacy, because we engineered the system to make that possible.

The Harder Path

I want to be honest about something: building this way is harder. It would have been faster and cheaper to do what everyone else does. Cloud processing is simpler. Server-side storage is more forgiving. Zero-knowledge encryption creates real usability challenges that require careful design to navigate.

We made our engineering lives more difficult on purpose.

We did this because we believe the alternative is not acceptable for this particular category of data at this particular moment in history.^[11] We did this because the standard industry practices, applied to women's reproductive health, create risks that users do not fully understand when they agree to terms of service. We did this because "trust us" is not good enough when the architecture could be designed to make trust unnecessary.

We could be wrong about the trade-offs. Some users will prefer convenience over privacy. Some will want cloud backup without the cognitive load of managing a passphrase. Some will trust companies to protect their data and resent the implication that they should not. That is fine. There are other products for those users.

Clair is for users who want a different bargain—one where the technology serves them without surveilling them, where the device is a tool and not a witness, where the data their body generates belongs to them alone.

Your Body, Your Data

The title of this piece is not a slogan. It is a design principle, an engineering constraint, and—we hope—a statement of values that the technology actually lives up to.

Your body generates data constantly, involuntarily, whether you are thinking about it or not. That data is yours. It should remain yours. It should not become a permanent record on someone else's servers, accessible to parties you have never met, for purposes you never agreed to, under policies that can change without your consent.

We built Clair because we believe that continuous health monitoring is possible without continuous surveillance. We built it because women's health data is sensitive in ways that the current environment has made newly urgent. We built it because the standard bargain—convenience in exchange for intimacy—is not one we wanted to offer.

Your body, your data. Not because we promise. Because we designed it that way.^[12]

Clair is building the first privacy-first continuous hormone tracker. Reserve your spot and get 50% off at wearclair.com.