System collections
Every workspace ships with a fixed set of system collections defined in @norbital-ai/pod. They are merged into your manifest at norbital build — you do not redefine them in modules/collections/.
Tenant authors add domain collections beside this baseline. System collections power identity, access control, work coordination, approvals, files, and audit trails.
systemWorkspace. Do not copy or override collections like user or approval_request in 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 and parent teams
- policy — named bundles of collection grants and
accessible_applicationsfor app visibility - team_policy — assigns a policy to a team
Mutations on user, team, policy, and team_policy require admin access. See Policies & Approvals for how grants
work on domain collections.
Work & review
- task — operational follow-up with assignees, teams, tags, and kanban/list/timeline views — Tasks
- task_tag — colored labels attached to tasks
- 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 ↔ teamstask_assignee— users ↔ taskstask_team— teams ↔ taskstask_tag_task— tags ↔ tasks
vs domain collections
Domain collections are yours: payroll runs, shipments, work orders, and so on. System collections
are the platform substrate every tenant shares. Only task is openly mutable by non-admins
among system collections — everything else in the identity and policy set is admin-governed.