System documents

datadata exposes its own state as documents under the reserved sys: prefix. They ride the same subscribe/read path as your data — documents all the way down — so a devtools panel, a sidebar, or an agent introspects the engine with the calls it already uses.

Most sys: documents are synthesized read-models: the engine derives them and you never write them directly. The exceptions are real, editable documents, written through the same createDocument/updateDocument calls: schema documents (schemas as documents) and the sys:access roles document (authorization). No sys: document can be deleted, editable or not.

System documents are also commonly shaped by authorization: unlike a normal document, which every subscriber sees identically, a system document is shaped per reader. Listings hide the documents you can’t access, sys:access is redacted to your own entry, and sys:principal is your connection’s identity alone. Two clients subscribed to the same sys: document can hold different state. See Authorization.

Folder state

• sys:index — every document in the folder the reader can access, with its type and name. Renaming a document patches its entry here, so a subscriber sees the new name without reloading the document. The data source for a listing or sidebar.
• sys:trash — every soft-deleted document the reader can access (id, type, name, when); the data source for a trash/restore UI. It updates live as documents are deleted, restored, and purged (a purge removes the entry — the signal that restore is no longer possible).

Schemas

• sys:schema:<type> — the schema for a document type. A real document, written through the same createDocument/updateDocument calls and carrying its own migration history.
• sys:schema:presence:<presenceType> — a named presence channel’s cell schema. Presence is schema-gated too: no declared schema, no channel.

Access

• sys:access — the folder’s roles document: per-subject role assignments and folder-wide defaults. A real, editable document (writable only by admins, with admin-only history), but served redacted per reader — a non-admin syncs only its own entry plus the defaults, while admins and trusted server code read the full document. A folder without one treats authenticated subjects as admin; governance is opt-in. See Authorization.

Staged work

• sys:session — a summary of all currently staged work in a session. Its per-target entries are shaped by target read visibility; hidden stages are counted in aggregate without revealing their target ids.
• sys:stage:<docId> — the full staged detail for one document. See sys:session and sys:stage.

Identity and client state

• sys:principal — the connection’s own identity: the principal the server actually enforces (roles, grants, scopes). Synthesized per connection from its connect-time state and never stored. A client subscribes to it and adopts it, so prediction and capability discovery run against the real principal; a host-driven mid-connection change is re-served on the live socket. See Authorization.
• sys:presence:<presenceType>:<docId> — ephemeral per-participant state (who’s here, cursors, what’s streaming) on a channel. Never stored durably: the server keeps an in-memory aggregate and each client owns its own cells. See Presence.
• sys:presence-view:<presenceType>:<docId> — a session’s own lens over that aggregate, shaped { self, peers }: self is this session’s cell, peers is every other cell annotated with staleness from the liveness overlay. Synthesized on read and read+write — writing self publishes this session’s cell through to the aggregate — but never persisted or synced; it exists only through a session, so the live client reads it as null.
• sys:client-docs-status — the client’s own view of what it’s subscribed to and where each document sits in the sync lifecycle. A client-side read-model, not folder state.