Clarify Global

Four of these questions are canonical, shared with gcp-to-aws — see references/vendored/clarify/. Read the linked file for the question text, options, and interpretation rule; this fragment supplies only the Azure-specific auto-extraction signal, default, and disposition escalation.

The architecture default is x86_64, and that is a deliberate divergence from the rest of this repo. Graviton is the default in the GCP and Heroku skills. Azure fleets carry Windows and .NET routinely, which is exactly the escape path in references/shared/graviton.md, so defaulting to Graviton here would produce a recommendation that has to be walked back on a large fraction of real estates. Graviton is offered as an optimization with its own savings line.

Step: Return rows

This fragment asks nothing. clarify-assemble.md owns the conversation — see clarify.md § Step: Run the phase for why presentation is centralised.

Q-A1 — Target AWS region

Disposition: DETECTED when every resource shares one Azure region and the map resolves it; ESSENTIAL when the estate spans regions (there is no defensible way to pick one for someone). Default when DETECTED: the mapped region.

Map from the estate’s Azure regions via knowledge/design/azure-region-map.json — do not assume us-east-1 when the estate is plainly European. westeurope → eu-west-1.

This is the region-mapping half of the canonical region question (references/vendored/clarify/clarify-region.md). Read that file for the “where are your users” half. Disposition (Q-A1b): PROPOSED when Q-A1 resolves to a single mapped region (default: "single-region", matching the canonical file’s default answer 1 — the shortcut is the same one GCP’s Q1 documents: a single detected infrastructure region does not by itself prove single-region users, but it is a reasonable default, correctable on the sheet); ESSENTIAL when the estate spans multiple Azure regions (the map cannot pick one AND geography genuinely needs a direct answer, mirroring GCP’s Q1 escalation rule). A CDN / Front Door / Traffic Manager resource in the inventory is a DETECTED signal for "multi-region" or "global" — read it before proposing "single-region".

Q-A1c — Compliance and regulatory requirements — ESSENTIAL, always

Canonical question: references/vendored/clarify/clarify-compliance.md. This question always fires for a full-infrastructure Azure migration — there is no Azure-specific auto-extraction signal (compliance status is never inferable from ARM/Bicep/Terraform), so this fragment supplies no override to the canonical file’s disposition, options, or default. Ask it exactly as written there.

This closes a real gap: before this fragment referenced the canonical file, Azure’s infrastructure Clarify flow asked no compliance question at all, and estimate-infra.md had to carry a permanent compliance: null special case as a result. Now that this question fires, estimate-infra.md‘s Part 7 hard-trigger-1 first clause is no longer permanently true — it evaluates normally against the recorded compliance array.

Q-A1d — Multi-cloud portability

Disposition: PROPOSED when compute resources are present; N/A otherwise. Default: per the canonical file — no constraint, full compute decision tree.

Canonical question: references/vendored/clarify/clarify-multicloud.md. On this skill, a “yes” answer’s early exit routes to EKS and skips Q-C1 (compute target) in clarify-compute.md — any App-Service-Plan compute that would otherwise default to Elastic Beanstalk routes to EKS instead, overriding Q-C1’s normal default. Record the resolved value as design_constraints.compute_target: { value: "eks", chosen_by: "user", forced_by: "multi_cloud_required" } so Q-C1 can detect the early exit and skip its own row entirely rather than emitting a second, conflicting compute-target row.

Q-A2 — Environment scope

Disposition: DETECTED from the resource groups and name patterns present. Default: every environment found.

Under an obfuscated RDfA report the prod_ / nonprod_ prefixes give this directly. From Terraform it is a name-pattern heuristic (-dev, -prod, d-, t-, s-), so treat it as a strong hint and show what was inferred rather than asserting it.

Q-A3 — Migration window

Disposition: PROPOSED. Default: null — unstated.

Left null rather than guessed. It shapes the timeline in the report and nothing in the design, so an invented window would add false precision to the one output people quote.

Q-A4 — Cost optimization appetite

Canonical question: references/vendored/clarify/clarify-cost-appetite.md. Disposition: PROPOSED. Default: balanced (per the canonical file).

Feeds the aggressiveness slider in knowledge/estimate/rightsizing-thresholds.json. With no utilization data it changes nothing — say so on the row rather than implying it will (the canonical file states this same caveat; repeat it on the sheet, do not drop it).

Q-A5 — Azure baseline spend

Disposition: DETECTED when a billing export was discovered; ESSENTIAL otherwise — there is no way to infer what someone pays.

Anchors the migrate-versus-stay comparison. With no billing source the whole comparison is absent from the report, which is worth stating rather than leaving the reader to notice.

Rows returned

cpu_architecture and compute_target are not here — they belong to clarify-compute.md‘s Q-C3 and Q-C1. This fragment writes design_constraints .compute_target itself ONLY when Q-A1d (multi-cloud) resolves to “yes” — in that case it writes { "value": "eks", "chosen_by": "user", "forced_by": "multi_cloud_required" } and Q-C1 in clarify-compute.md becomes N/A. When multi-cloud resolves to “no” (the default), this fragment writes no compute_target key at all — Q-C1 is the sole owner of that row in the ordinary case, exactly as before this restructure.

Who consumes these

Status — build step 5

Implemented. knowledge/design/azure-region-map.json exists — look the region up there, and do NOT emit a “table absent” flag. Where the row’s same_country is false the move crosses a border: surface that as a residency warning rather than resolving it silently.