Core

Committed design

The core turns user intent and extension contributions into one normalized, reviewable plan. It coordinates work but does not contain Azure-service logic or deployment-engine syntax.

Responsibilities

Area	Core responsibility
Configuration	Parse versioned YAML, apply precedence, validate schema, and record provenance
Policy	Evaluate identity, network, secret, spend, licensing, sensitivity, and lifecycle rules
Planning	Merge extension contributions into a stable resource-and-action DAG
Preview	Produce offline -Plan and live, non-mutating -WhatIf results
Assessment	Coordinate facts and recommendations separately from migration
Cost	Run a distinct estimate using declared quantities, prices, assumptions, and uncertainty
Approval	Bind approval to the plan hash, policy decisions, actor, scope, and expiry
Orchestration	Dispatch approved actions to the selected engine and resumable supporting operations
State	Record append-only events, snapshots, locks, reconciliation, and cleanup evidence
Reporting	Emit versioned evidence that can render to console, JSON, Markdown, or HTML

The core does not silently infer unsupported target behavior. An extension either declares a capability and contributes valid plan nodes, or returns a structured capability failure.

Configuration contract

YAML is canonical. Templates make common cases easier, while explicit flags give experienced users narrow overrides:

schema defaults < selected template < YAML < explicit flags

Each resolved field records:

• final typed value or redacted reference;
• source layer and source location;
• derivation rule, when calculated;
• validator or policy decisions;
• whether an external fact remains unverified;
• schema version.

Flags may override only schema-declared fields. Unknown keys, incompatible schema versions, conflicting overrides, and ambiguous template inheritance fail before a plan is accepted.

Command-line commitments

The final cmdlet grouping remains API-design work, but the architecture reserves these advanced-user parameters and their meaning:

Parameter	Contract
-ConfigFile	Read the canonical YAML definition
-Plan	Resolve and explain the deterministic offline plan
-WhatIf	Reconcile that plan with live Azure state without mutation
-CostEstimate	Run the separate cost-estimation operation
-OutputFormat and -OutputPath	Select console, JSON, Markdown, or HTML rendering and its destination
-DeploymentEngine	Explicitly select PowerShell, and later Bicep or Terraform when supported
-TerminalUi	Opt in to guided YAML creation; never make the terminal UI mandatory
-KeyVaultName and -UseExistingKeyVault	Contribute to, but never silently replace, the target or solution pack’s explicit secretStoreDecision
-GeneratePassword and -ShowPassword	Independently opt in to generation and shell display
-ContainsSensitiveData	Acknowledge restricted data and activate policy checks
-UseCustomArtifact, -CustomArtifactPath, -CustomArtifactUrl, and -CustomArtifactChecksum	Select a user-controlled artifact and optional expected digest

Unsupported combinations fail during validation. A parameter cannot weaken a deny policy merely because it was supplied explicitly.

Policy and approval

Policy findings have stable codes and one of four outcomes: allow, warn, require-approval, or deny. A warning does not become consent.

Approval records contain the plan hash, actor, timestamp, expiry, approved operations, acknowledged risks, spend boundary, sensitive-data decision, and teardown scope. A changed plan requires new approval. Non-interactive approval must be supplied through an authenticated, auditable mechanism; a webhook, CI job, or AI session cannot approve itself.

The following always remain explicit:

• each target and solution pack’s secret-store decision;
• each Azure VM’s administrative-access decision;
• secret generation or display;
• use of sensitive data;
• unverified or unsigned artifacts;
• license acceptance;
• spend above the approved boundary;
• replacement or destructive change;
• adoption of an existing resource;
• teardown.

Operations

Operation	Purpose	Azure auth	Mutation
Validate	Check schema and locally available inputs	No	No
Assess	Collect and interpret source or target facts	Depends on source	No
Plan	Resolve a deterministic normalized plan	No	No
WhatIf	Reconcile a plan with live Azure state	Yes	No
EstimateCost	Price the declared plan with explicit assumptions	Depends on price source	No
Deploy	Execute an approved plan	Yes	Yes
Probe	Verify declared postconditions	Depends on probe	Read-only where possible
Report	Render existing evidence	No	No
Shutdown/Resume	Change eligible runtime state	Yes	Yes
TeardownPreview	Resolve deletion eligibility and blockers	Yes	No
Teardown	Execute an approved teardown plan	Yes	Yes
CleanupProof	Reconcile expected removals and retained resources	Yes	No

Assessment can inform target choice, sizing, compatibility, security, and migration readiness. It does not move data. Migration is a later, separate capability with its own plan and approval.

Assessment evidence is required for a release when the target or scenario declares it applicable. Assessment is not a prerequisite for security policy, planning, cost estimation, or an initial deployment canary.

For the first SQL Server path, the committed assessment integrations are SQL Server enabled by Azure Arc and the migration component in SQL Server Management Studio. They contribute assessment evidence; they do not turn assessment into an automatic migration.

External continuation

Authenticated triggers may:

• request validation, planning, reporting, or another non-mutating operation;
• request resume of an already approved run using its immutable run ID and an idempotency key.

They may not widen approval, increase spend, reveal secrets, acknowledge sensitive data, accept a license, adopt resources, or approve teardown. Resume begins with state lock acquisition and live reconciliation. CI, webhook, and other unattended mutation requires an approved remote state backend with leases, fencing, resumable events, and OIDC or managed identity.

See Plan and State for the serialized contracts and Extension Model for contribution boundaries.