The architecture, threat model, and open questions for a privacy-native personal health stack.

What we defend against, and what we don't.

Primitives

Today, computation runs server-side over data encrypted at rest, with minimization and pseudonymization before egress. The target privacy architecture is built on Fully Homomorphic Encryption (the TFHE family of schemes), a far-horizon R&D goal rather than a current capability. For that eventual encrypted-compute path we target Zama's Concrete ML framework, the only mature toolchain that compiles ordinary ML graphs (linear models, decision trees, small neural nets) into FHE circuits without per-model cryptographer effort.

The target custody model is device-bound: each user's secret key generated and stored inside a hardware-backed keystore (iOS Secure Enclave, Android StrongBox), never exported, with encryption and decryption client-side so the key never traverses the network. In the current MVP, key custody is server-side; moving to device-bound custody is part of the build this round funds.

Threat model

Five attacker classes, in order of severity:

• VitaCrypt-infrastructure breach: adversary controls our compute infrastructure. Sees: ciphertext only. Cannot recover plaintext without the user's device-bound key. Mitigated.
• Compute substrate insider: adversary is a privileged operator on a co-located GPU. Sees: ciphertext, model weights. Cannot recover plaintext. Mitigated.
• Network observer: adversary on-path between device and compute. Sees: TLS-encrypted ciphertext blobs. Mitigated.
• Device compromise: adversary has root on user's device. Sees: plaintext signals, key, all decrypted insights. Not mitigated, fundamental to any client-side architecture.
• Side-channel timing: adversary observes per-query latency to infer input class. Partially mitigated via padding to fixed-cost circuits; still being characterized.

Three principals. One invariant.

Target invariant: every byte of plaintext lives in exactly one place, the user's hardware. Everything else, transport, storage and compute, handles ciphertext only.

Stage breakdown

The pipeline is four functions, each with explicit pre/post conditions on where data may exist in plaintext:

Encrypted output structure

The compute substrate returns a small, structured ciphertext encoding: a fixed-size set of action slots, each with a score, a category code, and an opaque reference into a pre-cleared citation pool. The structure is fixed; only the values vary. This bounds the inference an attacker observing output size can make.

Implementation status: now vs target

Latency, throughput, and the cost frontier.

FHE is not part of the MVP. The targets below are for the roadmap FHE path, bounded by what is honestly achievable on the current Concrete ML stack on commodity GPU servers.

Latency strategy

We avoid running FHE on every user interaction. The product surface is asynchronous by design: the user composes a query (or the system schedules a daily one), the server runs inference, and the result lands as a notification 3–10 minutes later. Interactive UI uses cached plaintext on the user's own device.

What 300s buys us

The widely cited Zama benchmark for encrypted DNA ancestry inference at ~96% accuracy with sub-300-second latency is for a single-task, single-domain query on a representative SNP subset. Multi-layer inference (DNA × environment × wearable signal × microbiome) is multiplicatively heavier; our ~5-minute target reflects that. Source verification pending; see §08.

Health signals, unified into one profile.

The profile is built to ingest any health signal; the current set is below. Each row reflects current status, not the aspirational endpoint. Live = in the app today. Wired = pipeline built, waiting on a file or connection. Beta / Partial = limited today. A date = roadmap.

Client-side requirements

In the target architecture the encryption stage runs on the user's device. Target hardware:

• iOS: A14 Bionic or later (Secure Enclave with Cryptokit), iOS 16+.
• Android: StrongBox-class TEE, Android 13+.
• Desktop / web (fallback): WebCrypto + IndexedDB-stored key, scoped per origin. Acceptable but weaker custody than mobile keystore.

On-device FHE encryption is not yet benchmarked on our payloads. Heavier formats (whole-genome) would be pre-summarized into compact SNP subsets before encryption.

What we add, and where the privacy line gets crossed elsewhere.

