Your data lives on your node, and so does the reading of it

Most AI products keep your documents in a large shared cabinet. Your drawer is labelled, the staff are trustworthy, and they are asked not to open it. That arrangement can be run honestly for years. It is still an arrangement, and what protects your documents in it is a rule someone is following.

Your node is not a drawer in our cabinet. It is a vault that sits inside your own deployment, and it has no keyhole on our side. What it has is a request slot. We can post a request through it: store these passages, or answer this question. We cannot walk in and read the shelves, because there is no door that would let us.

Concretely: the platform never opens a database connection into your node's store. It sends intents, which are specific requests your node validates and carries out itself. It cannot browse, and it cannot run a query of its own devising. That distinction is the entire point. "We promise not to look" is a policy, and a policy can be changed by anyone who later has a reason to. "There is no way to look" is a design. We withheld the ability rather than merely declining to use it, because the second one is what you can actually verify.

Storing your documents on your node is only half of it. Answering a question about them takes several steps that have to read them: finding candidate passages, ranking those candidates so the best one leads, and writing the shortlist into instructions for the model. Anywhere those steps run is a place your text is read.

So they run on your node. When you ask a question, the platform sends your node the question and nothing else. Your node searches its own vault, ranks what it finds, decides which passages are good enough to use, writes the prompt, and calls the model. What comes back to us is the finished answer and a list of the sources it cites. The passages themselves never make the trip.

This is worth stating plainly because the alternative was the obvious way to build it, and for a while it is how this worked: your node sent the passages to us, we ranked them and built the prompt, and then we sent that prompt back to your node to be answered. Your text made a round trip through the one place we tell you it does not go, and arrived back where it started. Moving the ranking to your node removed a network hop and a copy of your data at the same time. When the privacy-preserving version is also the shorter path, that is usually a sign the design was wrong before.

A transcript is your content. What you asked reveals what you were working on, and what the model answered is built out of your own documents. Storing your files carefully and then keeping the conversation about them in a shared database would protect the pages and publish the reading list.

So chat history follows the same rule as the knowledge base, through the same decision point rather than a parallel one: one place in the code decides where your data lives, and both your passages and your conversations follow it. Your threads persist per node, so you can leave and come back to them, and they persist on the node they belong to. Deleting a conversation is a real deletion, not a hidden flag that keeps the rows and stops showing them to you.

If your node is unreachable, or has no model runtime, we refuse the question. We do not quietly answer it from the middle instead. That looks like worse availability, and it is, but it is also the guarantee showing its work: a system that could fall back to answering centrally would be a system that had your data in reach the whole time. The refusal is only possible because the fallback does not exist.

Uploads come through the front door. You upload documents through our dashboard, so a new file passes through the platform on its way to your node: we receive it, read it to split it into passages, and today we also turn those passages into the fingerprints that make them searchable before sending them on. That means ingest is the one point where your document text is handled on our side. Moving the fingerprinting onto the node is planned work. Until it ships, the accurate claim is that your data lives on your node and is read there when you ask questions of it, not that it has never been in our hands at all. We would rather name that than round it off.

Your question and your answer travel through us. The dashboard is served by the platform, so the question you type and the answer you read pass through it by construction. The citations shown alongside an answer include short snippets of the passages it used, and those ride back with the answer so your screen can display them. What stays on the node is the corpus and the pipeline that reads it, not the conversation you are having through our front end.

"Residency" here means a boundary, not a country. Everything on this page is about whose machine your data sits on: yours, not a shared one of ours. That is a different question from which jurisdiction that machine sits in. You can already pin a dedicated node to a region when you provision it, but the governed profile around that, the one that lets a regulated buyer attest that a given workload never left a given country, is Enterprise roadmap rather than a shipped guarantee. If you are here because of a compliance requirement worded in terms of geography, this page answers a related question and not that one.

Community tier is central by design. Residency starts at Personal. The free tier runs on shared infrastructure and has no node of its own to keep anything on, so its data and its pipeline both live centrally. That is a boundary rather than an oversight: a dedicated node is real compute that someone has to pay for.

Your node becomes a dependency you can feel. Because we will not answer from the middle, node health is now something that affects whether you get an answer at all. That is the honest cost of the guarantee, and it is the trade we think is worth making.