Initial public ModelForge release
This commit is contained in:
@@ -0,0 +1,30 @@
|
||||
# ADR-0033: Promotion plans and rollback snapshots
|
||||
|
||||
## Status
|
||||
|
||||
Accepted in M12 on 2026-08-26.
|
||||
|
||||
## Context
|
||||
|
||||
Approval alone does not describe blast radius, canary semantics, resource placement, migration or
|
||||
restoration. A single-click approval-and-swap cannot be reconciled safely after races or restart.
|
||||
|
||||
## Decision
|
||||
|
||||
An approved request permits an immutable PromotionPlan. Execution journals a separate idempotent
|
||||
LifecycleOperation and captures an immutable rollback snapshot before activation. Subject versions
|
||||
provide compare-and-swap protection, and the database enforces single production-stable deployment.
|
||||
Successful canary requires a second explicit review; failures and incomplete restart stages roll back
|
||||
conservatively.
|
||||
|
||||
## Consequences
|
||||
|
||||
Requester, approver and executor are auditable even for one owner. Plan changes create new plans.
|
||||
Failed rollback becomes manual intervention, never false stable. Embedding reindex and schema-breaking
|
||||
plans are representable but not auto-executed by M12.
|
||||
|
||||
## Rejected alternatives
|
||||
|
||||
- Mutating deployment rows directly: loses intention and recovery state.
|
||||
- Automatic promotion after canary: removes the explicit production decision.
|
||||
- Reconstructing rollback from current rows: current truth may already be partially changed.
|
||||
Reference in New Issue
Block a user