Clarify Global

These foundational constraints gate everything downstream — region selection, service catalog, data residency, credits eligibility, compute platform, availability topology, and migration strategy.

Five of these questions are canonical, shared with azure-to-aws — see references/vendored/clarify/. Read the linked file for the question text, options, and interpretation rule; this fragment supplies only GCP’s auto-extraction signal, default, and disposition escalation. Q3 (GCP spend) and Q3.5 (CUDs) are GCP-specific — no shared file, no Azure equivalent (Azure’s commitment story is Reservations/Savings Plans, framed as a finding in Estimate rather than a Clarify question — see estimate-infra.md).

Step 1: Extract before proposing

Resolve from discovery first — a DETECTED row costs the user nothing to confirm, and a question discovery could have answered is a question that should not have been asked.

Step 2: The rows

Q1 — Target AWS region + user geography

Canonical question: references/vendored/clarify/clarify-region.md.

Disposition: DETECTED when the inventory has a single GCP region among PRIMARY compute/database resources — map to the closest AWS region and record chosen_by: "extracted". ESSENTIAL when multiple regions are present, or when there is no infrastructure inventory at all (billing-only or AI-only mode reaching this fragment).

GCP’s auto-extraction shortcut: unlike Azure (which asks a separate user-geography question whenever the map alone can’t decide a CDN strategy), GCP treats a single detected GCP region as sufficient to resolve BOTH the region mapping AND user_geography: "single-region" in one extraction — this is a documented shortcut, not a claim that GCP has independently verified where end users are. State this on the sheet row’s source field ("terraform:single-region-assumed-single-geography") rather than a bare "extracted", so a reader can tell the assumption apart from a genuine multi-signal confirmation.

Default when ESSENTIAL and skipped: answer 1 (single region, closest AWS region to the GCP region present in the inventory).

Q2 — Compliance and regulatory requirements — ESSENTIAL, always

Canonical question: references/vendored/clarify/clarify-compliance.md. No GCP-specific auto-extraction signal exists (compliance status is never inferable from Terraform), so this fragment supplies no override to the canonical file’s disposition, options, or default. Ask it exactly as written there — always ESSENTIAL, never skipped, never silently defaulted to “none.”

Q3 — Approximately how much are you spending on GCP per month in total? — GCP-specific

Auto-extract signal: If billing-profile.json exists, map summary.total_monthly_spend to the spend band below and skip Q3 when unambiguous (chosen_by: "extracted"). If billing is absent or ambiguous, ask Q3.

Rationale: Total GCP spend is the primary input for ARR estimation, which determines credits eligibility tier. Also provides a sanity check for cost estimates when billing data is not uploaded.

Total GCP spend helps me estimate AWS credits eligibility and provides a cost baseline for the migration plan.

1. < $1,000/month
2. $1,000–$5,000/month
3. $5,000–$20,000/month
4. $20,000–$100,000/month
5. $100,000/month
6. I don’t know

Billing enrichment (when Q3 is not skipped): If billing-profile.json exists but extraction was skipped due to ambiguity, show:

Your billing data shows ~$[total_monthly_spend]/month. Does this match your expectation?

Interpret:

Default: 2 — gcp_monthly_spend: "$1K-$5K".

Q3.5 — Do you have active GCP Committed Use Discounts (CUDs)? — GCP-specific

Conditional: Only fires if billing-profile.json exists AND commitments.has_active_cuds == true. N/A otherwise. GCP’s CUD product has no Azure analogue in Clarify — Azure’s Reservations/Savings Plan continuity is surfaced as a finding in estimate-infra.md Part 6, not a question here, because AHUB/Reservations are architecturally different from GCP CUDs (see that file for why).

Rationale: Active CUDs affect migration timing and cost comparison accuracy. If a customer has unexpired CUDs, they’ll continue paying commitment fees even after migrating — this is a sunk cost that affects the migration ROI timeline. Also determines whether to compare against GCP list price or committed rate.

Your billing data shows active Committed Use Discounts (~[effective_discount_percent]% effective discount). CUD timing affects migration ROI — commitment fees continue regardless of usage until the term expires.

1. Yes, and they expire within 6 months
2. Yes, and they expire in 6–12 months
3. Yes, and they have more than 12 months remaining
4. Yes, but I’m not sure when they expire
5. No active CUDs / I don’t know
6. I plan to let them expire and not renew

Interpret:

Default: 5 — cud_status: "none".

Q5 — Multi-cloud portability

Canonical question: references/vendored/clarify/clarify-multicloud.md. Disposition: PROPOSED when compute resources are present; N/A otherwise. Default: per the canonical file — no constraint, full compute decision tree.

GCP’s early exit skips clarify-compute.md‘s Q8 (Kubernetes sentiment) and Q7b (App Engine compute-operational-model) — App Engine routes to EKS instead of its normal Elastic Beanstalk default, overriding the Q7b default the same way it overrides Q8’s.

