Architecture Center
Versioned blueprint promotion
Show how a blueprint moves from source to a promoted environment version with validation, test-tenant execution, review, and rollback.
previewreferenceContract >=0.8 <1.0Reviewed 2026-07-20
Problem statement
Changing how sessions behave must be deliberate and reversible. Blueprints are versioned; promotion is a governed step, not an in-place edit.
When to use
- You evolve artifact types, states, commands, or policies over time.
- Behavior must be reproducible against a pinned version.
- You need a safe rollback path for a bad promotion.
When not to use
- One-off sessions with no reusable definition.
- Environments where reproducibility is not required.
Flow
Blueprint sourceValidationCompileTest-tenant executionReviewEnvironment promotionCompatibility monitoringRollback
Resource inventory
- Blueprint version
- The immutable, versioned definition of session behavior.
- Test tenant
- Runs the candidate version against synthetic fixtures.
- Decision
- The authorized promotion approval.
- Compatibility range
- Governs which clients and sessions accept the version.
Failure modes
- Blueprint incompatible
- Validation rejects an incompatible version before promotion.
- Failed test-tenant run
- Promotion is blocked until the candidate passes.
- Bad promotion
- Roll back to the prior version; sessions pin their version.
Security controls
- Promotion requires an authorized decision.
- Versions are immutable; sessions pin the version they were created against.
- Compatibility ranges enforced by the kernel.
Deployment checklist
- Validation and compile steps automated.
- Test-tenant fixtures defined for the candidate.
- Promotion approval and rollback path documented.
- Compatibility monitoring after promotion.
Related quickstart: Produce and compare artifact revisions →