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

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

Primitives

The compute layer is built on Fully Homomorphic Encryption, specifically the TFHE family of schemes. We target Zama's Concrete ML framework for production inference because it is the only mature toolchain that compiles ordinary ML graphs (linear models, decision trees, small neural nets) into FHE circuits without per-model cryptographer effort.

We layer FHE with device-bound key custody: each user's secret key is generated and stored inside the platform's hardware-backed keystore (iOS Secure Enclave, Android StrongBox) and never exported. Encryption and decryption happen client-side; the key never traverses the network.

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.

Every byte of plaintext lives in exactly one place: the user's hardware. Everything else — transport, storage, 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.

Latency, throughput, and the cost frontier.

FHE was theoretical in 2020 and is production-tractable in 2026. Our MVP performance targets are 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.

Six streams of biology.

Each row below reflects MVP status, not aspirational endpoint. Live = production-ready integration today. Planned = on the 2026 roadmap. Partner = requires explicit partnership we have not yet signed.

Client-side requirements

The encryption stage runs on the user's device. Minimum hardware requirements at MVP:

• 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.

FHE encryption of a typical multi-layer payload runs on-device in 8–20 seconds. Heavier formats (whole-genome) are 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 stores your data unencrypted on their cloud. Not a moral judgment — it's how their compute works. They have to see it to analyse it. We don't.
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 HIPAA-covered. HIPAA 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 HIPAA-like protections to Apple Watch / Oura / Whoop data. Lawmakers are currently drafting the protection VitaCrypt already provides cryptographically.

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 ciphertext patterns to cited next actions.

Inference model

The encrypted inference model is intentionally small. Large neural nets are not yet practical under TFHE. We compose the system 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, no third-party API sees a single user-derived token. Hosted frontier models are an acceptable bootstrap option but 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: public papers and curated open biomedical corpora — never the user's profile. The model has no access to ciphertext or plaintext user data.
• How findings reach the user: the agent emits structured tags (e.g. variant=MTHFR-C677T, exposure=PM2.5-chronic). Profile-vs-tag matching happens under FHE — a cheap circuit, not transformer inference.
• 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 — full source menu

Every action surfaced to the user carries a citation count. The "37M+ records cross-referenced" figure on the landing refers to the size of the upstream PubMed corpus we query against, not the number of papers behind any single recommendation. PubMed sits at ~37M indexed records per the NLM open-data portal; Cochrane Library hosts ~4,500 systematic reviews. The full MVP source menu:

What the output never includes

Free-form natural language generated from the user's encrypted profile. We do not run LLM completions over ciphertext at MVP scale — FHE-friendly transformer inference exists in research but is not yet production-viable. All copy presented to the user is composed on-device from short templated insight slots, with tags sourced from the research-agent layer above.

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 — Synthetic dose-response (Q3 2026)

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

Stage 2 — IRB-supervised longitudinal study (Q4 2026 – 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 (2027)

HL7/FHIR connector + clinician-side decision support pilot with the same medical center. Optional HIPAA BAA path for 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 in development. The list below tracks every claim on the landing we are independently verifying before lock.

• [1] Zama — Concrete ML documentation. github.com/zama-ai/concrete-ml. Production FHE toolchain targeted by our 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, ~37M records.
• [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.0. Items marked pending verification are tracked in §08 and the linked research brief. Numbers and stack-specific claims will be locked once independent verification completes.