What MAXIMUM protection blocks, and what it does not

Every vault carries a protection level, set in Settings then Vaults. Two matter day to day: NORMAL, the default, and MAXIMUM, for what you do not want leaving for a provider.

A NORMAL vault is ordinary memory: read in answers under the default scope, on every route.

What MAXIMUM does

Marking a vault MAXIMUM has four effects, and they are precise.

A question that names no vault does not read it. The default scope queries every vault at once, and protected vaults are removed from it at the source.

If you name the vault explicitly, it answers, but the route is constrained: an answer grounded in its content cannot go to a cloud model. The refusal is not a wall, it carries a "send anyway" button. That consent covers that one call and is never stored.

Indexing its content does not go through a remote embedding service. A file arriving in a protected vault is computed locally, or not indexed at all.

It is removed from the dream layer, the nightly pass that links memories to each other.

What MAXIMUM does not do

It does not encrypt the vault. Protection governs where content is allowed to go, not the form it is written in on your disk.

It does not stop you from reading it yourself, or from naming it in a question. That is deliberate: a private vault stays selectable, otherwise protecting it would mean losing access to your own memory.

It does not apply when you are already local. On a local route nothing leaves the machine, so nothing is held back and every vault answers, protected ones included.

The conversation lock

Once an answer has been grounded in a protected vault, the whole conversation carries that constraint. A later turn heading for the cloud is refused with the same button, because the first answer comes back inside the next turn's prompt. The constraint follows the conversation, not just the message.