Schema Estimate Infra

The fields aws_monthly_premium, aws_monthly_balanced, aws_monthly_optimized (under projected_costs) and option_a_premium, option_b_balanced, option_c_optimized (under cost_comparison) are three pricing scenarios for the same GCP->AWS mapping in aws-design.json. They are not three alternative Terraform roots.

scenario_deltas (required with three tiers): projected_costs.scenario_deltas itemizes, per non-Balanced scenario, what concretely differs from Balanced for this stack — the estimate engine already knows (it priced the differences); this field makes the reader see them instead of inferring from generic labels. Each entry names the change AND its consequence when the change is architectural, not just financial (e.g. dropping a NAT Gateway is a network-posture change, not merely savings):

Validation: when all three tiers are present, scenario_deltas.premium and scenario_deltas.optimized are non-empty string arrays; every architectural delta (resource added/removed vs the Balanced design) states its consequence, and commitment-based savings name the commitment. Readers of pre-extension artifacts must tolerate absence.

How to read: Scenario order is highest -> middle -> lowest monthly AWS estimate for the modeled architecture. Balanced is the primary comparison row vs the GCP baseline. Premium and Optimized are bounds (HA vs cost-optimization skew).

Terraform: When the Generate phase produces terraform/, it implements one infrastructure baseline aligned with the Balanced scenario (aligned_with_estimate_tier in the migration_summary output). Premium and Optimized remain estimate-only unless the customer edits IaC. See references/phases/generate/generate-artifacts-infra.md (terraform/README.md, main.tf header comment).

estimation-infra.json schema

recommendation block in estimation-infra.json

The recommendation block is the single source of truth for migrate/stay guidance. Consumed by Estimate chat output AND HTML migration report (Section 0). Do not duplicate this logic in the report template.

Decision outcome (additive — v2 fields): outcome expresses the decision, independent of the execution-path vocabulary above. path answers “how would we migrate”; outcome answers “should we, now”. Both are written; consumers that only read path keep working.

Validation:

• path is one of: "migrate_optimized", "migrate_phased", "stay"
• path_label matches the corresponding display string for path
• outcome, when present, is one of: "go", "conditional_go", "defer_for_evidence", "stay" (readers MUST tolerate absence — pre-extension artifacts)
• conditions is a non-empty array of strings when outcome == "conditional_go"
• decision_basis, when present, has measured, assumed, and unknown string arrays (any may be empty)
• would_flip_if, when present, is an array of strings
• outcome == "stay" requires path == "stay"; outcome == "defer_for_evidence" may pair with any path (path shows what migration would look like)
• migrate_if and stay_if are non-empty arrays of strings
• Scope rule (stay_if / conditions): the whole-stack stay_if list is reserved for factors that argue for staying entirely (e.g. compute economics dominating a sparse-traffic app). A factor affecting a single track (one AI workload’s quality eval, one deferred service’s specialist plan) is track-scoped: it goes in conditions[] prefixed with its track (“AI image: …”) and/or shapes that track’s entry in track_outcomes — it MUST NOT appear as a whole-stack stay reason. This generalizes the existing BigQuery rule (deferral is not a reason to stay unless analytics must cut over in the same window) to every track.
• track_outcomes, when present, is an array of {track, outcome, note}; track is one of compute_database, ai_text, ai_image, ai_agentic, analytics (use only tracks that exist in the design); outcome uses the same enum as recommendation.outcome. Required when the stack has more than one track (AI artifacts and/or deferred services alongside infrastructure). The stack-level outcome is then a summary: it must not be worse than the compute/database track’s outcome merely because a secondary track has a condition — a failing track demotes that track, never the stack. Readers of pre-extension artifacts must tolerate absence.
• next_steps is a non-empty array of strings
• Block is REQUIRED in estimation-infra.json output (Part 7 must write it; Part 7 always writes the v2 fields)

Observability Entry in projected_costs.breakdown

When Part 2B of estimate-infra.md produces an observability cost, it is included as an entry in projected_costs.breakdown[] with this shape:

Validation for observability entry:

• components keys are exactly: log_ingestion, log_storage, custom_metrics, alarms, tracing
• volume_source is one of: "heuristic", "billing" (reflects log volume source — the largest cost component; metrics are always heuristic regardless of this field)
• tracing is 0 when no tracing signals detected in source — do not add X-Ray costs unprompted
• mid equals the sum of all components values
• This entry REPLACES any CloudWatch/log/metric portion in the “Supporting” row — never both

