Blueprint Versioning & Forks

Minerva operates differently than a traditional database. Because permissions, applications, custom logic, and database schemas are all defined in a single Blueprint, changing any of them safely requires strong version control.

Understanding Blueprint Checkpoints

Every applied change in Minerva creates a new Blueprint Checkpoint.

1. A snapshot of the live database is taken.
2. The required schema changes are generated.
3. Those changes are applied.
4. A checkpoint entry is stored with reconstructable history.

Because the history is immutable and reconstructable, you always have an audit trail of who changed what and when.

The Staging Workflow: Blueprint Forks

You cannot make changes directly to the live production Blueprint. Instead, Minerva uses Blueprint Forks.

A Fork is an isolated staging environment backed by a clone of the live production database.

Creating and managing forks

• Open Blueprint Manager
• Create a new fork
• Make changes safely without disrupting live users

Forks use a lock-owner model to avoid concurrent write conflicts:

• One active editor owns the fork
• Other collaborators can inspect it in read-only mode
• The interface shows who currently holds the lock

Testing and validation

Because a fork comes with a clone of your data, you can test new fields, UI blocks, and automations on real records. Before a fork can be applied, Minerva validates the configuration and blocks merges with errors.

Applying changes

When you apply a validated fork:

1. Minerva enters maintenance mode
2. Takes a pre-merge snapshot
3. Computes the schema diff and applies it
4. Commits a new checkpoint
5. Cleans up the fork database and exits maintenance mode

Rollbacks and recovery

If a change needs to be reversed, Minerva can restore a checkpoint snapshot and create a new rollback checkpoint so history remains append-only.