Cornerstone data layer — vault, device mesh, encrypted backup, sovereignty

Status: SPEC / not built (2026-07-30). The build-ready design for the "family's own private cloud" layers of Cornerstone — beyond the shipped governed-AI console. Bound by the mesh honest-custody standard: if we can read the user's private data, "you own it" is a lie.

This doc is the "when we build it, here's the design" artifact. Some layers are buildable in software today; some are gated on the Cicero (Matt) home box — licensing only. Each layer says which.

The layered model

Nothing in scope is honest without the encryption keystone below, so that's the piece to build first — every other layer moves ciphertext.

The encryption keystone (build this first)

Pure core BUILT + tested 2026-07-30 — cornerstone-crypto.ts (+ security tests 8/8): sealEnvelope/openEnvelope (AES-256-GCM content + PBKDF2 KEK), multi-holder wraps + addHolder (the recovery model), WrongKeyError/TamperError. It's a standalone library, not yet wired — no store, no client UI, no route (correctly: it's client-side). Remaining: relocate to packages/shared, build the client/box call-site, upgrade the KDF PBKDF2 → Argon2id (the envelope kdf block is versioned for it), and add real recovery holders (recovery phrase / second-device key).

The property that makes all of it true: we store ciphertext; only the family holds the key. Concrete design:

• Envelope encryption, per item. Each file/record gets a fresh random content key (DEK); the DEK is wrapped by a family master key (KEK). Only wrapped DEKs
  • ciphertext are ever stored on our side or in cold storage.
• The KEK is derived on the user's device, never transmitted — from a family passphrase (Argon2id) and/or a hardware key on the Cornerstone box. We never see a plaintext KEK, and there is no vendor-escrow copy (a backdoor key fails the standard, full stop).
• Encrypt/decrypt happen at the edge the user controls — the box, or the client device. Our servers and the storage vendor only ever handle sealed bytes.
• Recovery is user-controlled: a user-held recovery phrase, or a second key on another of the family's own devices (the second mesh box), or chosen-guardian social recovery. Lost key = lost data, stated plainly in the copy — the honest cost of real ownership (if we could rescue it, we could read it).

Verification bar: an engineer with prod access + the storage vendor's cooperation cannot produce plaintext. The reason must be architectural (no key exists on our side), not a policy.

Cold backup — the add-on (most buildable)

The paid add-on, and the layer least dependent on the box:

1. The client/box encrypts each item (keystone above), chunks large blobs.
2. Ships ciphertext only to cold storage — S3 Glacier Deep Archive (cheapest; ~hours to restore, fine for a backup) or Backblaze B2 (faster/cheaper egress).
3. Stores a small manifest (also encrypted) mapping items → object keys, so a restore is: fetch manifest → fetch objects → decrypt on-device.
4. Restore is deliberately a "cold" path (rare, patient) — matches Glacier's retrieval model and keeps storage cost near zero for the common case (never needing it).

Economics: cold storage is cents/GB/month, so this is a healthy add-on margin with obvious value (fire, theft, both boxes lost). Billing rides the existing Stripe rail (Family Wall Plus tier or a metered add-on).

Device mesh — fault tolerance without the cloud (gated on the box)

• 2+ Cornerstone boxes on the family's account form a mesh; each holds a full (or quorum) copy of the family's ciphertext, so a single device failure loses nothing.
• Geo-distribution — one box at home, one at a grandparent's — turns the mesh into off-site resilience and seeds the Cairn/legacy thread (a relative's box already holds the family's story).
• Replication moves sealed bytes only (the keystone holds across the mesh); a new box joins by being handed a key on-device by an existing family device, never by us.
• Open design Qs: copy-count/quorum policy; conflict resolution for concurrent edits; discovery/transport between boxes (LAN + relay). All gated on real hardware to design against.

Sovereignty tier — self-hostable HiveJournal (partially buildable)

For the family that won't rely on us at all: a self-contained build of HiveJournal that runs on the box(es), no dependency on our servers.

• Buildable-now groundwork: this is the far end of the existing platform-independence thread. The honest first step is an inventory of hard cloud dependencies (Supabase, the LLM providers, ElevenLabs, image APIs) and which have local substitutes (a local Postgres; a local model for the "decide-locally" tier — this is exactly where Matt's local NLU fits; local TTS for the box path).
• Gated: a true offline build needs the local model/TTS substrates + the box. The AI degrades gracefully offline (decide-locally handles most; cloud-escalation simply unavailable) rather than breaking.

Build order

1. Encryption keystone — the client-side envelope-encryption layer + key derivation + recovery pure core BUILT + tested (2026-07-30); remaining is relocation to shared + the client/box call-site + Argon2id + real recovery holders. Pairs with ratifying the honest-custody standard.
2. Cold backup add-on — ciphertext → Glacier/B2 + manifest + restore. The first shippable, revenue-bearing layer; least box-dependent.
3. Device mesh — on real Cicero hardware.
4. Sovereignty — dependency inventory now; full offline build with the local substrates later.

Gates (unchanged)

• Cicero = licensing only, never partnership/equity (layers hot/resilient).
• COPPA/counsel before opening the vault (esp. minors' photos) to families beyond the owner's own; own-family use is not third-party-gated.
• Honest-custody standard ratified before shipping any "your data is safe" copy on these layers.