The private architecture.

01Ingestion and extraction

A document is read on your device before it's sent anywhere — turning the bytes of a PDF or a photographed page into words is done there, using Apple's own PDFKit and Vision frameworks, the same recognition Notes and Files use. That's what makes sealing the file meaningful rather than cosmetic: the server never has an unsealed copy to read in the first place, not even briefly. The extracted text joins the canonical store alongside metadata Neeos derives — document kind, vendor, dates, amounts, expiries. Notes written in Neeos are already text and skip straight to indexing. On the Mac, watched folders sync on a ten-minute cycle, skipping anything already ingested.

02The index — local by construction

The semantic index is built by all-MiniLM-L6-v2, a sentence-embedding model producing 384-dimension vectors. The load-bearing fact is not the model choice — it's where it runs: the weights ship inside the app itself, and embedding happens on your device, not on a server. There is no embedding API call to any third party and no server-side computation either — indexing your material cannot leak it, because the text never leaves the device to become searchable in the first place.

• Text is chunked in overlapping windows, so a fact straddling a boundary still lands in at least one chunk whole.
• Indexing runs automatically on every save; a background sweep catches anything missed.
• Your queries take the same path: the question you type is embedded by the same on-device model, and the similarity search that matches it against your index runs there too — chosen over the earlier server-side search because it measured more accurate, not only because it's more private. The question itself is never sent anywhere to be matched against your library.

Every row in the production index was produced by this on-device model — verified against the running system, not assumed from the code.

03Answering — what leaves, enumerated

Producing prose from retrieved passages requires a frontier language model, and that call goes to Anthropic. The payload is exactly:

• your question,
• the conversation you are having,
• the specific passages retrieved for that question, and
• anything you deliberately attached — a file on the message, or documents attached to the project you're working in.

Not your library. Not your index. Not your vault. The retrieval step is what makes this scoping possible: because search happens locally first, the language model only ever sees the handful of passages that matter for one answer.

Chat is not local. We state it plainly because the rest of the pipeline is local enough that people assume the last step is too. It isn't, and a page like this one is worthless if it blurs that.

Dictation, spoken replies, live voice conversations, and image generation are handled by OpenAI — only when you use those features, and only the audio, text, or prompt involved. We make no claims here about what Anthropic or OpenAI do with API traffic; those are their commitments to make, in their terms. What Neeos does is ours to state: we train nothing, sell nothing, and share nothing.

04Tenancy

Neeos is multi-tenant. Accounts share infrastructure — not a private database, not a private server — but the boundary between them isn't left to one mechanism to get right. Every request is bound to your account before it can touch any data; the application code checks that same boundary again at 459 separate points across the codebase; and underneath both of those, the database itself refuses — as a rule it enforces on every single query, independent of anything the code above it does — to hand back a row that doesn't belong to the account asking. If the first two layers ever miss a case, the third one still holds: a forgotten check returns nothing, not someone else's data.

That protection is also hardened against a failure mode most systems don't guard against at all: normally, a routine infrastructure update run for a completely unrelated reason could silently revert the database connection to a role that isn't subject to this rule — no error, nothing visibly different, isolation just quietly off. Neeos's infrastructure configuration now explicitly protects against that specific accident, and a background check at startup raises a loud, named alarm if isolation is ever found off when it shouldn't be.

Not every table has this protection yet. A small number — including local file tracking and document edit history — don't carry it today, and closing that is active, tracked work, not a quiet gap. It is not a per-customer instance, and we won't describe it as one; "your own instance" is the kind of phrase that gets stretched, and this page exists to not stretch things.

05Encryption, and its honest limits

Your notes, documents, messages, and health data are locked on your device — before they're sent to us, not sometime after — under a key generated on that device and never assigned or seen by our servers. That key is protected two different ways at once: your phone or Mac's own dedicated security hardware (the Secure Enclave — the same chip that holds your Face ID data and Apple Pay credentials) hardens it locally, and a separate, encrypted copy syncs privately between your own devices through your iCloud Keychain, so signing in on a second device never has to trust our servers with anything. If you ever need it without any of your devices, a recovery key — shown to you once, generated with far more randomness than any password a person would choose — is the only other way in.

We considered building this the more common way, where a server holds your key for just the moment it needs it to answer a request, and rejected that design by name: even a moment is a moment a compromised server could use. The code that would have to exist to unlock your data from our side isn't disabled, isn't hidden behind a permission check — it was never written. There is nothing in our servers with a way to open what your device locked.

When you ask the AI something, our server reads your question in order to answer it — that's true of any AI assistant, not a Neeos-specific gap. What it doesn't do is keep a readable copy afterward. Once your question and the assistant's reply have done their job, they're sealed on your device — locked with the very same key that protects everything else in your account, not a separate or weaker one. Sealing happens shortly after you receive a reply, not the same instant: your device needs a moment to check in and do the locking itself, so there's a brief window, normally seconds, where a reply exists in a form our server could technically read, until that happens.

• At rest: content is sealed on your device, under a key we never receive, before it reaches storage; infrastructure-level encryption with a customer-managed key covers the database and document storage underneath that.
• In transit: TLS is enforced on every connection — client to API, service to database.
• The AI, scoped: a request to the model carries only what's relevant to the conversation you started — never your library, never your index, never your account as a whole.
• Storage posture: document storage has all public access blocked, with versioning on.

What we can't lock down: the credentials that let us pull in data from services you've connected — Google, WHOOP, and the like — because we have to refresh them on a schedule with no device present to hold a key. And we don't collect your location at all: weather is estimated from your device's time zone, not from GPS or any coordinate.

What this is still not: a guarantee that it is impossible for Neeos to ever see your data. We write the app you run, and a differently-built version could behave differently — that is true of any provider, including the most private ones. What we can say, and mean precisely, is narrower and real: we do not have your key.

06What this actually protects against

Not an abstract promise — the specific things this design stops, and how:

• Someone with access to our database — an employee, a breach, a subpoenaed backup — finds locked data they have no key to open. Not redacted, not restricted by permission: unreadable, the same as it would be to anyone else without your key.
• Someone with access to our file storage sees the same thing: content locked before it ever reached us.
• Another Neeos customer can't see your data by accident or by bug. That isn't one filter that has to work correctly every time — it's three independent ones, and the last is enforced by the database itself, not by trusting our code got it right.
• A developer who makes a mistake and forgets to scope a query to one account doesn't leak the wrong account's data — the database refuses to return it at all.

What none of this claims: that it's impossible for Neeos to ever see your data, or that a stolen login session is harmless, or that a device already unlocked in someone else's hands is protected. Those are named honestly above and below — this section is what the design is actually for, stated as precisely as the rest of this page tries to state everything else.

07Deletion and retention

• Incognito chats have no access to your data and no memory. The conversation — messages, attachments, and the conversation record itself — is deleted outright when you leave it, and automatically within a day if you don't. Verified as real row deletion, not a hidden flag.
• Vault trash and deleted chats hold a 30-day recovery window, then purge.
• Account deletion is available from inside the app and removes your content.

08What this architecture is not

The claims we could make and don't, in one place:

• Not "zero-knowledge" in the absolute sense some products claim — we don't say it's impossible for us to ever see your data, only that we don't have the key today. See "Encryption, and its honest limits" above for the precise boundary.
• Not on-device chat. Answering requires a frontier model, and that call leaves.
• Not HIPAA, SOC 2, or GDPR certified. None of those audits have been done yet.
• Not self-hosted and not per-customer instances — see "Tenancy" above.
• No web client. The apps are native, and the only surfaces.