Trust document · published before code, kept exact after

What we can see. What we can't. Stated exactly.

Vantell's entire value is trust. For a product like that, one discovered overstatement costs more than ten admitted limitations — so this page says precisely what is true, qualifiers included, and nothing more.

The claim, in two sentences

Your private notes cannot reach us, because the software that could send them doesn't run on our servers. Your shared export we can technically read — it is encrypted with keys we manage, and our workers decrypt it to answer questions on your behalf. Here is precisely how we constrain, monitor, and audit that access.

Two sentences, two different guarantees — and we will never collapse the second into the first.

• The first sentence is architectural impossibility. The component with access to your full vault runs on your machine and has no network. It cannot send your private notes anywhere, ours included.
• The second is controlled capability. Real isolation, real controls — but a policy guarantee, not a physical one. "We cannot read anything" would be an overstatement, and we don't make it. An unqualified "cannot" for the shared export would require confidential-computing execution (trusted enclaves for our workers) — a legitimate roadmap item, not a launch promise.

What never reaches our servers

The software you install locally is two strictly separated components — separate processes, separate OS users:

• The publisher is the only code with access to your vault, and it has zero network. No API calls, no uploads, nothing — even its search indices are built with a local embedding model. It classifies your notes, strips everything hidden or private, and writes only the notes you marked shareable into a local export directory.
• The courier is the only local code with network access, and it can read only that export directory. It has no handle to your vault — not "declines to open it": cannot open it.

Your private notes never reach our servers, because the software that could send them doesn't run on them — and the software that runs on your machine with network access can't read them either.

Private is doing real work in that sentence. The shared export — the notes you deliberately marked shareable — does reach our servers, and our workers can read it; that is what the second sentence of the claim above is about. Everything else stays home. On a real, intensively used vault, the shareable layer measured 475 notes out of 187,412 files — we see a quarter of one percent of that brain, and nothing else.

Some exclusions hold no matter what you configure: raw captured material (email, transcripts, chat exports — mostly other people's data, whose subjects never consented) and notes about individuals can never be marked shareable. There is no switch. Not opt-out — the switch does not exist.

What we can technically read — and how it's constrained

• Scope: only your shared export and the indices built from it. Encrypted at rest under a per-person key; our membrane workers decrypt it to synthesize answers on your behalf, under your policy, at the disclosure level you set.
• Isolation: storage is namespaced per person — isolation is a connection-level fact, not a WHERE clause. Every data access path structurally requires a tenant scope.
• Egress: answers leave only as syntheses (or, for notes you explicitly opted into raw sharing, the note itself), after deterministic leak gates the writing model cannot influence.
• Audit: every question asked of your brain, who asked, at what level, and what was decided lands in your audit log — visible to you, forever. Silent access is the thing this architecture is built to make impossible to hide.

Your org admin sees even less

In Vantell, the tenant is the person. Your organization is a federation domain your personal tenant is bound to — it handles billing, membership, and a policy floor (ceilings on disclosure, never overrides upward). This inverts what every B2B tool does, deliberately:

What org admins can never see:

• Members' notes
• Members' answers
• Members' audit logs
• Members' policies
• Any content at all

Not policy. Architecture — there is no API for it. Admins see metadata: query volumes, response rates, topic coverage. If a metric could rank employees, it doesn't exist.

You see everything

Radical transparency runs toward the owner, not the platform. Your audit log shows every question ever asked of your brain, by whom, for what stated purpose, at what level, and what was answered or refused — with a signed consent receipt for every grant. Only you can see it, and you can export it: it's your data.

Leaving

Deleting your account destroys your export copy, indices, keys, and audit log by deleting the per-person encryption key that protects them — unrecoverable, immediate, and propagated into backups within a stated window. Contributions you explicitly consented to keep in org-owned notes exist without your name; you can withdraw those too.

Honest limits

• A synthesized summary of a secret is still a secret. Conservative defaults, mechanical leak gates, and the audit log make leakage rare, visible, and attributable — not theoretically impossible. We say so up front.
• The relay routes ciphertext it cannot read, but metadata — who asked whom, when — exists and is itself sensitive. We treat it that way.
• For cloud-native knowledge tools with no local vault, classification must run server-side — a weaker guarantee than the local publisher, and any such tier will be labeled and priced as exactly that. The weakest connector never gets to define the claim for the whole product.

Questions this page doesn't answer belong in it. Tell us: hello@vantell.ai.