Perseus Vault

Perseus Vault keeps three planes distinct:

Implicit working context is the host's current prompt, transcript, and any context block a client chooses to inject. It is ephemeral and host-owned; it is not persisted merely because Vault returned it. Explicit durable memory is written by an explicit perseus_vault_remember, perseus_vault_capture, write, or capture operation. The Vault server owns the SQLite record, history, journal, decay, archive, and purge lifecycle. Derived projections include consolidated or synthesized records and exported Markdown. They carry provenance, but they are not a replacement for the durable source records and may need separate cleanup. perseus-vault prepare and perseus_vault_context read durable records to produce a bounded, task-relevant active working context. This is a rolling snapshot, not a background write or a promise that the client will retain it: refresh it when the task changes, and do not treat prompt text as durable memory unless an explicit capture/write operation succeeds. Recall-first output is budgeted (1500 characters by default, 6000 for large-window hosts, or an explicit max_context_chars); the always_on set is capped at five. See retention and context semantics.

Lifecycle hooks and client installers are optional orchestration. They request server-owned recall, capture, maintenance, and refresh work; they do not become a second store or change retention policy. If the server or a hook is unavailable, continue the task without injected memory and surface the degraded state. A host integration may have an explicitly configured local fallback, but that fallback must be labeled local-only and must not be presented as durable Vault recall; a failed explicit write must never be reported as persisted. For upgrade/recovery steps, use the upgrade and migration playbook.