Stores & Workspaces

The Kernel does not hold all records in a single flat pool. Data is partitioned into stores — isolated ledgers within the Kernel, each with its own fragment files, its own graph index, and its own access scope.

Understanding stores is important for several reasons: they determine which records your agents can see, which graph connections exist, and how changes in one part of your organization are isolated from another.

What a store is

A store is a named, self-contained ledger. Every record write happens into a specific store. Every query is scoped to a specific store (or explicitly expanded to cross multiple stores). An agent running against the "LegalCases" store cannot see records in the "Operations" store unless it explicitly traverses the boundary with appropriate clearance.

Think of a store as a workspace: a bounded context for a team, a client, a department, or a project. Multiple stores can run in the same Kernel. They share the same world model but hold independent data.

Workspace stores

These are the stores you create and manage. They hold your organization's records: people, cases, communications, projects, and whatever else your world model defines. You can have as many workspace stores as your Kernel's disk can hold.

Typical reasons to create separate stores:

• ▸Clients or matters — each client's data is isolated from others
• ▸Departments — Operations and Legal see only their own context by default
• ▸Projects — a bounded store for a fixed-scope engagement that can be archived when complete
• ▸Environments — a staging store for testing agent behavior before running against live data

System stores

The Kernel maintains several internal stores that are always present and managed by the system. These are not visible to end users in the same way as workspace stores. They handle authentication state, API configuration, clearance grants, and the agent registry. Writes to system stores do not trigger graph updates or appear in the record graph — they are infrastructure, not data.

Switching stores

The active store for any session is selected at the start. The browser UI shows a store picker. Agents inherit the active store from the session that dispatches them, unless the session explicitly routes them to a different one.

Every query, every agent action, and every approval request is tagged with the store it operates against. This tagging is permanent — it is part of the audit trail.

The demo store

Every Dominir installation ships with a demo store pre-populated with synthetic records. This store is safe to experiment with: run agents against it, explore the graph, test queries. Changes you make to the demo store do not affect any other store. The demo store uses the same world model as your live workspace, so what you learn in demo transfers directly.

Cross-store traversal

By default, a graph query or agent session is scoped to one store. The Kernel supports explicit cross-store reads when the user or agent has clearance in both stores and the operation is scoped accordingly. Writes always target a single store — there is no way to write to multiple stores atomically.

Archiving a store

When a workspace is no longer active — a project is closed, a client relationship ends — the store can be archived through the Airlock. Archiving a store removes its active data from the running graph, compacts the remaining records, and flags the store as inactive. The archived store is still accessible for audit purposes unless you explicitly release it.