Cornerstone device — hardware design

Status: DESIGNING (2026-07-31). Reference-build-first, not gated on Cicero. The software tiers of Cornerstone — the governed AI, the encrypted vault, the device mesh, and off-site backup — are built and run without any special hardware today. This doc designs the optional privacy-max tier: a small always-on device in the home that runs the family's AI locally and holds their data on hardware they own. Public page: /cornerstone/hardware.

Why a box at all (the one thing software can't do)

Everything else in Cornerstone is honest already: the vault is client-side encrypted, so we store only ciphertext; the mesh replicates ciphertext across the family's own devices. But two things still touch our servers in the software tiers:

1. The AI itself. A kid's question goes to a cloud model. Even governed, the content leaves the house.
2. Reachability. The family's devices are phones and laptops — not always on, not a stable home for the data.

The box closes both. The family's AI runs on a computer in their house, and its memory lives there — so the ordinary case (most questions, all storage) never leaves the building. That's the honest version of "you own your data," and it's the one thing no amount of client-side encryption can deliver, because the compute, not just the storage, has to move home.

This is the decide-locally model already designed in FAMILY_AI_PROVISIONING.md: the box answers what it can locally and escalates only genuinely hard asks to a frontier model — and even that escalation is a design choice the family can see and cap, not a default pipe.

What the box does

• Runs the family AI locally — a small local model + Cicero's deterministic NLU (licensed; see gates) for the decide-locally tier; frontier escalation is opt-in and visible, never automatic.
• Holds the vault — the family's photos, documents, and the kids' AI memory, on the box's own disk. On the box, the box is the client: keys are held with the family, on their hardware, not on our server.
• Is the always-on mesh node — the durable member of the device mesh (phones/laptops come and go; the box is always there), so the family's ciphertext always has a live home.
• Originates the off-site backup — pushes ciphertext to cold storage (reuses the cornerstone-backup service), so even a house fire doesn't lose the data.
• Does audio at home — local STT + local TTS, so a spoken question and its answer never round-trip to the cloud (round-tripping audio would defeat the whole point).
• Runs the packaged app offline — the sovereignty endgame: HiveJournal itself running on the box, degrading gracefully when the internet is down.

Software stack (what runs on it)

Hardware requirements

The compute target is set by the decide-locally tier, and here we get lucky: Cicero's NLU is light (~1.2 GB speech-core, deterministic, micro-wake-word — runs on x86-64 Linux or ARM64, per Matt's answers), and the heavy generative work escalates to cloud. So the box does not need a big GPU for v1 — a capable mini-PC handles the NLU + local STT/TTS + Postgres + vault + mesh. A discrete GPU/NPU is an upgrade for "more of the model runs locally," not a requirement.

Candidate builds:

• v1 reference build (now): an off-the-shelf x86-64 mini-PC (e.g., a 16–32 GB Ryzen/Intel NUC-class unit, ~1–2 TB NVMe). Cheap, commodity, dogfoggable in a real home this quarter. This is the honest first device — no manufacturing, no BOM, no waiting on anyone.
• Apple Silicon Mac mini — excellent local inference, but macOS is a poor appliance base; useful as a dev target, not the shipped box.
• ARM64 SBC (Pi 5-class) — fine for the vault + mesh + backup; too weak for the local AI tier beyond tiny models. A "storage-and-mesh-only" node, not the full box.
• Productized appliance (later): a custom or partner-manufactured unit once the reference build proves the stack. Not v1.

Photos live here, not in our cloud

A family's photo library (100s of GB–TBs) is the killer content for the vault and the reason the box exists: storing ciphertext photos in our cloud is unbounded cost and un-dedupable by construction (honest custody forbids server-side thumbnails). On the box, storage is the family's own disk, thumbnails/search run on-device over decrypted content, and off-site backup is opt-in + family-paid. So photo intake is a box capability, imported from the family's own Apple/Google export (not a fragile live platform API) — see CORNERSTONE_PHOTO_INTAKE.md.

The honest tensions (name them, don't hide them)

• Remote access is the real cloud dependency. "Everything stays home" is true on the home LAN. Reaching the box from outside the house needs a relay (a Tailscale-class tunnel, or our cloud). That's a genuine crack in the sovereignty story, and the honest answer is: the tunnel moves ciphertext/encrypted sessions only, the family can turn remote access off, and we say plainly that off-site reach trades a little of the "nothing leaves" guarantee for convenience.
• Local-model capability is capped. A box-sized local model is not GPT-class. The decide-locally/escalate split is honest about this — hard asks do leave, visibly, and the family sets the ceiling.
• BOM, cost, thermals, manufacturing, support, warranty — all real, all deferred. The reference build sidesteps every one of them: it's commodity hardware the family (or we) buy and flash.

Phased build plan

0. Dependency inventory + reference-build spec (now, software). List every hard cloud dependency (Supabase, the LLM providers, ElevenLabs, image APIs) and its local substitute (local Postgres; llama.cpp; whisper.cpp; Piper/Cicero). Pin the v1 reference-build BOM. This is the "buildable-now groundwork" from CORNERSTONE_DATA_LAYER.md.
1. Reference build, dogfooded own-family. Flash a commodity mini-PC, run the packaged app + local Postgres + vault + mesh + backup on it in a real home. Prove the stack lives off our servers. Own-family-first, same as the rest of Cornerstone.
2. Local AI: Cicero NLU + local STT/TTS. Integrate the licensed deterministic NLU + whisper.cpp + Piper once Matt's open-source suite verifies (run his suite when it lands). This is where "the AI runs at home" becomes real.
3. Productized appliance. A shippable box for families who want it out of the carton — only after 0–2 prove the software actually runs local and a real home actually wants it.

Gates (inherit Cornerstone's, plus hardware ones)

• Cicero = licensing only, never partnership/equity — the local NLU/speech substrate is a license we buy at integration, not a dependency we're entangled in. [[feedback_cicero_licensing_only]]
• Don't gate v1 on Matt's box. The reference build runs on commodity hardware today; Cicero raises the local-AI ceiling but isn't the critical path to a working device.
• Honest custody applies on the box too — including the derived-data constraint (no plaintext index over sealed content) and, since the box may touch minors' photos, the COPPA/child-safety counsel gate before any non-own-family use.
• Own-family-first. Real marketing waits until it works in one real home (ours). The hardware page validates willingness-to-pay (the existing /cornerstone waitlist already has a hardware tier) before any manufacturing spend.

First concrete step

Done → CORNERSTONE_HARDWARE_PHASE0.md — the dependency inventory (each cloud dependency → local substitute → swap effort) + the pinned reference-build BOM + the "hello box" milestone. Headline finding: only one swap is load-bearing (self-hosted Supabase); everything else is additive, droppable, or not a box concern — which is what makes a reference build realistic this quarter. Next: buy the unit, stand up self-hosted Supabase, hit the hello-box milestone (seal+open a note fully offline) in a real home.