Isolation per vault
Each graph lives in its own version-controlled vault. Storage, history, and the retrieval index are isolated per vault; there is no pooled store your data mingles in. Every change the xysq Memory Engine makes is a commit you can diff, with a code-owned changelog and a ledger entry behind it. Nothing changes silently. That isolation isn’t a compliance feature bolted on later. It’s how the engine works, and it’s what makes export and deletion clean.Export anytime
Pages are standard markdown. You can export your graph at any time and read it in any markdown tool. The export is the same thing the engine serves, not a degraded copy. No lock-in.Deletion is real
Two different things, and we mean both:- In normal operation, the engine invalidates rather than deletes. A superseded fact is closed, not erased, so lineage holds: you can always see what changed, when, and on what evidence. That’s versioning.
- When you delete, it’s an actual erasure. Deleting an item scrubs the fact ledger (including its quoted evidence), the page history, the vectors, and the archives. Deleting your account is a clean sweep of your vault and your slice of the index, which per-vault isolation makes tractable. Not a soft hide. Not a tombstone that quietly keeps the data.
Consent-gated, never trained on
Your context is never used to train models. Nothing crosses a graph boundary without an explicit share that you approve in the app, and every share is view-only and revocable. Inspect, export, delete: all three are yours, all the time.BYO drive and private deployment (rolling out)
The direction we’re building, rolling out now:- Bring your own storage. Your graph mirrored to a drive you control, readable in standard markdown tools (open it in Obsidian and you get a graph view for free).
- Private deployment. The engine running inside your own boundary.
Next
MCP tools
The four tools your agents use to read and write context.
Build with the SDK
Read from one or many graphs, write to your own.