Operate · Execution
Execution plans.
A phased, dependency-aware sequence of changes Axiom proposes after a scan. Every item ships with Terraform, blast radius, pre-verified rollback, expected impact, and approval requirements.
The contract
01
Anatomy of an execution plan
- Title + summary — what the plan accomplishes and why
- Total resources affected — and which provider/region
- Estimated savings/impact — monthly dollar impact, performance delta, security posture change
- Total duration — predicted apply time across phases
- Rollback RTO — measured time-to-restore if anything fails
- Blast radius — contained (1–5) / moderate (6–20) / broad (20+)
- Phases — ordered, dependency-aware steps
- Terraform preview — full IaC diff per phase
- Affected resources — typed list with create/modify/destroy classification
- Safety checks — pre-flight conditions that must pass before any apply
02
How phases work
Phase 1 is always snapshot + rollback verification
Capture pre-flight state. Verify rollback path can restore that state within the published RTO. ALB drain configured if applicable.
Subsequent phases group dependent changes together
Plans are split into the minimum number of phases that still respect dependency ordering. Each phase has its own approval gate.
Health verification between phases
After each phase, Axiom confirms expected state (health check, cost delta within bounds, no unexpected drift). Failed verification halts the next phase and triggers rollback if configured.
Final phase locks the outcome
Last phase records the cost shift / posture change / drift correction in operational memory. Plan transitions from "executing" to "complete".
03
Risk levels per item
- Low — Idempotent, easily reversible, contained blast radius. Single approver.
- Medium — Reversible with measured RTO, moderate blast. Single approver + rollback verification required.
- High — Multi-resource impact, requires multi-party approval. Cannot be auto-applied regardless of Trust Ladder state.
04 · Verification
What verification proves
- The intended resource change actually landed (modify/create/destroy completed at the AWS API level)
- Health checks pass — ALB target group, CloudWatch alarms, custom SLI
- Cost shift is within the predicted range (catches surprise behavior)
- No new drift was introduced (the change didn't cascade elsewhere)
- The savings/security posture change is real and durable (lock event written to memory)
05
Rollback readiness
Every plan item is gated on rollback verification. The criteria:
- Pre-flight state can be captured (snapshot, configuration export, or AMI)
- Restore path is mechanically possible (re-create resource from snapshot, re-apply prior Terraform, etc.)
- RTO is measured, not estimated
- If any of these fail, the plan item is blocked at the governance gate until resolved
See rollback strategy for the full rollback lifecycle.
Trust questions
What is an execution plan?
A reviewable, phased proposal of changes Axiom wants to make. Always reviewable before apply.
Why phased?
To respect dependencies, isolate failure, and verify health between steps. Each phase is independently approvable.
Is it safe to approve?
Items only reach you if pre-flight rollback is verified. You see Terraform, blast radius, and RTO before approval.
What happens after apply?
Health verification confirms the change landed correctly. Memory locks the outcome. Confidence calibrates for similar future actions.
What if it fails mid-phase?
Rollback fires automatically. Audit log records the failure + rollback outcome. You can re-plan once root cause is addressed.
Can I export instead of apply?
Yes — every plan generates downloadable Terraform you can apply through your own pipeline.
Need a human?
Most flows are documented — but we'll help if anything is unclear.