Built-in modules

What they are

Built-in modules are system collections merged into every workspace at norbital build. You do not author them in modules/collections/ — they ship with @norbital-ai/pod as operational substrate beside your domain collections.

You cannot redefine these schemas

System collection schemas are fixed. Do not copy or override user, approval_request, policy, or other platform tables in tenant model.ts — the runtime depends on their exact shape for identity, approvals, and audit integrity.

Some collections are especially sensitive: user, team, policy, team_policy, and approval_request are governed by platform rules and admin-only mutation paths. Treat them as infrastructure, not tenant-owned schema.

You can still query them. Apps, hooks, automations, and remote functions read system collections through the same SDK and collection APIs as domain data — subject to policy evaluation. Use them in dashboards, joins, and server logic without redefining the tables.

Shipped modules

Tasks

task and task_tag — operational follow-up with assignees, teams, tags, and kanban/list/timeline views. Non-admins can create and update tasks; assignment drives visibility. See Tasks.

Identity & access

• user — members, roles, invitation state (admin mutations)
• team — org structure and app visibility (admin mutations)
• policy / team_policy — grants assigned to teams (admin mutations)

Approvals

approval_request — write-then-lock review state for gated mutations. Managed by the approval runtime; do not treat as a tenant-editable schema.

Audit & files

• mutation_log / audit_event — append-only change history
• notification — in-app notification rows
• document_asset — file metadata and ingest pipeline

More coming

Additional built-in modules will ship over time — same model: fixed schemas, queryable from your workspace code, with clear mutation rules per collection.

Full reference: System collections.