The private architecture.

01Ingestion and extraction

A document's text is read on your device — turning the bytes of a PDF or a photo into words is done there, using Apple's own PDFKit and Vision frameworks, the same recognition Notes and Files use. The file and its text are then sealed on your device before they are uploaded, so what we store is locked. One honest gap: a scanned PDF has no text layer, and the iPhone and iPad apps do not yet read one, so a scan added from a phone is stored but is not searchable by its contents.

Suggesting a document's title, kind, vendor, date, amount and expiry for you to confirm is local too, on an encrypted account: our server refuses to read an encrypted account's file for that, and the next app build makes the suggestions on the device, with Vision, PDFKit and Apple's on-device model. The build in the beta today makes no suggestion on an encrypted account — you name the file yourself. Two cases still reach a model: an account that has not set up encryption (its file's text goes to GPT-5.6 Luna, a photo to Claude Sonnet), and the assistant itself, mid-conversation, pulling details out of text or an image it has already been given in that chat. Notes written in Neeos are already text and skip straight to indexing. On the Mac (the app is coming), 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 while the app is open — when you open it or come back to it, or from Settings. It is resumable rather than backgrounded: the work left to do is derived from which chunks are missing, so closing Neeos mid-index loses nothing and repeats nothing — it continues next time you open it. A first index of a large library wants a few minutes of the app being open, once.
• Your queries take the same path: the question you type is embedded by the same on-device model, and the search that matches it against your index — by meaning, alongside plain keyword matching — runs there too, chosen over the earlier server-side search because it measured more accurate, not only because it's more private. Our server does receive your question, because it is the message you are sending; it does not search your records with it.

Every new entry in the index is made by this on-device model: the server has no code path that writes one, and a test fails if one is added. Entries made before the index moved to the device, in August 2026, were converted to the sealed format rather than rebuilt.

03Answering — what leaves, enumerated

Producing prose from retrieved passages requires a frontier language model. By default that call goes to OpenAI (GPT-5.6 Luna). Anthropic's Claude handles some other tasks: picking out facts worth remembering from what you say in a conversation, and reading an image when the assistant is asked to pull details out of a photo you shared in the chat. Each message carries:

• your question,
• the recent conversation,
• a short profile of durable facts about you, and the standing instructions of the project you're working in,
• 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.

While answering, the assistant can also look something up when the question needs it — a note or document, your tasks and goals, an earlier conversation, or the web (through OpenAI's hosted search). Each lookup sends what it returns, and nothing more.

Never your whole library, your index, or your vault. The retrieval step is what makes this scoping possible: because search happens locally first, the language model sees the passages that matter for one answer, not the corpus.

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 with anyone for their own purposes.

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 several hundred 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 check at startup logs a loud, named error if isolation is ever found off when it shouldn't be.

Not every table has this protection. A few don't carry it: the account and sign-in tables, billing and usage records — by design, and each exemption is written down with its reason — and the table of sharing links, which is 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 and documents are locked on your device — before they're sent to us, not sometime after — and your chat history is locked on your device shortly after each reply (below). All of it 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 tablet'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 the key that unlocks it syncs privately between your own devices through your iCloud Keychain, while our servers hold only a locked copy they cannot open — 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, 140 bits of randomness, far more 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 window — normally seconds, longer if your device goes offline or the app closes first — where a reply is stored in a form our server could technically read, until that happens.

What is not locked on your device, in one place:

• Voice — a recording nobody can open cannot be turned into words, so speech is never locked. Dictation, spoken replies and classic calls go through our server as audio and text. Live calls, the default on iPhone, stream your voice from your phone straight to OpenAI, which turns it into words; only those words, and the text of Neeos's answer, pass through our server.
• Files you attach to a chat, and files Neeos makes for you (a generated image or PDF) — stored under our storage encryption, not under your key. Moving chat attachments under your key is built and not yet in the beta.
• Files uploaded before your account finished encryption setup, which stay as they were uploaded, under storage encryption. The next app build adds a way to re-seal them under your key, from Settings.
• Account basics and structure — your email and name, ids, dates, which module a thing belongs to — which the service needs in order to run.

• At rest: content is sealed on your device, under a key we never receive, before it reaches storage, with the exceptions listed above; infrastructure-level encryption with a customer-managed key covers the database and document storage underneath all of it.
• In transit: TLS is enforced from your device to our load balancer and from the service to the database; the hop between the load balancer and the service runs inside our private network.
• 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: credentials for outside services. None can be connected in this beta. Accounts that linked WHOOP, Oura or a music service before those features were paused still have those credentials on our servers, readable, because they are refreshed with no device present to hold a key; deleting your account deletes them. And we don't collect your location: weather is estimated from your device's time zone, not from GPS or any coordinate — though, like any web service, our load balancer logs the IP address a request came from, kept for 30 days.

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 for everything your device locked — the exceptions are the ones listed in section 05, which are protected by storage encryption only.
• 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 — its messages and the conversation record itself — is deleted outright when you leave it; if the app never got to, it is deleted the next time you use Neeos after a day. Real row deletion, not a hidden flag.
• Vault trash and deleted chats hold a 30-day recovery window. After that they are purged the next time the cleanup runs — it runs as you use the app, not on a clock.
• 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. When you're offline, Apple's on-device model can answer from the notes on your phone; everything else needs 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.