HELIOS — A Longevity Companion That Never Sees Your Data

Consumer longevity has become one of the fastest-moving categories in health — biomarker panels, continuous monitoring, protocol design, all of it sold on the promise that someone will finally explain what your numbers mean. The category's growth is real. So is its structural problem: every product in it requires the customer to upload the most sensitive data they own to somebody else's server.

That trade is accepted reluctantly, and it caps the market. The people with the most to gain from longevity intelligence — executives, clinicians, high-net-worth individuals, anyone with a diagnosis they would rather not see in a breach notification — are precisely the people least willing to make it. Meanwhile the regulatory floor keeps rising: lab results and symptoms are special-category health data under GDPR Article 9, and in France, hosting them without HDS certification carries criminal exposure, not just a fine.

Most operators treat that as a compliance cost to be absorbed. We read it as a positioning opportunity. If the data never arrives on your infrastructure, most of the exposure never exists — and the privacy claim stops being a marketing sentence and becomes something a buyer's own IT team can verify. That reframing is the entire product.

Moving a hosted product onto the desktop usually means rewriting it. The obvious paths were Pyodide in the browser, or a TypeScript port of the reasoning engine. Both were rejected for the same reason: the engine contains the safety gate — the logic that decides, for example, whether to block testosterone therapy for someone with a prostate-cancer history. Earlier reviews had already found real fail-open bugs in exactly that code. A second implementation of a safety gate is not a maintenance burden. It is a divergence risk, and divergence in that file is a patient-harm risk.

The alternative required one property to hold: the engine package had to have zero runtime dependencies, standard library only. It did — and protecting that became a standing architectural constraint rather than a preference. Because it held, the existing, already-tested engine could be frozen with PyInstaller and shipped unchanged as a Tauri sidecar. The safety-critical code that runs on someone's laptop is the identical code that was reviewed, tested, and hardened on the server.

Storage was solved the same way — as a seam rather than a rewrite. Postgres and SQLite switch at a single connection point, with the three known compatibility traps handled by registered converters at that seam, leaving repository call sites essentially untouched.

The parity claim was not asserted — it was measured. The engine's analysis output is byte-identical across Postgres, the encrypted SQLite vault, and a complete hosted-to-desktop migration round-trip, verified by hash. Both test axes run green, plaintext and encrypted, and the packaged application performs create-vault, unlock and analyse inside the frozen binary rather than only in development.

The more valuable finding came from an adversarial review that went looking for problems tests were protecting. It found fabricated clinical data in the weekly plan: a specific exercise session count that the underlying knowledge base never stated, accompanied by a test asserting the figure had been transcribed from source. The test passed. The claim was invented. Two related defects sat beside it — engine ranges collapsing to their lower bound, and a fallback that turned the absence of data into a positive daily prescription.

The same pass deleted a registered but uncalled IPC endpoint whose only function was to accept a passphrase and retain it. Unreachable by design, callable by any script in the webview. Dead code in a security boundary is not dead — it is attack surface.