Pod concepts

These concepts describe how @norbital-ai/pod lets you author a workspace, and how Core builds and runs it.

Workspace source

Editable TypeScript/Svelte roles under src/: collection models and relationships, apps, hooks, pipelines, integrations, automations, remotes, and seed data. The Pod Vite plugin compiles this into build output the runtime loads.

Build output

vite build runs the Pod plugin and emits a compiled bundle Core runs:

• output/server/ — server bundle for collections, hooks, automations, and remotes
• .norbital/migrations/ and schema SQL — tenant database migrations and helpers
• .norbital/dist/ — compiled runtime, tenant apps, assets, and host shim

Core applies DDL and deploys the complete checkpoint through its build pipeline. Local workspace development invokes the same Pod Vite plugin.

System collections

Platform tables (user, team, policy, and approval_request) are merged into the manifest at build time. Tenant authors add domain collections on top. See System collections.

Authoring surfaces

• Collections — domain +model.ts roles and relationships
• Hooks / pipelines / integrations — server behavior on collections
• Automations — scheduled background jobs
• Apps — Svelte operational UIs
• Remote functions — typed server endpoints

Policies

Access is policy-based: reusable grants assigned to teams, evaluated inside the pod runtime on every read and mutation. Approval gates use write-then-lock — see Policies & Approvals.

Facilities

Workspace code reaches Postgres, storage, AI, and secrets only through host-provided bindings — never direct credentials. Pod exposes an ai facility port; Core binds the concrete provider at runtime.