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

Status: keystone + notes vault BUILT (2026-07-31); mesh / backup / sovereignty still SPEC. The build-ready design for the "family's own private cloud" layers of Cornerstone — beyond the shipped governed-AI console. The encryption keystone is now wired end-to-end into a working, demonstrable vault (see Build order §1). 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)

Family-held cold backup BUILT (2026-07-31). The first + most on-brand form: "Download backup" assembles the whole vault (sealed headers + wrapped keys + the file ciphertext blobs) into one portable cornerstone-vault-backup JSON in the browser — the family's own off-site copy, held by them, we keep no second copy. "Restore from backup" re-creates items through the normal sealed-write routes (same honest-custody guards). It's all ciphertext, so the file is safe anywhere and useless without the key. This is the sovereignty-pure default; the us-managed off-site copy below is the convenience/revenue layer on top of it.

Us-managed off-site backup BUILT (2026-07-31, migration 607) — config-gated. We hold an encrypted second copy on a separate provider (Backblaze B2 native API, no SDK dependency), so losing Supabase doesn't lose the family's data. The backend reads ciphertext only (never a key) and assembles the SAME cornerstone-vault-backup archive the client produces — one object per user in B2 — so a managed backup and a family-held one interchange. Wired: pure core (cornerstone-backup-core.ts, tested)

• B2 client (b2-client.ts) + service (cornerstone-backup.ts, backup/restore/status)
• routes /api/cornerstone/backup/{status,run,restore} + status table. Enable by setting CORNERSTONE_B2_{KEY_ID,APP_KEY,BUCKET_ID,BUCKET} env; unset → every route degrades cleanly (BACKUP_NOT_CONFIGURED) and the UI shows "not set up". ⚠️ The B2 wire is code-complete but untested without live creds — smoke-test before trust. Currently a manual "Back up now" (no cron yet, so no scheduled-task/heartbeat obligation); scheduled auto-backup + per-item incremental diff + Glacier Deep Archive tier are the follow-ons:

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

Software mesh BUILT (2026-07-31, migration 608). The honest reframe: the mesh's first nodes are the family's EXISTING devices, no dedicated box required. Each registered device keeps an encrypted local replica of the whole vault in IndexedDB (the same cornerstone-vault-backup archive — all ciphertext) and can restore the vault from it if our primary store is lost. More devices with a copy = harder to ever lose. Registry (cornerstone_mesh_device, telemetry only — no vault content) lets the family SEE their nodes; sync/restore + "your mesh" list live in the vault UI. A Cornerstone box is just a future always-on node added to the same mesh — so the mesh is no longer gated on hardware; only the dedicated-box variant below is.

• 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 — the box runs it, no cloud (partially buildable)

For the family that won't rely on us at all: the whole thing packaged to run on the box(es), no dependency on our servers. Note the framing — this is data + compute sovereignty, NOT source ownership: it ships as a closed appliance the family runs (not open source — see CORNERSTONE_DISTRIBUTION.md), and stays honest via the open crypto core + the unplug test + the network-transparency panel, not by opening the code.

• 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 BUILT + tested (2026-07-30), and WIRED into a working vault (2026-07-31): a browser-native call-site (apps/frontend/src/lib/cornerstone-crypto.ts), a persisted store (cornerstone_vault, migration 605), authed routes that only ever handle ciphertext + a golden-tested boundary that rejects any body carrying a key (cornerstone-vault-core.ts), and a demonstrable UI (/dashboard/cornerstone/vault) with a "what the server sees" ciphertext panel. This is the first end-to-end proof that "we can never read it" is a fact, not copy. Remaining: consolidate the two crypto twins into packages/shared once the box needs it, and Argon2id. Photos & documents now BUILT (2026-07-31, migration 606): files are sealed in-browser and their ciphertext stored as an opaque blob in a private Storage bucket (cornerstone-vault, service-role only), with only the sealed header in the row; download is a short-lived signed URL the client decrypts locally. The server never holds plaintext or a key for a file either. Recovery holders BUILT (2026-07-31): a vault-wide recovery-phrase flow re-wraps each item for a second holder client-side (addHolder → PATCH /vault/:id), so a single forgotten passphrase no longer loses data — still no vendor-held key (lose both and it stays closed). Per-device recovery now BUILT (2026-07-31) too: "Trust this device" adds a device:<id> holder keyed by a locally-stored secret so a shared family device (the wall) opens the vault one-tap without a passphrase — opt-in, honestly framed (device access = trusted items open; key on-device, never our server), and revocable via removeHolder.
2. Cold backup add-on — ciphertext → Glacier/B2 + manifest + restore. The next shippable, revenue-bearing layer; least box-dependent. (The seal/store/open round-trip it needs is now proven by the notes vault above.)
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.
• Derived-data constraint (honest-custody redline 4, QS 2026-07-31): the vault seals content; a plaintext server-side index / embedding / thumbnail / transcript computed FROM sealed content is a reconstructable shadow of it and is itself private content. So no server-side derived index over vault content — any future vault search must run client-side over decrypted content, or use searchable-encryption. (Compliant today: the vault stores only ciphertext + user-chosen plaintext metadata label/kind; there is no server-side content index. Keep it that way.)