Data Layer
One pane onto your local data footprint — every store the platform maintains, its durability tier, and operator-controlled backups with staged restore.
The Data Layer (Settings ▸ Data Layer) shows you every local database the platform maintains — what exists, who owns it, how big it is, and how it is backed up. It is the answer to three buyer questions in one screen: where does my data live, what is protected, and what is safe to delete.
The premise behind the screen: everything is local. There is no cloud database. Your data lives in a set of local store files on your own disk, plus one local graph database (managed separately — in Cortex and Settings ▸ Database). Every store is created empty on first run and self-bootstraps; a fresh install starts with your data and nobody else's.
Reading the board
The header rolls the topology up into one line — how many stores exist, the total size on disk, and how many are being backed up — with a Refresh button. The topology is served by the Routines service, so the board needs that daemon online (start it from Dashboard ▸ Platform Health if the view reports it unreachable).
Below, one card per store, grouped by durability tier:
| Tier | Meaning | Backup posture |
|---|---|---|
| 1 · Critical | Irreplaceable — losing it costs re-authentication or paid work to rebuild, or is simply not derivable from anything else (agent memory, voice history, publishing credentials, the product registry, your Calendar schedule, your email address book) | Backed up automatically, longer retention |
| 2 · Valuable | Regenerable with effort (product ledgers, video briefs) | Backed up automatically, short retention |
| 3 · Operational | Ephemeral or re-derivable (harvested items, queues, render jobs, the activity feed) | Not backed up by design — manual snapshots still available |
Each card shows the store's name and a status dot, a pill for its backup state (auto-backup on/off, manual, or an amber restore pending), a one-line description, and a meta line: owner, size, snapshot count, and last-backup time. The agent-memory card carries a shortcut into the Memory view. A couple of stores are shown but not manageable here and say why on the card — the per-product ledgers keep their snapshots inside each product folder (so a product folder stays a portable unit), and the desktop app's own store lives in application data, managed by the app.
Two cards are worth finding, because they explain what the tiers actually measure. The Calendar schedule and the email address book sit in Tier 1 not because they are large or busy, but because they are hand-authored: nothing on this machine can rebuild a week you planned or a contact list you typed. The email queue right beside the address book is Tier 3, and is regenerable from your mailbox in one poll. The tier is answering could this be produced again?, not how often is it written?
The backup drawer
Click a card to open its drawer:
- Back up now — takes an immediate consistent snapshot (safe while the owner is writing) and prunes to the retention count.
- Policy strip — for auto-capable stores, an on/off toggle for automatic backups and a stepper for how many snapshots to keep (1–100). Both apply at runtime — no restart, no file editing. Stores that are manual-only say so: off by design.
- The snapshot list — every snapshot with size and age, each with Restore and Delete.
Snapshots live in a backups/ folder next to the store itself, so they are
yours on disk and travel with anything you copy.
Restore is staged, on purpose
Restoring never overwrites a live, running database. Choosing Restore stages the snapshot; the card shows restore pending, and the restore is applied the next time the owning service restarts — the confirm dialog spells this out, and a staged restore can be canceled any time before that restart. During the swap the current database is preserved aside rather than destroyed.
Corruption is handled the same way — defensively: a store that fails its integrity check at boot is quarantined aside (never deleted) and recreated fresh, so you can recover the old file or restore a snapshot from the drawer.
What is safe to delete
- Any Tier-3 store — it rebuilds or re-harvests. This is the sanctioned way to reclaim disk space.
- The desktop app's own store — the activity feed. It is a cache of what agents did, not the record of it; the files they wrote are the record, and they are in the documents tree. It is the one store on the board that lives in application data rather than your workspace, which is why the card says it is not manageable here.
- Not the Tier-1 stores — that is what the automatic backups are for.
One honest boundary: this screen manages the platform's databases, not your workspace. The documents tree itself has no built-in backup — treat that folder like any directory you value. And the scope footer on the view says the rest: the graph database is managed in Cortex, not here.
Related pages
- Memory layers — what the agent-memory store means
- The knowledge graph — the one non-relational store, and where it is managed
- Configuration reference — the install folder map these stores live in
- Dashboard — starting the service that serves this board