Every wearable on the market is a single-signal sensor plus a closed app. VitaCrypt is a synthesis layer that uses the sensor's data alongside DNA, microbiome, labs, environment, and survey context. The honest comparison below.

The five things that matter

1. None of them have DNA, microbiome, labs, environment, or live research. Every device in this category is a sensor company. VitaCrypt is a synthesis layer.
2. Every one of them analyses your data in readable form on their cloud. Not a moral judgment; it's how their compute works. Today so do we; FHE is how we plan to change that.
3. Several actively monetise that data. Oura runs data-sharing agreements with academic and pharmaceutical partners. Whoop offers aggregated population-level data for research and commercial purposes. Fitbit (Google) ranked among the most permissive sharing terms in npj Digital Medicine's 2025 wearable-privacy systematic analysis.
4. None of them are covered by US provider health-privacy law. That law applies to providers, insurers, and clearinghouses. Consumer wearables are categorically outside (Athletech News, 2024).
5. The legislative trend is favourable. HIPRA (the Health Information Privacy Reform Act, introduced by Senator Cassidy on November 4, 2025) would extend provider-grade privacy protections to Apple Watch / Oura / Whoop data. Lawmakers are currently drafting the kind of protection VitaCrypt is building toward.

Positioning

We don't replace, we connect. Keep your Oura. Keep your Apple Watch. Keep your Whoop. We pull what they read and add what they can't see: DNA, microbiome, labs, environment, validated surveys, live science. The encryption is the price of admission, not the product.

From your profile to cited, bounded next actions.

Three tiers, and a clinical boundary

Every insight is classified before it is shown. This router, the boundary, and the CPIC reference are the live, unit-tested core of the product today; the cryptographic primitives in §01 to §03 describe the privacy roadmap for how this computation could eventually run under encryption.

• Evidence-backed: real PubMed PMIDs, a confirmed-N-of-M corroboration check across the retrieved papers, and a composite High / Moderate / Emerging confidence indicator.
• Exploratory: cross-domain connections the literature has not settled, labelled preliminary rather than asserted as fact.
• Redirect: anything clinical is withheld server-side and replaced with a warm handoff to the right clinician. The boundary is software-enforced, not a disclaimer.

For established pharmacogenomic markers (starting with CYP2C9) the published CPIC consortium guidance is shown as a descriptive reference, the one place a grade comes from a clinical consortium rather than a model.

Scoring model (target FHE path)

Under the hood the scoring model is intentionally small; large neural nets are not practical under FHE, which is why the FHE path stays a roadmap item. The target FHE pipeline composes from:

• FHE-compiled gradient-boosted decision trees, for genotype × environment interaction lookups. Concrete ML supports this natively.
• FHE-compiled linear / logistic regressors, for risk scoring on continuous biometric inputs.
• A small set of hand-curated decision rules, encoded as FHE-friendly boolean circuits, derived from systematic reviews.

Output is a vector of action proposals, each with a confidence score and a reference into the citation pool. The citation pool itself is a pre-cleared index over the corpora listed below, computed in plaintext at indexing time; the lookup that maps from inference to citation happens on-device after decryption.

Research-agent (model layer)

A separate, non-FHE component watches the public scientific literature for new findings relevant to the action proposals our inference model generates. This is a vendor-agnostic architectural choice, not an LLM endorsement.

