What this page is
This page is the operational spec for the Penumbral privacy spine. It keeps the legal and policy argument on a separate page and focuses on how that argument translates into concrete requirements on encryption, logging, retention, and system design.
If you want the full Shield and Privacy Vacuum narrative, read the legal strategy brief first. When you are ready to turn that narrative into implementation work, come back here and use this page as a checklist.
The companion page is the Penumbral privacy spine — legal strategy brief, which sets out the “why” in more detail. This page is the “how”: it expresses those commitments as requirements a system, infra, or product team can actually build against.
Operationalizing the silence: spec vs. synthesis (v2)
The table below pairs a concise, implementation-facing view of the privacy spine with a counsel-facing synthesis. The left column can be read as a sketch of the operational spec; the right column translates each control back into the Shield and Vacuum idiom.
| Column A — Operational spec (v2 lineage) | Column B — Shield & Vacuum synthesis (v3) |
|---|---|
|
Client-side key generation
Encryption keys are generated and held at the client edge. The service only ever sees ciphertext and cannot decrypt user payloads, even if compelled by a third party. |
Shield: keys stay with the mind that thinks
Placing keys at the edge makes the context window function like a locked diary. The provider can courier the sealed envelope, but it cannot open it. That turns the technical design into a structural barrier against compelled insight into a user’s private reasoning. |
|
Sovereign state management
The canonical state of a session lives on the user side or in a strictly encrypted, non-derivable store. Server infrastructure treats that state as an opaque blob. |
Shield: the canonical record lives in the user’s world
If the only legible copy of a conversation is the one the user chooses to keep, then system operators never become the authoritative historians of intimate facts. That keeps the primary ‘zone of truth’ inside the user’s control, not the platform’s racks. |
|
Transient, stateless inference
Inference runs in a stateless mode: once a response is produced and delivered, the intermediate activations and request bodies are discarded rather than pooled for future training. |
Vacuum: thoughts that are consumed and not stored
When the system treats context as fuel that is burned and gone, it behaves more like a conversation in a closed room than a permanent deposition. The vacuum is not metaphorical; it is implemented as the absence of lingering copies. |
|
Aggressive TTL on operational logs
Operational logs used for reliability, abuse monitoring, or billing are kept only for a short, predetermined window before being systematically purged. |
Vacuum: the floor clears itself
Short log lifetimes mean that even where the system must briefly remember that something happened, it quickly forgets the details. That narrows the window in which sensitive context can be replayed, subpoenaed, or repurposed. |
|
Metadata minimization
Only coarse metadata about events is retained where strictly necessary for security or billing. Semantic content is stripped at the boundary. |
Vacuum: traces without transcripts
Logging that ‘an interaction occurred’ without preserving what was said preserves operational accountability without turning conversations into evergreen dossiers. The system remembers enough to function, but not enough to become an evidentiary archive. |
Limitations and hand-off to real matters
This composite brief is demonstrative scaffolding, not formal legal advice. It simplifies doctrine and omits jurisdiction-specific constraints. Any deployment of these ideas in a live product, contract, or policy must be reviewed and adapted by licensed counsel with knowledge of the relevant facts and law.
Nothing in this page creates rights, obligations, or warranties. It is intended to help lawyers and product teams speak a shared language about the Shield and the Privacy Vacuum, and to show that the architecture can be aligned with that language when properly specified.