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 (agent memory, voice history, publishing credentials, the product registry) | 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.
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-data stores (the activity feed and the missions board projection) — they are caches rebuilt from your files on next launch; your missions and history-of-record live in the documents tree, not there.
- 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