Q6 — Availability / downtime tolerance

Canonical question: references/vendored/clarify/clarify-availability.md.

Disposition: DETECTED when all Cloud SQL PostgreSQL/MySQL instances agree on the mapped availability_type; ESSENTIAL on conflict or when availability_type is missing on any instance; PROPOSED when no Cloud SQL signal exists but a database resource is present some other way.

GCP’s auto-extraction signal (per the canonical file’s “what a consuming skill supplies” §1): read each google_sql_database_instance‘s availability_type (or config.availability_type):

Resolve this question only when all Cloud SQL PostgreSQL/MySQL instances agree on the same mapped value. multi-az-ha and multi-region are never auto-extracted — those require this question’s Mission-Critical / Catastrophic answers. Cloud SQL REGIONAL maps to multi-az (RDS Multi-AZ), not multi-az-ha (Aurora) — GCP’s REGIONAL HA is not the same tier as Aurora’s HA.

GCP’s default (per the canonical file’s §2 — a deliberate, documented choice, not convergence with Azure’s Single-AZ default): Multi-AZ (answer 2) when unanswered. This is a conservative middle ground: GCP customers arriving with no HA signal at all (billing-only mode, or Cloud SQL absent) are defaulted to a safer tier than Azure’s Single-AZ default, because GCP’s typical inbound estate (Cloud Run / Cloud Functions-heavy) carries less already-provisioned HA context to escalate against than Azure’s VM/Flexible-Server-heavy estates do.

GCP’s escalation rule (per the canonical file’s §3): when Cloud SQL instances disagree, or when availability_type is missing on any instance, escalate to ESSENTIAL rather than defaulting — the multi-instance conflict handling in clarify-assemble.md covers the per-instance breakdown presentation.

Q7 — Maintenance window / cutover strategy — ESSENTIAL, always

No GCP↔Azure canonical file — GCP asks this as one unified question (a single cutover decision governs both compute and database cutover); Azure splits it into two ESSENTIAL questions (VM cutover in clarify-compute.md Q-C6, DB cutover in clarify-database.md Q-D2) because Azure’s VM-replication runbook (MGN) and its database-replication runbook (DMS) are different tools answering different questions. GCP’s compute targets (Cloud Run, GKE, Cloud Functions) do not have an Azure-VM-style “replicate the guest” option, so one cutover question suffices here. This divergence is intentional, not drift — do not unify these into a shared file; the underlying decision shapes are different.

Rationale: Determines cutover strategy and which database migration tooling is recommended. Zero-downtime migrations require significantly more complex infrastructure (blue/green, traffic shifting). With a maintenance window, databases can be taken offline briefly and migrated with native tools — without one, live replication via DMS is required.

Database migration tooling notes:

• Use the in-flight resolved Q13b value (db_size — resolved in clarify-database.md) to select the right tool. Do NOT read preferences.json here: mid-Clarify it does not exist yet, and on a re-run any file present is a prior run’s stale answers. If Q13b is not yet resolved, fall back to the size thresholds below.
• For PostgreSQL databases db_size: "<10GB" or unknown-small: pg_dump/pg_restore is sufficient.
• For PostgreSQL databases db_size: "10-100GB" or "100-500GB": pgcopydb offers parallel table copying and index rebuilding, significantly reducing migration time within the same maintenance window.
• For PostgreSQL databases db_size: ">500GB": AWS DMS strongly recommended regardless of maintenance window — single-pass export/import at this scale is high-risk.
• pgcopydb’s CDC mode requires wal_level=logical on Cloud SQL, which must be enabled explicitly.

The maintenance window determines your migration cutover strategy and which database migration tooling we recommend. Zero-downtime migrations require significantly more complex infrastructure.

1. Yes — weekly maintenance window (e.g., Sunday 2–4am)
2. Yes — monthly maintenance window only
3. No — zero downtime required, must use blue/green or rolling deployment
4. Flexible — we can schedule one if needed
5. I don’t know

Interpret:

Default: 4 — cutover_strategy: "flexible".

Step 3: Rows returned

cpu_architecture is not here — it belongs to clarify-compute.md, same reasoning as Azure’s fragment: whether it is a question at all depends on which compute is present.

Who consumes these

Status — build step 5 (restructure)

Implemented. Restructured from the pre-fragment monolithic clarify.md into the fragment-returns-rows / assembler-owns-conversation pattern shared with azure-to-aws. Five of these seven questions (region, compliance, availability, multi-cloud, cost-appetite — the last lives in Category E below, not in this fragment, per references/vendored/clarify/clarify-cost-appetite.md § “What a consuming skill supplies”) now read their question text and options from the canonical references/vendored/clarify/ files instead of carrying an independent copy. Q3/Q3.5/Q7 remain GCP-owned with no shared file, because they have no Azure equivalent or a genuinely different decision shape.