Abstract

A non-custodial, ephemeral compute architecture enables privacy-preserving analysis of personal data by an operator that, by construction and not by policy, contract, or trust, holds no persistent key material capable of decrypting the data it processes. The architecture lets an application separate two kinds of personal data that are usually conflated. Contact data is the identifying and reach information an application legitimately needs to hold (name, email, account and billing identifiers: who someone is and how to reach them). Confided data is the substantive information a person reveals about themselves: their body, mind, behavior, and life. The architecture processes the confided kind without ever storing it or being able to decrypt it at rest. Regulated categories such as health, biometric, reproductive, mental-health, and behavioral data are important instances of confided data, but the architecture is not limited to them. The architecture combines four separable elements:

  1. a bidirectional, per-invocation hybrid post-quantum key agreement bound to the lifecycle of an ephemeral compute instance;

  2. a non-custodial compute fabric in which a deliberately "dumb" coordination layer holds only ciphertext, public keys, and content-free status codes, and the only components that ever process plaintext are the end-user device and a short-lived ephemeral worker;

  3. a deterministic-middle inference pipeline that structurally prevents a learned model (LLM) from authoring numeric values or unvalidated findings in the output;

  4. a realization-neutral compartment model whose invariants are testable by parties other than the operator.

The architecture runs today on commodity cloud infrastructure without specialized silicon, hardware attestation, or cryptographic-protocol overhead on every operation. It is presented in layers, marked throughout as built, designed-in, or forward-looking. The invariant engine flow (the key agreement, the ephemeral-worker rendezvous, and the non-custodial trust boundary) is built and in production, as is an already-multi-application platform and API atop it. On that engine, the first computation flow (the analysis run on the decrypted data) is complete and in production, and the worker model is a general-purpose compute host designed to carry additional computation flows, so extending the system is adding a flow to an existing foundation rather than rebuilding it. A managed-service generalization for independent third-party integrators is described as a forward-looking extension. Both what is built and what is designed are disclosed, so the full design is in the public record without overstating what is shipped.

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 License.

Download

Share

COinS