architecture_comparison (optional — Graviton/ARM64)

Present in estimation-infra.json only when preferences.json → design_constraints.cpu_architecture.value is graviton or mixed (see estimate-infra.md Part 2C and shared/schema-graviton.md). Omit entirely for x86.

Validation for architecture_comparison entry:

• All four numeric fields present; savings_amount equals x86_equivalent_monthly − graviton_monthly
• savings_percent equals savings_amount / x86_equivalent_monthly × 100 (one decimal)
• Models the hourly price discount only — never performance-uplift capacity reduction
• Not a fourth pricing tier — Graviton is the architecture within the Balanced/Premium/Optimized totals
• Canonical field definitions live in shared/schema-graviton.md

Output Validation Checklist

• design_source is "infrastructure"
• pricing_source.status is "cached", "cached_fallback", or "unavailable" (pricing is cache-only — there is no "live" status because no live pricing tool is configured, and there is no "cached_stale" status either: a stale cache is status: "cached" with fallback_staleness.is_stale: true)
• pricing_source.fallback_staleness.is_stale is true when the cache is older than its staleness threshold, with a non-null staleness_warning; false otherwise
• accuracy_confidence matches the pricing mode (±5-10% for cached, ±15-25% for fallback)
• current_costs.source is "billing_data" if billing-profile.json was used, "inventory_estimate", "preferences", "user_provided" (asked during estimate), or "unavailable" (user declined) otherwise
• current_costs.gcp_monthly matches billing-profile.json total (if used) or is a reasonable estimate
• projected_costs has all three tiers (premium, balanced, optimized)
• Tier semantics: Three totals are scenario $ only (same design); Balanced matches generated Terraform baseline — see Cost tiers section above; user-facing labels must use the subtitles there (also estimate-infra.md Present Summary / generate-artifacts-report.md)
• projected_costs.breakdown covers compute, database, storage, networking, supporting services, and observability
• Every service in aws-design.json is represented in the cost breakdown
• projected_costs.breakdown observability entry (when present) REPLACES any CloudWatch/log/metric costs in the “Supporting” row — never double-count
• cost_comparison shows all three options with monthly and annual differences
• cost_comparison.commitment_context is present if billing-profile.json has commitments.has_active_cuds == true; omitted otherwise
• migration_cost_considerations.billing_data_available is true if billing-profile.json exists, false otherwise
• If billing_data_available is true: migration_cost_considerations.categories lists GCP vendor egress / data transfer only (never human or professional-services costs)
• If billing_data_available is false: migration_cost_considerations.categories is empty; note explains that billing data is required for GCP egress fee estimates
• roi_analysis presents recurring monthly/annual savings (or increase) per tier
• roi_analysis is honest — if migration increases cost, say so and justify with non-cost benefits
• optimization_opportunities only includes strategies relevant to the designed architecture, per the eligibility matrix in references/shared/ri-sp-eligibility.md — never claim Database Savings Plan coverage for an ElastiCache target that isn’t Valkey, and never claim DynamoDB Reserved Capacity eligibility for on-demand or Standard-IA tables
• Each optimization_opportunities[] entry includes required fields: opportunity, target_services, savings_percent, implementation_effort, description. Optional fields: type, savings_monthly (null when post-migration sizing unavailable), commitment, timing, prerequisite, references, alternative
• Compute Savings Plans entries for Cloud Run migrations MUST NOT include savings_monthly sized from GCP billing — use savings_monthly: null and timing: post-migration
• Database Savings Plans entries MAY include savings_monthly only when projected DB on-demand exceeds $50/month
• optimization_opportunities savings are incremental to Balanced on-demand totals — not additive on Optimized tier (which already embeds reservation/Spot assumptions)
• The Cost Optimization Opportunities section renders even when the design has no RI/SP-eligible service — per ri-sp-eligibility.md‘s three-state model, state explicitly which state the design landed in rather than omitting the section
• financial_summary provides a clear executive-level view
• recommendation block exists with path, path_label, migrate_if, stay_if, and next_steps all populated
• recommendation.path is one of: "migrate_optimized", "migrate_phased", "stay"
• recommendation.next_steps includes actionable items
• No references to AI-specific costs (those belong in estimate-ai.md)
• No references to billing-only estimates (those belong in estimate-billing.md)
• All cost values are numbers, not strings
• Output is valid JSON