Every change tracked. Nothing slips through.
Blueprint mutations work like git. Every change — whether made by AI or a human — becomes a Change Request inside a Change Set. Blast radius is computed before approval. Dependencies cascade in order. Every apply creates a snapshot with stored reverse operations so any change can be rolled back, instantly.
Change Sets and Change Requests
The model mirrors git: Change Requests are commits, Change Sets are pull requests. Every mutation to the Blueprint — add, remove, replace — is a typed, traceable Change Request.
Every Change Request specifies an operation — add, remove, replace, copy, or move — against a named target in the Blueprint. Operations are JSON Patch-compliant, which means they're diff-able, reversible, and serializable. No freeform mutations.
Each Change Request captures the before state at proposal time and the after state at apply time. You can diff any two points in Blueprint history. Nothing is lost.
Change Requests within a Change Set declare dependencies on each other. The engine applies them in topological order — prerequisites first, downstream after — so cascade chains never apply in the wrong sequence.
Blast radius before you commit
Before any Change Set is approved, the engine computes exactly what will be affected — records, downstream nodes, dashboards, reports. You see the full impact before a single change lands.
Low (isolated change, few dependents), Medium (moderate cascade, no destructive ops), High (significant downstream, possible data migration), Critical (destructive operations present, large cascade). Severity gates approval policy — Critical changes cannot auto-approve.
Any Change Request that removes a node or drops data is automatically flagged as destructive. Destructive CRs are surfaced prominently in the review UI and cannot be bundled with non-destructive changes without explicit acknowledgement.
The blast radius report shows exactly how many downstream Blueprint nodes, records, and integrations are touched — not an estimate, a computed traversal of the dependency graph. You know what breaks before it breaks.
Approval on your terms
Three presets. Configurable per user, per doctype, per field. You control the gate — from instant auto-approval to manual sign-off only.
Low-severity changes auto-approve after 30 seconds. The window gives you time to cancel if something looks wrong, but doesn't slow you down for routine modifications. Ideal for low-risk iteration loops.
Medium-severity changes queue for 5 minutes. Notification is sent to the approving user. If no action is taken, auto-approval fires. Practical for team environments where changes are frequent but someone should be aware.
High and Critical severity changes require explicit human approval. No timer. No auto-approve. The change sits pending until a named approver acts. Role-based approval chains, per-doctype overrides, and per-field rule matching are all supported.
Full rollback, always
Every applied Change Set creates an immutable snapshot and stores reverse operations. Rolling back is a single action — not a migration.
Before any Change Set lands, the engine snapshots the before state of every affected target. Snapshots are SHA-256 hashed, gzip-compressed, and stored inline for small targets or in object storage for large ones. The chain is parent-linked — the full history is traversable.
At apply time, the engine computes the exact inverse JSON Patch operations for every Change Request and stores them with the Change Set. Revert is deterministic — not a best-effort undo, a precise re-application of the reverse diff.
Snapshots support branch_name and fork_of fields. You can fork a Blueprint state, apply experimental changes on the fork, and merge back — or discard. The same model used for git branching, applied to your living specification.