• Model class: a frontier generalist LLM grounded in biomedical RAG over the corpora listed below. Our preferred posture is self-hosted open-weight (Llama 3.x / Mistral / Qwen class): provider-free, so no third-party API sees a user-derived token. Today a hosted frontier model is used as the bootstrap option; it is not the long-term choice. Per arXiv 2408.13833 (2024), fine-tuned biomedical LLMs (Meditron, Med42, OpenBioLLM) do not consistently outperform frontier generalist LLMs grounded in biomedical RAG, so we do not train or fine-tune a proprietary medical model either.
• What the model reads: today, public papers plus a minimized, pseudonymized summary of the user's profile, which it needs to write the recommendations. Target: public papers and curated open corpora only, with the profile match done under FHE.
• How findings reach the user: the agent emits structured tags (e.g. variant=MTHFR-C677T, exposure=PM2.5-chronic). Profile-vs-tag matching is a cheap circuit, not transformer inference; running that match under FHE, so the server never sees the profile in the clear, is the privacy roadmap goal.
• What we explicitly do NOT claim: "encrypted LLM inference." No production-grade FHE-compiled transformer exists today. Nillion (MPC) and Apple Swift HE (BFV primitives) are not yet a single-user LLM substitute. We will revisit if/when the landscape changes.

Citation pipeline: sources, live and roadmap

Every action surfaced to the user carries a citation count. The "~40M" figure on the landing refers to the size of the PubMed corpus we search live, not the number of papers behind any single recommendation. Cochrane Library hosts ~4,500 systematic reviews. Sources, live and roadmap:

What the output never includes

Personal doses, medication changes or diagnoses. Today recommendations are written server-side by a hosted LLM over a minimized profile summary; a guard then blocks doses, medication changes and diagnoses, and falls back to a fixed template if a sentence fails. We do not run LLM completions over ciphertext; FHE-friendly transformer inference exists in research but is not yet production-viable.

How we will know it works.

FHE preserves the privacy of inputs. It does not, by itself, guarantee that the recommendations on the other side are clinically useful. Validation is a separate problem, addressed in three stages:

Stage 1: Closed alpha (Q4 2026)

Closed-alpha cohort of ~50 design partners runs the full pipeline. Each receives weekly insights and reports adherence + outcome on standard questionnaires (PSQI, wellbeing scales, custom biomarker check-ins). Goal: detect implementation defects and obvious mis-calls before any external study.

Stage 2: IRB-supervised longitudinal study (Q1 2027 – H2 2027)

Partnership with an academic medical center for a 12-month open-enrollment longitudinal study. Endpoints: inflammatory marker trajectories (CRP, IL-6), HRV trends, glucose variability, validated quality-of-life scores. We do not promise clinical-trial-grade evidence at the MVP scale; we promise honest, IRB-supervised observational data.

Stage 3: Clinical decision support pilot (H2 2027+)

HL7/FHIR connector + clinician-side decision support pilot with the same medical center. Compliance path agreed with partner providers.

Where we are still resolving the story in public.

The honest answer to "is the architecture on the landing exactly what is on GitHub" is: directionally yes, in detail not yet. The MVP is live, early-stage and pre-launch. The list below tracks every claim on the landing we are independently verifying before lock.

A full pre-launch resolution of these questions is the contract of this document's research brief. Investors and prospective partners who want the current status on any specific item can request it directly.

• [1] Zama, Concrete ML documentation. github.com/zama-ai/concrete-ml. FHE toolchain targeted by our roadmap compute layer.
• [2] Chillotti, Gama, Georgieva, Izabachène, TFHE: Fast Fully Homomorphic Encryption over the Torus. Journal of Cryptology, 2020.
• [3] Zama, bounty submission #95: encrypted whole-genome ancestry classification, 96% accuracy at ~300s latency on a single CPU (1000 Genomes test set). github.com/zama-ai/bounty-and-grant-program/issues/95
• [4] Grand View Research, Digital Health Market Size, Outlook 2024–2030.
• [5] Bank of America Global Research, The Longevity Economy. 2025 industry sizing.
• [6] PubMed (National Library of Medicine), primary biomedical literature index, ~40M citations.
• [7] Cochrane Library, systematic reviews; secondary source for protocol recommendations.
• [8] Apple, Secure Enclave overview. developer.apple.com/security.
• [9] Android, StrongBox keystore. source.android.com/security.

This is v0.1.2. Items marked pending verification are tracked in §08 and the research brief. Numbers and stack-specific claims will be locked once independent verification completes.