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.
How Most Health Apps Store Your Data by Default
The standard architecture for health wearables is straightforward: sensors capture data, data transmits to servers, servers process it, insights return to the user. This model works well for the company. It is less obviously good for the user.
Once your health data reaches a server, it exists in a context you do not control. The company's privacy policy governs what they will do with it—but privacy policies are not physics. They can change. Companies can be acquired. Legal demands can arrive. Data breaches happen. The gap between "we promise not to" and "we cannot" is significant, and that gap is where most health data lives.
Reproductive health data occupies a special category of sensitivity. The data generated by tracking your menstrual cycle, fertility window, hormonal patterns, and pregnancy status is precisely the kind of data that has historically been used against the people it describes.
We know this because we built Cyra 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%. That accuracy is a feature when the user controls the data. It becomes something else entirely when someone else does.
Building a Health Platform That Cannot Access Your Data
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.
On-Device Processing: Why Your Hormone Data Never Leaves Your Phone
The AI that powers Cyra (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. We spent considerable effort making this work because the alternative of sending your raw biometric data to the cloud for processing was not something we were willing to build.
When your Cyra 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.
Encrypted Local Storage: Your Keys, Your Health Data
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 of holding decryption keys to your health history creates risks we are not willing to impose on users.
Zero-Knowledge Cloud Backup for Women's Health Data
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. 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.
The Difference Between Will Not and Cannot
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 Privacy Trade-Off: What You Gain and What You Give Up
We want to be honest about what this architecture costs. It is harder to build. It is harder to maintain. It limits certain features that users of other platforms might expect. We cannot, for example, let you access your full health history from a web browser without your device, because we do not have your data to serve you.
These limitations are intentional. We made them deliberately. We believe they are worth making. But we also believe you should understand them before you choose Cyra, so you can make an informed decision about whether this trade-off is right for you.
Your body generates data about you. That data belongs to you. We built the architecture to match that belief.