Blueprint Versioning & Forks

Norbital treats configuration as versioned infrastructure. Because schema, permissions, interfaces, pages, and automation templates all live in the blueprint, the platform stages and applies changes with the same discipline you would expect from a deployment workflow.

Understanding Blueprint Checkpoints

Every production sync creates a new checkpoint.

A checkpoint represents the currently applied production blueprint and gives you:

  • A stable version to branch from
  • An audit trail of what changed and when
  • A recovery point for rollback workflows

What A Fork Is

A fork is the safe staging area for blueprint work. It branches from a checkpoint and is backed by a cloned tenant database so structural changes can be prepared and tested before they reach production.

Use forks for:

  1. Schema changes
  2. Permission updates
  3. Interface edits
  4. App and page changes
  5. Automation and notification configuration

The Staging Workflow: Blueprint Forks

In day-to-day work, the flow looks like this:

  1. Create a fork from the latest production checkpoint.
  2. Stage your changes in Database Studio, app settings, or Commander.
  3. Review issues raised by linting and validation.
  4. Merge the fork when the staged state is correct.

Fork Locking

Forks use an ownership model so only one active editor controls write access at a time. Other people can inspect the fork without creating conflicting edits.

  • One editor owns the lock.
  • Other collaborators can review in read-only mode.
  • Agent-driven changes must hand the lock back before merge or discard.

Validation And Issues

Saving to a fork does more than store text. Norbital lints and validates the staged configuration as you work so the fork can be marked valid or invalid before merge time.

Do not treat save as apply
Saving a collection or codeblock updates the fork payload. Physical schema changes and schedule updates happen only when the fork is merged into production.

Merging A Fork

When you merge a valid fork, Norbital applies the staged configuration as one coordinated change:

  1. The system confirms the fork still branches from the latest production checkpoint.
  2. Schema differences are computed from the staged blueprint state.
  3. Production is updated and a new checkpoint is recorded.
  4. Post-merge synchronization tasks, such as automation schedule sync, are run.

Rebase When Production Has Moved

If someone else has already merged a newer checkpoint, your older fork may need to be rebased before it can be applied. This is an important operational habit for larger implementation teams.

Rollbacks And Recovery

If a production change needs to be reversed, Norbital can restore an earlier state and record that recovery as a new checkpoint. History stays append-only, which keeps the audit trail intact.

  • Keep forks focused on one implementation goal.
  • Merge smaller changes more often instead of carrying a large long-lived fork.
  • Rebase early if production has moved.
  • Review issues before merge, even if the change feels small.
Previous Core Concepts Next Collections