Execution Lifecycle

Committed design

The core owns lifecycle order. Providers and other extensions contribute typed facts, plan nodes, actions, and evidence; they do not create parallel orchestration flows.

Stages

Stage	Contract	Mutation
Resolve	Apply precedence and provenance; ask extensions for deterministic defaults	No
Validate	Check schema, local inputs, policies, capabilities, and known constraints	No
Plan	Build, validate, serialize, and hash the normalized DAG	No
Assess (optional sidecar)	Collect facts and recommendations for suitability and readiness before or after Plan	No
WhatIf	Reconcile the immutable plan with live state	No
Estimate cost	Price declared quantities separately from planning and report uncertainty	No
Approve	Bind actor and allowed scope to the plan hash	No
Deploy	Dispatch approved nodes to the selected engine and supporting operations	Yes
Probe	Test declared postconditions and produce evidence	Read-only where possible
Report	Render evidence envelopes	No
Shutdown/Resume	Change eligible runtime state using a new approved operation	Yes
Teardown preview	Reconcile ownership and show delete, retain, conflict, and unknown	No
Approve teardown	Bind deletion scope to a teardown-plan hash	No
Teardown	Delete only eligible, confirmed resources in dependency order	Yes
Cleanup proof	Reconcile removals, retained resources, failures, and unknowns	No

Assess is not a mandatory step between Validate and Plan, and it does not migrate data. Cost estimation does not grant spending approval. WhatIf does not approve or execute changes.

Assessment may run before or after planning depending on its inputs and the question being answered. It is a release requirement where applicable, not a prerequisite for security policy, cost estimation, or an initial deployment canary. Any assessment-derived plan change creates a new plan hash.

Provider contribution

For each applicable stage, a target provider may contribute:

• offline validation rules and deterministic defaults;
• required live-state queries;
• normalized resource and action nodes;
• preconditions, postconditions, risks, and capability requirements;
• cost quantities and quality limitations;
• secretStoreDecision and, for an Azure VM, administrativeAccessDecision;
• probe specifications;
• teardown dependencies and cleanup checks.

Engine export functions are not provider lifecycle methods. Providers never implement ExportBicep or ExportTerraform.

Idempotency and partial failure

Every mutating action has a stable action ID, idempotency key, expected preconditions and postconditions, and retry classification. After interruption:

1. Acquire the run lock.
2. Verify approval is still valid for the plan hash.
3. Reconcile recorded state, engine state, and live state.
4. Mark actions succeeded, pending, drifted, conflict, or unknown.
5. Continue only actions that are idempotent and still approved.
6. Require a new plan and approval for replacement, expanded scope, or increased spend.

Compensation is explicit and never assumed. If automatic rollback is unsafe, the run stops with recovery evidence and leaves resources intact for review.

Ownership-aware teardown

Ownership	Meaning	Deletion eligibility
owned	Created by this run	Eligible when teardown intent and approval include it
adopted	Existing and explicitly brought under lifecycle control	Eligible only under its recorded adoption scope
reused	Existing and consumed without ownership	Never deleted by this run
external	Observed or referenced only	Never deleted

Unknown resources are never deleted. A matching name, resource group, or tag is not enough to establish ownership. Teardown traverses the approved plan in reverse dependency order and records every retained, deleted, failed, and unresolved item.

Human and automated checkpoints

Policy may require approval for spend, sensitive data, secret display, license acceptance, unverified artifacts, adoption, replacement, or teardown. Authenticated CI, webhook, or AI-assisted sessions can request non-mutating work or resume an approved run with its run ID and idempotency key. They cannot bypass those checkpoints.

An unattended mutating stage also requires remote locking and fencing. A local file lock cannot authorize two independent runners, webhook deliveries, or agent sessions to continue the same run.

See Plan and State for serialization and recovery details.