How Haven is built.

A privacy product where the architecture is the promise.

Haven is a native desktop application — a Rust workspace wrapped in a Tauri shell with a React dashboard — that connects to your email, cloud storage, and local files, scans them on your own machine, and walks you through cleaning up what it finds. Detection runs in three escalating tiers, two of which never touch the network. The few bytes that do leave are bounded, logged on-device before they're sent, and verifiable by anyone with a packet sniffer. Three features — Trace, Settle and Prepare — go further and assemble a signed document you can hand to someone else, still without uploading the mail it was built from.

Five surfaces, one trust boundary.

The whole product is five deployable surfaces. One of them — the desktop agent — holds all user content. The other four are deliberately designed so they couldn't hold it: a static marketing site, a static artifact CDN, a counters-only backoffice, and two GPU services that process bounded payloads in memory and forget them.

• Desktop agent — the product. Everything sensitive happens here: scanning, classification, the encrypted findings store, remediation, undo.
• Signed artifact CDN — three static nginx channels that only ever send: detection rules, ML model bytes, and update manifests, each Ed25519-signed before it leaves CI.
• Tier 3 inference — Haven-controlled GPU running an open-weights model behind an OpenAI-compatible API. Receives bounded excerpts, returns verdicts, retains nothing.
• Image safety — a second, Haven-owned GPU for the explicit-photo detector (on by default; turn it off per connector), built specifically so users' intimate photos are never processed by a third party.
• Backoffice — the operations plane. Accepts aggregate telemetry counters, tester feedback, and scrubbed error reports; serves the team an OTP-gated dashboard.

Boring where it should be, sharp where it counts.

The agent is systems software — Rust end to end, with ML inference embedded in-process. The supporting services are deliberately minimal: static file serving, one small Node app, and two GPU boxes running open-weights models Haven controls outright.

Three tiers. Two never touch the network.

Every message, file, and attachment flows through an escalating pipeline. Tier 1 is deterministic pattern matching. Tier 2 is a transformer running inside the app process. Only when both of those are genuinely uncertain — a low single-digit percentage of items — does a bounded excerpt cross the trust boundary to Tier 3 for a second opinion.

What leaves the device — exactly, and nothing else.

Most privacy products ask you to trust a policy. Haven's claim is structural: there is exactly one code path that can reach the network, it only accepts a fixed list of payload shapes, and it writes every outbound request to an on-device log before the bytes leave. A continuous CI lint fails the build if any other crate so much as links an HTTP client.

One chokepoint, enforced by the compiler and CI

Three features that end in a document, not a dashboard.

Most of Haven ends in a finding you can act on. Trace, Settle and Prepare end in something you can hand to a person — a lawyer, an executor, a claims adjuster, whoever opens your affairs after you. All three ride the same connectors, the same egress chokepoint and the same export path: a folder containing a Word document, a signed manifest of everything that went into it, and the files the messages carried.

What a model is shown — and what it isn't

No message is adjudicated by a model. The mail is read on your device; the only things that ever cross are a description of who wrote and, at export, the finished register. Concretely, classification sees the sender's name and address, the message count, up to five subject lines, and the closing lines of up to two messages. Summaries see the register and nothing else. Both are run through the scrubber first.

• No new payload shape. These calls ride the existing Tier 3 variant under class slugs — investigate:*, settle:classify:<domain>, settle:summary. Adding a record feature adds a slug, never a destination.
• Logged call by call. Every one lands in the on-device Network Activity log with the institution's domain on the row, written before the bytes leave.
• The document says so too. The record's Method & Provenance section states exactly what the model saw, in the same words as this page. If that ever changes, the document changes with it.
• Prose is gated. A generated summary is withheld if it names a figure that isn't in the register, asserts a status, gives advice, or clips an institution's name — and the record lists the withholding under known gaps. Stored summaries are re-checked on every re-export.

The folder, and the two signatures

