Reference

Zero-egress health AI: how a LifeCare node keeps raw data in place

Zero egress means the models run where the raw health data lives, and what leaves is interpretation: a score, a band, a sentence with no number in it. This page describes how a LifeCare node enforces that, in code, and how anyone can check that a given node runs the code that does.

Published 4 September 2026, updated 30 September 2026 (the attestation paragraph). Describes the node software serving the LifeCare network; the API contract it refers to is published and drift-tested.

What zero egress means, and the three places a model can run

Every AI product that reads health data has to answer one question: where does the raw value go when the model needs it? There are three answers.

To a cloud model. The value is sent to a provider's inference service. This is what a memory layer or a chat assistant does when it puts your data in the prompt. Privacy rests on the provider's policy.
To an attested remote enclave. The value is sent, but to hardware that can prove what it runs and cannot retain what it sees. This is the confidential-computing answer, and at its best it is verifiable.
Nowhere. The model comes to the data. Inference runs on the machine that holds the raw values, and only interpreted outputs cross to anything else. This is zero egress.

A LifeCare node is the third answer. The node is a machine, physical or virtual, owned and operated by the person's provider, holding that person's raw data under their consent. It runs the models. Its API serves apps, and the contract of that API is that no raw biometric value is ever served. The person's app, their weekly letter, their guardian's replies are all interpretation produced next to the data, not data sent away for interpretation.

Three layers of enforcement

A promise like "raw data never leaves" is only as good as the code paths it would have to leak through. On a node there are three, and each has its own gate.

Path	Gate	Where it lives
A model call	Model adapters refuse any endpoint that is not on the machine, and on a shared model server accept only the model ids declared in the manifests	The model runtime
An agent's read	Agents never hold the data source; they hold a guarded accessor limited to declared scopes, and every read acquires a token and lands in the person's ledger	The data interfaces
A response to an app	Every response is a complete field whitelist; prose is screened numeric-free before it is shown; inputs are acknowledged without echoing values	The API contract and the voice screen

Layer one: where models run

The node's model runtimes are constructed with an endpoint, and the constructor refuses anything that is not a loopback address. The refusal is not a warning; it raises, with the reason in the message: inference must stay on the node.

refusing non-local model endpoint 'https://api.example.com' — inference must stay on the node (PHI boundary)

A loopback address is not enough on its own, because a model server on the machine can proxy to a cloud model behind a local port. So each model is declared in a manifest with its id, runtime, quantization, licence and the endpoint it is served from, and the adapter for a shared server is fenced to exactly the ids declared against it. A request for any other model on that server is refused, whatever the server's catalog offers. The rule in the design notes is one line: a local URL alone does not prove local inference.

Today's node runs two open-weight models on an NVIDIA DGX Spark: a 14-billion-parameter reasoner for synthesis and a 30-billion-parameter mixture-of-experts model for the conversational guardian, both Apache-2.0 licensed, both served on loopback. Replacing either is a manifest change. The weights never live in the repository, and the licence is part of the manifest because the freedom to run the model anywhere is part of the sovereignty claim.

Layer two: what an agent may read

An agent on the node never receives the longitudinal data source. The runtime hands it a guarded accessor restricted to the data scopes its definition declares, from the same fixed vocabulary the authorization server knows: cgm, daily, labs and the rest. A read outside the declared scopes fails with a permission error before any value is touched. Every read inside them acquires a token for the person, the scope and the agent's purpose, and writes an access event to the person's ledger. The agent is a requester like any app, with a narrower door.

Layer three: what may leave

The API contract lists, for every response, the complete set of fields that will ever appear. The weekly summary is representative:

GET /v1/users/{user_id}/summaries/weekly/latest

{
  "user_id": "…",
  "kind": "muscle-preservation",
  "period_start": "2026-06-04",
  "score": 57,
  "band": "at-risk",
  "summary": "It sounds like this week was a bit of a challenge…",
  "components": { "protein_support": 0.0, "training_stimulus": 16.7,
                  "loss_velocity": 25.0, "lean_mass_trend": 15.0 },
  "generated_at": "2026-06-10T21:56:37Z"
}

A score, a band, sub-scores on a fixed scale, a date and a sentence. The sentence contains no numeric value by contract. Three mechanisms hold that line:

The voice screen. Every generated sentence passes a screen before it is shown: numeric-free, free of internal vocabulary, inside the general-wellness boundary, and free of clinical language. A sentence that fails is sent back to the model with the reason as the retry instruction; a sentence that cannot pass falls back to authored copy, so unscreened model text is never served.
The floors. Below the screen, compose-time floors refuse specific values outright: a raw glucose reading, because the node never states one, so any such number is fabricated; kilograms, milliseconds, beats and hours on the same logic. The prompts order the model to spell counts as words, and the floors check the spelled forms too.
Acknowledgement without echo. When a person or their scale reports a weight, the acknowledgement returns the day it was recorded and whether a related value was estimated, and not the weight. When an app contributes an experience episode, its context and outcome must be categorical labels; a label carrying a digit is refused with 422.

What the node keeps, and for how long

Raw provider payloads are held in a buffer for twenty-four hours and purged. The derived series the node computes from them are what it keeps.
What the node remembers about a person in words (the twin's facts and reflections) rejects any value carrying a digit at write time, and is encrypted under a per-person data-encryption key.
Erasure is key destruction. The person's key is destroyed, and every payload encrypted under it becomes unreadable, on the node and in any backup that holds a copy. Keys are stored wrapped under a node master key that never travels in a backup bundle.

Where raw data enters

Two ways, and neither passes through the consent layer. A source with a cloud API, such as a continuous glucose monitor's partner API, is fetched by the node under a token the person granted; the consent layer ran the connection handshake and holds the grant, and the bytes travel provider to node. A source that exists only on the person's phone or scale, such as a health-data store on the handset or a Bluetooth body-composition reading, is shipped by the person's own edge app directly to their node under an insights-scoped token. Device to node. In both cases the node is the first and last place the raw value is stored.

Verifying a node

Zero egress is a property of the code a node runs, so the node publishes what it runs. Every node exposes a signed attestation: a measurement over its identity, its role, the exact code commit, the loaded models with their licences, the active learned-parameter version and the twin recipe version, computed over exactly the published fields so anyone can recompute it from the response, and signed with the node's P-256 key using ES256. The verify page (explained on the attestation page) fetches a node's attestation in your browser, recomputes the measurement, checks the signature against the key the response carries, compares that key with the keys LifeCare.ID® lists for the node, and shows you the commit and models. The attestation is the node's own report of what it runs; what a pass proves and what it does not is on the attestation page.

What zero egress does not mean

Not air-gapped. A node fetches its sources, serves interpreted outputs to the person's app, and talks to the authorization server about tokens, receipts and the registry. Zero egress is a statement about raw values, not about network traffic.
Not "no cloud models anywhere". Frontier cloud models are used to develop the node's code, review it and plan it. They are never on the path that touches a person's data; the constraint is written into the engineering rules and enforced by the adapters above.
Not a policy. The properties on this page are code paths with tests pinned to them: the endpoint refusal, the allowlist, the field whitelists, the numeric-free screen and the floors. A policy can be quietly relaxed; a test fails.

Why this is the right shape for AI on health data

Models are becoming interchangeable. The thing that is not interchangeable is a person's longitudinal record and the ledger of what was recommended and what happened next. Keeping the model next to the data means the record never has to be copied to wherever the best model happens to live this year, and swapping the model is a manifest change rather than a migration of everyone's data. It also means the question "what did the AI see" has an answer a person can read: the ledger names every access, the receipt names every grant, and the attestation names the code.