Cornerstone — distribution: a closed appliance families run

Status: DESIGNING (2026-07-31). Decision (Sandon): the Cornerstone device and the sovereignty tier ship as a closed executable / appliance the family runs — not open source. Families get a thing they run, not a repo they read. This doc designs that, and — because it collides head-on with something we adopted today — reconciles it with the honest-custody standard's verifiability clause. Companion to CORNERSTONE_HARDWARE.md.

The tension, named (because we just adopted the thing it violates)

Honest-custody v2, adopted for Cornerstone today, added at QuickSites' redline:

the "can you read it?" answer must be verifiable without trusting us — open client, reproducible build, or third-party audit. Otherwise "math, not policy" is, from the user's seat, still just policy.

A closed binary makes "we can never read your data" something the family must trust. Left unaddressed, closed source quietly turns the whole promise back into policy. So a closed Cornerstone is only honest if it solves verifiability — and it can, without opening the product.

The resolution — why closed is still honest here

The promise rests on exactly one thing: content is sealed client-side before it's stored, with keys the user holds. If that's true, everything else being closed is irrelevant to the promise — the rest of the system only ever touches ciphertext. So we don't need to make the product verifiable; we need to make the sealing verifiable. Two independent legs, and either one alone satisfies QS's clause:

1. Open the crypto core; keep the rest closed. The client sealing (cornerstone-crypto, SealedEnvelope v1) is a small, self-contained module — standard AES-256-GCM + PBKDF2, nothing proprietary in it. Publish that one module as open + reproducibly built (third-party audited later), while the app, the data layer, the business logic, and the box image all stay closed. QS's clause says "open client," not "open everything" — and the client crypto is precisely the client. A skeptic reads ~200 lines to verify the load-bearing claim, not the whole product.

It's inspectable anyway: a web frontend ships its JS to the browser, so the client crypto is already readable in DevTools. Opening it just makes that explicit and pins it, so it can't silently change under a future build.

2. The unplug test (for the box). The box runs in the family's home and is offline-capable. The strongest verification needs no source and no technical skill: pull the network cable — it still works (the "hello box" milestone). A device that functions with the internet physically disconnected cannot be exfiltrating anything. For a non-technical family, "unplug it and it still works" is more convincing than reading source — it's verification by physics, not by trust.

Together: the software tiers are verifiable via the open crypto core; the box is verifiable via the unplug test. Closed product, honest promise, intact — and this is now a requirement of the distribution, not a nice-to-have.

The network-transparency panel — verification you can watch (Sandon, 2026-07-31)

The unplug test is one-time and passive. The stronger, ongoing answer: show the family, in a UI on the box, every port it has open and every connection it's making — live, and with history. This is the active version of "verify without trusting us," and it's legible to a non-technical family in a way source never is.

What it shows (a panel on the Family Wall / dashboard, reading the box's own network state):

Open ports — what's listening, and which service owns each (the app, self-hosted Supabase, the mesh sync daemon, the remote tunnel only if you turned it on).
Live connections, grouped and labeled in plain language:
- Inbound, on your network: "Kitchen iPad", "Mom's phone" — your own devices reaching the box.
- Outbound, to the cloud — each one named: "Off-site backup (encrypted)", "AI escalation — a hard question you asked went to the cloud", "Update check", "Remote access (you enabled this)".
When + what — a history: not just the current state but a log, so a family can see "the box talked to the backup service at 2am, sent ciphertext, and talked to nothing else all day."

How it's built: on the box (Linux), enumerate sockets (/proc/net, ss) and map each to its owning process; resolve outbound destinations to a labeled purpose (the box's own services have known endpoints — Supabase is local, B2 is backup, OpenAI/Anthropic is escalation, the update server is updates); surface it in the UI, with a rolling history.

Why it's the keystone of the closed-box honesty story: it turns "trust us, we only connect where we say" into "here is every connection, watch it yourself." A family can see that when they asked the AI nothing hard, nothing went out — and that the only cloud connections are the handful we named. If the box ever reached somewhere unexpected, it would be on the screen.

And it sets a hard design constraint on the whole box: every connection it makes must be nameable in plain language for a family. If we can't label it, we don't make it. The panel enforces "no undeclared phone-homes, ever" by making any such call visible the moment it happens. That constraint is arguably worth more than the panel itself.

What "closed source" actually means for this stack (no false promises)

The frontend can't be hidden. A web app ships JS to the browser; anyone with DevTools reads it. That's fine — and it's how the crypto stays inspectable. "Closed source" here protects the backend, the business logic, and the appliance image — never the browser client, and we won't pretend otherwise.
Node/JS doesn't compile to opaque machine code. A Node SEA or bun build --compile single binary embeds the JS (extractable); a private container registry ships readable layers. None of these are true obfuscation. The realistic artifact for the box is a signed appliance OS image — you flash it, you don't read it — but its protection is distribution + licensing + being far more work to reassemble than to read a file, not a magic unreadable binary.
So the product is protected the ordinary way — license, distribution, a moving target — and we never say "your data is safe because it's compiled." That would be the dishonest version of this whole idea.

The distribution

The box: a signed appliance image the family flashes (or gets pre-flashed) — packaged app + self-hosted Supabase + local model runtime as prebuilt binaries. Source not distributed.
Licensing: a per-family license (the box is a purchase). Signed images; an update channel that verifies signatures.
Updates: family-pulled, never pushed. The family pulls updates when they want them — signed, verified against our key, applied on their say-so. We never push, never force, never auto-update behind their back. Sovereignty means they can stay on a version forever, offline, and the update check itself is one of the labeled connections in the transparency panel — so even "checking for an update" is something they can see us do, not a silent background call.
The open crypto core ships as a separate, public, versioned artifact the closed app depends on — so "verify the sealing" always points at something public and pinned.

Reconcile the "sovereignty" language

The sovereignty tier meant data + compute sovereignty (nothing leaves your house), not source ownership. "Even the software becomes yours" overreaches for a closed appliance and is now corrected across the surfaces to: the whole thing runs on your box, not our cloud. You own the box, the data, and the ability to run it offline forever; you don't own the source, and we say so plainly.

Gates

Verifiability is a requirement, not optional: ship the open crypto core, and make the box pass the unplug test — that's the price of shipping closed while keeping the honest- custody promise honest.
Never claim an "unreadable binary" or "safe because compiled." The honest claims are: the sealing is open and verifiable; the box works offline; the keys are yours.
Honest-custody's other gates still apply on the box (derived-data constraint; COPPA/counsel for non-own-family minors).