Export writes a folder — never into an existing one; it takes -2, -3 — holding the .docx, a .manifest.json, a plain-text note explaining what the manifest is for whoever opens it, and an attachments/ directory. The document is rendered with fixed zip timestamps so its bytes stay deterministic: the same record, exported twice, still matches its manifest.

• Signature one covers the per-exhibit digests — "did Haven, on this device, assemble these exact messages?" It has to be computable before the document exists, because it is printed into the document.
• Signature two covers the finished document's hash, bound to the manifest's own identity — "is this .docx the one produced from them, unmodified since?" A hash nobody signed would be evidence of nothing, and a document signature can't be transplanted between manifests.
• Self-signed, and it says so. The Ed25519 key is generated on your machine and never held by Haven, so the public key travels in the manifest. That makes this evidence of integrity, not third-party attestation — the same weight as any document a person signs themselves. The record states that plainly rather than leaving a recipient to work it out.
• The scope statement says what was not searched. A record that silently omits a connected-but-excluded account is worse than no record at all.

Where it all actually runs.

Five pieces of hardware, each with one job. The interesting choice: both GPU services run open-weights models on machines Haven controls — no third-party AI API ever sees user content, and the explicit-photo detector got its own dedicated box precisely because that content deserves the strongest possible custody.

Everything that changes the agent is signed.

Detection rules, ML models, and the application itself all ship through independent channels — and the agent refuses anything whose Ed25519 signature doesn't verify against keys compiled into the binary. A compromised CDN can't hurt users: a bad signature means the agent silently keeps what it has.

• App updates — the agent checks a signed manifest, downloads only when the SHA-256 matches, and respects a staged rollout percentage so a bad release reaches 5% of the fleet, not 100%.
• Rules packs — new detectors ship weekly without an app release. The pack carries its own minimum-agent-version gate, so old agents never load rules they can't run.
• Model bundles — Tier 2 classifier upgrades arrive the same way: signed manifest, per-file hashes, atomic activation, prior version kept for rollback.
• Everything is opt-out-able — update checking is a user preference, and the Network Activity log shows every check the agent makes.

Eight kinds of sources, one encrypted store.

Each connector is its own Rust crate speaking the provider's native protocol — OAuth 2.0 with PKCE for the cloud sources, IMAP with an app password for Yahoo and AOL, direct database reads for iMessage, plain file I/O for local folders. Tokens live in the OS keychain. Sync is incremental, so after the first deep scan Haven only reads what's new.

The local store

Everything Haven learns lands in a single SQLCipher-encrypted SQLite database on the user's disk. The 32-byte key is generated on first launch and held in the OS keychain — Haven's servers couldn't read the store even with a copy of the file.

• Findings & verdicts — what was found, where, and every action taken, with the 30-day undo trail.
• The Network Activity log — the on-device record of every byte that ever left, kept in the same transaction as the send itself.
• Signed artifacts — the active rules pack, model manifests, and update manifests, stored as the exact signed bytes that were verified.
• Schema discipline — 29 additive migrations and counting; upgrades never rewrite or expose prior data.

An ops plane that can't see your data.

The backoffice exists so a small team can run an alpha fleet: watch aggregate health, read tester feedback, issue invites, and stage releases. Its most important property is what it doesn't receive — the telemetry schema is a fixed vocabulary of counter slugs, so message content is not just unsent, it's unrepresentable.

What the team can actually do

• Fleet dashboard — daily aggregate charts: scans run, findings by severity band, remediation counts, version adoption. Counters, not content.
• Alpha lifecycle — invite by email, issue license keys and download tokens, and remotely pause a license (the kill-switch): a paused agent's writes are refused fleet-wide.
• Release intake — CI uploads each signed installer; the backoffice keeps the latest plus recent versions per OS for the download links and the update channel.
• Feedback inbox — every in-app "send feedback" lands here, already scrubbed on the client before it was sent.