Skip to content

System collections

System collections

Every workspace ships with a fixed set of system collections defined in @norbital-ai/pod. They are merged into your manifest at the Vite build — you do not redefine them in tenant collections/.

Tenant authors add domain collections beside this baseline. System collections power identity, access control, approvals, files, and audit trails.

Fixed schemas — query, do not redefine
System schemas live in systemWorkspace. Do not copy or override collections like user or approval_request in a tenant +model.ts — the platform depends on their exact shape. You can read and query them from apps, hooks, automations, and remote functions like any other collection.

Identity & access

  • user — org members, roles (admin / member), invitation state
  • team — org structure, parent teams, and one required policy_id
  • policy — named bundles of collection grants and accessible_applications for app visibility

Mutations on user, team, and policy require admin access. See Policies & Approvals for how grants work on domain collections.

Review

  • approval_request — write-then-lock review state for gated mutations

Platform services

  • notification — in-app notification rows
  • document_asset — file metadata, ingest status, semantic search index
  • chat_session — Agent conversation history (Core)
  • mutation_log / audit_event — compliance and change history

Junction relationships

System collections connect through built-in relationships, for example:

  • team_members — users ↔ teams
  • team.policy_id — each team → its governing policy

vs domain collections

Domain collections are yours: payroll runs, shipments, work orders, and so on. System collections are the platform substrate every tenant shares. The identity and policy set is admin-governed.