Core Concepts

These concepts explain how Norbital behaves as a platform. If you understand them first, the rest of the product feels much more predictable.

1. The Blueprint

The Blueprint is the source of truth for an organization's configuration. It is not just a schema file. It describes the operational model of the workspace, including:

• Collections and route metadata
• Teams, permissions, redaction, and approvals
• Apps and pages
• Automation templates
• Codeblocks and expressions

2. Forks And Checkpoints

Production configuration changes are versioned. A checkpoint is an applied production version. A fork is a staged workspace where you prepare changes before they become live.

• Use a fork to stage schema, permission, interface, app, and automation changes safely.
• Merging a fork creates a new production checkpoint.
• If production advances while you are still working, your fork may need to be rebased.

3. Collections, Routes, And Interfaces

A collection is more than a table. It combines the schema, the relationship expansion model, the record label, the record interface, and route-specific behavior.

• Collections define fields and relationships.
• Routes define how reads and writes behave.
• Interfaces define how a single record is displayed and edited.

4. Permissions Are Part Of The Runtime

Norbital does not treat permissions as a thin frontend concern. Access is enforced server-side when data is queried, when forms are rendered, when payloads are submitted, and even when apps and pages are injected into the client blueprint.

This is why route permissions, field redaction, and approval workflows should be planned alongside the collection design, not after it.

5. Codeblocks And CEL

Most configuration is declarative, but Norbital lets you add small pieces of logic where needed. There are two main tools:

• CEL for concise expressions such as record labels, visibility, or subjects.
• TypeScript codeblocks for forms, page UI, validation, notifications, exports, and automations.

6. Multi-Tenant Isolation

Each organization operates against its own isolated tenant database, while configuration history, tasks, and system-level services are managed centrally. This separation is what lets Norbital stage fork changes safely without cross-tenant leakage.

7. Practical Mental Model

1. Model the business object as a collection.
2. Decide which teams can do what on each route.
3. Shape the record interface for create, view, and update.
4. Add pages, notifications, or automations around the workflow.
5. Stage, test, and merge the fork.

Once you think in this sequence, Norbital becomes much easier to configure and much easier to keep consistent over time.