Azure To AWS

_fragment: infra _of_phase: estimate _contributes:

• estimation-infra.json

Estimate — Infrastructure Cost Engine

Fragment unit. See estimate.md for how it is composed into the phase. Prices every service in aws-design.json, derives the Azure baseline it is compared against, and produces two AWS totals. The artifact write, the decision gate, and the phase-status update belong to estimate-assemble.md.

Execute ALL parts in order. Do not skip or optimize.

Step 0: Pricing mode

Execute references/vendored/estimate/pricing-mode.md as this step: staleness check, the region check, the rate-row check, the pricing-mode display, and the per-rate-row hierarchy including partial, estimated and unavailable. Do not restate or fork that logic here.

Two of its steps fire on nearly every Azure run, so expect them:

• Region. The cache is us-east-1. Azure source regions map to AWS regions through knowledge/design/azure-region-map.json, and a European Azure region maps to a European AWS region — so the design's target_region differs from the cache region on most estates.

• Rate rows. The knowledge/design/*-sizing.json tables emit current-generation types chosen to fit the Azure SKU. They were authored against Azure SKUs rather than against the rate card, so a design can name a type the rate card has no row for. Resolve every rate key before computing anything, so the holes are known up front instead of discovered per line.

Step 1: Prerequisites

The entry gate (design completed, inputs present and valid, services[] present and every entry well-formed) is enforced by this phase's _preconditions per INTERPRETER.md § Gate protocol; it has already passed. Then read:

1. $MIGRATION_DIR/aws-design.json — services[], deferred[], warnings[], target_region, clusters[].

2. $MIGRATION_DIR/preferences.json — baseline, design_constraints, data, and licensing (whose _fired flag decides Part 3's delta line).

3. $MIGRATION_DIR/azure-resource-inventory.json — the source SKUs the 1:1 lift is priced from, plus iac_metadata.

The all-deferred design

design.md allows services[] to be empty when every discovered resource was deferred to a specialist or skipped — a Synapse-and-Managed-Instance-only estate is the typical shape. That design is valid and it reaches this phase, so this phase must carry it through rather than stopping: Generate requires a completed Estimate, and its baseline-only path (core files plus baseline.tf) is the right output for exactly this estate.

Confirm the case first, then run every part below with an empty service set:

• Confirm it is accounted for. Every azure-resource-inventory.json resource must appear in deferred[] or in a warnings[] skip entry. One that appears in neither is a dropped resource, not a deferral — GATE_FAIL with the _preconditions wording; never price around it. A skip is not a deferral. A resource group recorded as a skip, for example, is not a specialist engagement.

• Count them apart. deferred_count is len(deferred[]). Skipped resources are not added to it, and they do not raise the complexity tier. A mixed estate (some deferred, some skipped, services[] empty) reports only the deferred entries as specialist work.

• Part 2 prices no workload. projected_costs.breakdown carries no service lines. The estate-wide lines still appear so a reader sees they were considered: the Part 2C observability line and both Part 2C-2 standing lines are emitted at $0 with a basis of "no generated service". Both workload totals are 0, every scenario key is 0, and rightsizing_delta.explanation says why the delta is 0. That sentence names deferred resources only when deferred[] is non-empty ("the deferred resources have no AWS-side line to right-size"). When every resource was skipped, it says "nothing was mapped to an AWS service; skipped resources are not a specialist engagement."

• Say what the $0 is, and what it is not. The $0 is the priced workload. It is not the price of baseline.tf. Those controls are unpriced on every path, including this one (see "Account baseline controls are not in these totals" below). Emit all_services_deferred only when deferred[] is non-empty, and baseline_controls_unpriced on every path. Carry the matching sentence into recommendation.conditions and would_flip_if[]. When deferred[] is non-empty, the condition is that those named workloads' AWS cost is unestimated until a specialist designs them. When deferred[] is empty, do not tell the reader a specialist is required. deferred_bears_azure_cost still fires per deferred[] entry when the Azure baseline includes that entry, so the comparison is not read as a saving.

• is_floor stays false here unless a priced line was excluded. The unpriced baseline is called out by baseline_controls_unpriced, not by pretending the workload total is a floor of those controls.

• Parts 7 and 8 run normally. service_count is 0. The recommendation is never go here — Part 8 soft trigger 9 fires on the empty services[], so the derivation yields conditional_go with the condition from the bullet above, or defer_for_evidence if a hard trigger fires.

• The decision gate is still presented (estimate-assemble.md Step 2), with the pack's $0 clause replaced by the sentence from the bullet above. The "Deferred to specialists" line lists deferred[] only, and is omitted when that array is empty. Option C is offered: Generate's baseline-only output is a real deliverable for this estate.

Part 1: The Azure baseline

The comparison is the point of this phase, so the baseline's quality matters as much as its value. Use the best available source; first match wins.

config.measured_utilization (discover-rdfa.md § Step 3, this PR) feeds right-sizing confidence in Part 2B below, not the Part 1 baseline above — the two are different consumers of RDfA, and this PR lands only the right-sizing one.

Say plainly which rungs are reachable. On a Terraform-only estate — every estate today — rungs 1, 2 and 4 cannot fire for a dollar baseline: rung 1 needs a discovery source that is not built, rung 2's own CSV carries no dollar signal at all (see above), and rung 4 needs Azure rates this skill does not ship. So the baseline is the user's stated figure, or nothing. Do not report rung 4 as attempted; there is nothing to attempt it against.

Record the rung on the artifact, and never present a derived figure as an invoice:

"current_costs": {
  "azure_monthly": "<figure or null>",
  "source": "<one of the rung values above>",
  "accuracy": "<'as stated by the customer' | 'invoice data' | 'unavailable'>",
  "baseline_note": "<REQUIRED for every source except cost_management_export>",
  "currency": "<preferences.baseline.azure_monthly_spend.currency, default USD>"
}

For user_stated, baseline_note is: "This is the figure you gave us, not an invoice we read. It may include Azure charges from outside this estate (other subscriptions, support plans, marketplace items) or exclude discounts you hold, so treat the comparison as directional."

The reservation $0 trap

A reserved VM, or capacity under a savings plan, reports $0 in consumption data. It is not free — it was pre-paid, and the money left the customer's account earlier. Pricing the baseline from the literal figure understates current Azure spend, which makes AWS look worse than it is and can invert the recommendation.

So: a $0 consumption figure against a resource that exists means RESERVED, never free. Price that resource at its pay-as-you-go rate as the baseline stand-in, and record the substitution:

"reservation_substitutions": [
  {
    "azure_id": "<the resource>",
    "reported_consumption": 0,
    "substituted_basis": "<the rate used, and where it came from>",
    "reason": "A $0 consumption figure on an existing resource indicates a reservation or a savings plan, not zero cost."
  }
]

This rule is unreachable today and must not be presented as exercised. A $0 consumption figure only appears in Cost Management or RDfA data — rungs 1 and 2, both deferred. A user_stated baseline has no per-resource figures at all, so reservation_substitutions is an empty array: the rule is a contract for when the billing source lands, not something this run tested. Write the empty array rather than omitting the key, so its emptiness is visible to a reader.

Metrics lookback affects confidence, not just precision

When metrics exist, evaluate each row: metric_error must be false, sample_count must be positive, and window_days must be numeric and meet confidence_rules.min_window_days. Error/empty rows and null/unknown windows are traceability, not measured sizing evidence; fall back to inferred and say why. Current RDfA exports omit query bounds, so never replace null with rdfa_metadata.lookback_days. A P95 of zero remains eligible when positively sampled.

Part 2: Price the design TWICE

Dual output is the shape of this phase, not an option a user asks for. Both totals are always produced.

Reporting only the lift overstates the bill. Reporting only the right-sized figure hides the work that produced the saving and leaves the customer unable to check it against their own expectations. Report both, always, plus cost_comparison stating the delta between them.

2A: The 1:1 lift

For each services[] entry, price the AWS service at the capacity implied by the source resource — from the inventory entry's config, not from aws_config:

• A source VM's SKU gives its like-for-like AWS instance via knowledge/design/vm-ec2-sizing.json. The row's own vCPU/memory columns for both sides are what make "like-for-like" checkable rather than asserted.

• A source App Service Plan's SKU and worker count give the EB instance size and count via knowledge/design/appservice-eb-sizing.json.

• A source Flexible Server SKU gives the RDS class via knowledge/design/flexible-server-rds-sizing.json; its storage_mb gives allocated storage.

• Where the design dropped or shrank a resource, the lift keeps it at full size. That is the entire point of the lift.

2B: The right-sized target

Price aws_config as the design states it. Right-sizing arrives from two distinct places, and conflating them is the mistake to avoid:

Utilization-based right-sizing is unreachable without a metrics source, and rightsizing-thresholds.json _precondition forbids applying its bands to a declared SKU — a SKU is what was bought, not what is used. Declared-waste right-sizing is reachable from Terraform alone.

So on a Terraform-only estate the delta comes entirely from declared waste, and it can legitimately be $0. When it is, say so and say why in the delta line itself: "No utilization data was discovered, so no size was reduced on measured evidence; this delta reflects declared waste only." A $0 delta presented without that sentence reads as a broken calculation — and a reader who assumes right-sizing was attempted and found nothing has been actively misled.

Right-sizing never revisits the service choice. The rubric's six criteria picked the service; this fragment only picks a size within it. If no size in the chosen service fits, that is a finding for the report, not a reason to re-run the rubric.

Per-service formulas

Rates come from the named keys in references/vendored/pricing/aws-infra-pricing.json. Do not restate a rate here. hours_per_month is _meta.hours_per_month (730).

Account baseline controls are not in these totals

Generate always emits baseline.tf: CloudTrail and its log bucket, GuardDuty, and the budget, plus Config and Security Hub when a named framework is declared. This cost engine has no rate row for those controls. Do not price them from memory, and do not add them into aws_monthly_balanced or either total.

Record the omission on every run, including a nonempty estate and the all-deferred path:

• Emit baseline_controls_unpriced (vocabulary below).

• Set projected_costs.baseline_controls to { "priced": false, "omitted_from_totals": ["cloudtrail_logs", "guardduty", "budget"] } and append "config" and "security_hub" to omitted_from_totals when the declared compliance set includes soc2, pci, hipaa, or fedramp.

• The note on that object says the totals exclude those controls, and that the budget limit max(50, ceil(aws_monthly_balanced * 1.2)) is a floor on the priced workload, not a price of GuardDuty or Config.

is_floor does not flip to true for this omission. A floor means a workload line was excluded. This omission has its own warning so a deferred-workload caveat is not asked to cover it.

The breakdown line shape

One entry per designed service, in projected_costs.breakdown[]. The field names are fixed, because both totals and every downstream reader key on them:

{
  "service_id": "<from aws-design.json services[].service_id>",
  "aws_service": "<from the design>",
  "lift_monthly": "<Part 2A figure, or null>",
  "right_sized_monthly": "<Part 2B figure, or null>",
  "pricing_source": "<cached | partial | live | cached_fallback | estimated | unavailable>",
  "basis": "<REQUIRED — the rate keys and arithmetic behind the figure, or why there is none>",
  "components": { "<sub-line>": "<figure or null>" },
  "assumptions": [
    "<any quantity taken from estimate-defaults.json or a rate file's _basis rather than from the estate>"
  ],
  "exclusion_reason": "<no_rate | partial_rate | no_quantity — ABSENT when the line is priced>",
  "excluded_from_total": "<true only alongside an exclusion_reason>",
  "missing_component": "<REQUIRED for partial_rate — names what is unpriced>",
  "is_floor": "<true for a partial_rate line>"
}

basis is required on every line, including the $0 ones — "a VPC is not billed" is the answer to a question a reader would otherwise have to assume. components must sum to the line's own figure wherever it is present, or the breakdown contradicts itself.

Lambda has rates but no invocation data. The rates are in the pricing file, so this is not a missing-rate case: IaC declares no request volume, and a source consumption plan provisions no worker capacity, so there is no source-side figure to multiply them by. Emit monthly: null with exclusion_reason: "no_quantity" and a stated reason — never a remembered default request count. lambda._no_invocation_data_note says the same thing at the data layer.

Services with no rate row — do not paper over them

_absent_services in the pricing file names the services a design can emit that have no rates there, and none in the gcp-to-aws cache either. Today those are DocumentDB, FSx for Windows File Server, and the Windows licence adder. Pricing is cache-only, so there is no lookup that can resolve them — for each:

1. Set that line's pricing_source to "unavailable" and its exclusion_reason to "no_rate".

2. Exclude it from both totals, with excluded_from_total: true, but keep the line in the breakdown.

3. Add to warnings[]: "Pricing unavailable for <service_id> (<aws_service>) — not in the pricing cache and no formula constant carries its rate. This line is excluded from the totals, so both totals are floors."

4. Add the service_id to pricing_source.services_with_missing_fallback[].

Never substitute a neighbouring rate. db.t3.medium on a DocumentDB line is not an rds_postgresql class: different service, and those rates are baked-in Multi-AZ, so the wrong table would be wrong twice over. A near-miss rate is indistinguishable from a correct one in the output, which is what makes it worse than a hole.

The Windows line is partial — neither silently wrong nor thrown away

When a service carries license_model: "License Included" (or the design otherwise states a Windows or SQL Server target), the ec2.instances rate is Linux — ec2._windows_note says so — and the file carries no licence adder. A Windows general-purpose instance costs roughly twice its Linux row.

Do not price it silently at the Linux rate: that understates the estate's most expensive compute line, in the direction that flatters AWS. Do not mark it unavailable either: the base rate is real, and discarding it loses information the customer needs. Instead, per pricing-mode.md rung 1b:

{
  "service_id": "<id>",
  "monthly": "<the Linux-rate figure>",
  "pricing_source": "partial",
  "exclusion_reason": "partial_rate",
  "excluded_from_total": true,
  "missing_component": "Windows Server licence (License Included)",
  "is_floor": true,
  "note": "Priced at the Linux on-demand rate. Windows Server 'License Included' costs materially more — roughly 2x for a general-purpose size — and no Windows rate or per-vCPU licence adder is in the pricing cache. This line is a FLOOR and is excluded from the decision-grade total."
}

and add the service_id to pricing_source.services_by_source.partial[].

Note how this meets the architecture choice: the design defaults to x86_64 because of Windows and .NET prevalence. So the estates where that default is load-bearing are exactly the estates where this pricing hole bites hardest. Say that in the report rather than leaving the reader to work it out.

When the rate exists but describes a different configuration

A distinct failure from a missing rate, and worse, because the arithmetic looks complete. rds_postgresql.instances rates are Multi-AZ — that section's multi_az_handling is baked_in and its _note says the rate already includes it. There is no single-AZ RDS table anywhere. So a single-AZ design priced from that table is roughly 2× too high, on what is usually the largest line in the estate.

Do not silently halve it: a halved Multi-AZ rate is a fabricated rate wearing arithmetic. Do not exclude the line either — it is the biggest number the customer needs. Price it from the table that exists, and label the direction of the error:

{
  "rate_configuration_mismatch": {
    "designed": "single-AZ",
    "rate_describes": "Multi-AZ (rds_postgresql.multi_az_handling is baked_in)",
    "direction": "overstates",
    "magnitude": "roughly 2x on this line",
    "why_not_corrected": "No single-AZ RDS rates exist here or in the gcp-to-aws cache, and halving a Multi-AZ rate would invent one."
  },
  "is_ceiling": true
}

This makes the totals wrong in BOTH directions at once, and that must be said rather than netted off. Excluded lines push every total down; a Multi-AZ rate on a single-AZ design pushes the largest line up. A total described as a simple "floor" while carrying a 2× overstatement on its biggest component is not honest. State both, and do not offset them — they do not cancel in any knowable amount.

Carry the mismatch into recommendation.conditions too. Repricing single-AZ RDS is one of the highest-value corrections available to this estimate, and it is completely invisible from the number itself.

The three reasons a line is excluded, and the one rule that decides

A line leaves the totals for exactly one recorded reason:

The rule: price what is quantified, and exclude a line only when its PRIMARY cost driver is unpriced or unquantified. A missing minor component does not remove a line — it is priced on what is known and the omission is named in assumptions[]. MSK is the worked example: brokers are the primary driver and they are quantified, so the line is priced, while per-broker storage is not sized by the design and appears as an assumption rather than deleting the line. A Windows instance goes the other way — its licence is roughly half the line, so what is left is a floor, not an estimate.

This is a materiality judgement, stated so it can be argued with rather than discovered. When in doubt, price the line and name the assumption: an under-stated line the reader can see beats a missing line they cannot.

Part 2C: Observability (CloudWatch)

Azure bundles a Log Analytics allowance, so many customers have never seen a separate line for it. CloudWatch bills from the first GB. Surface it here so it is not a surprise after cutover.

Every quantity below comes from knowledge/estimate/estimate-defaults.json. Read them from there; do not supply a remembered figure.

1. Log volume — log_volume_gb_per_service, keyed by service kind and counted per instance, node, broker or environment (not per cluster). Sum across the design. This is a heuristic and it is the coarsest input in the estimate.

2. Custom metrics — cloudwatch_defaults.custom_metrics_per_service × service count, floored at custom_metrics_floor.

3. Alarms — max(alarms_floor, alarms_per_service × service count).

4. Cost = log_gb × cloudwatch.log_ingestion_per_gb

   • log_gb × cloudwatch.log_storage_per_gb_month × retention_months

   • metrics × cloudwatch.custom_metric_month

   • alarms × cloudwatch.standard_alarm_month, with retention_months from cloudwatch_defaults. Add X-Ray (cloudwatch.xray_per_million_traces) only when tracing is actually detected in the source; otherwise it contributes a cost that traces back to no evidence.

Emit as a single breakdown line, service_id: "observability-cloudwatch", carrying volume_source: "heuristic", band_percent: 35, and the resulting low and high alongside its right_sized_monthly, with components broken out as log_ingestion, log_storage, custom_metrics, alarms and tracing. Label it: "Azure Monitor includes a Log Analytics allowance; CloudWatch charges from the first GB. Actual cost depends on log verbosity and retention."

It is the one line that is not a designed service, so it has no entry in aws-design.json services[] and must not be counted as one. It is also estate-wide, so its per_cluster attribution is cluster_id: null rather than a cluster picked arbitrarily.

This entry REPLACES any CloudWatch row a supporting-services line would otherwise add — never double-count.

The ALB line's LCU count comes from the same file (alb_lcu_estimate.default_lcus), for the same reason.

Part 2C-2: Standing network charges (NAT Gateway + load balancer)

<!-- Precedent: gcp-to-aws references/phases/estimate/estimate-infra.md:170-171 prices the NAT line "From VPC design" and the ALB line "From compute service count" — i.e. from the DESIGN, not from a services[] row. Mirror that here as estate-wide STANDING lines, in the same spirit as Part 2C's estate-wide observability line. -->

Two network charges are structural to the target architecture and are billed whether or not any services[] entry names them. So, exactly like the Part 2C observability line, they are emitted from the design, not from a services[] row:

1. Standing NAT Gateway line — derived from the VPC/AZ design, priced whenever a NAT will be emitted. Generate's default posture puts compute/database in private subnets across a 2-AZ VPC (shared posture: skills/tf-best-practices/references/security-posture-rules.md — VPC spans ≥2 AZ, public+private subnets, NAT for private egress), and Azure's NAT Gateway is regional while AWS's is zonal, so one source resource becomes one per AZ. When the AZ count is not explicit upstream, default N to 2 (the 2-AZ private-subnet VPC Generate emits) and price nat_gateway.monthly_fixed × 2 (+ nat_gateway.per_gb_processed × GB when a data volume is known; otherwise state the per-GB component as unquantified in assumptions[]). Record the assumption in assumptions[]: "default 2-AZ private-subnet VPC per generate posture; AZ count not explicit upstream." Emit this line even when no services[] entry maps to a NAT Gateway — a private-subnet design still pays it. service_id: "standing-nat-gateway", cluster_id: null.

2. Standing ALB/NLB line — derived from the edge/compute design. A public edge (Application Gateway / Front Door / public L7 LB → ALB) prices from alb.monthly_fixed + alb.per_lcu_hour × 730 × LCU; an L4 edge (→ NLB) prices from nlb.monthly_fixed + nlb.per_lcu_hour × 730 × LCU using the new nlb rate row. The LCU count is alb_lcu_estimate.default_lcus. Emit it even when no services[] entry names a load balancer — except where a LoadBalanced Elastic Beanstalk environment already provisions its balancer (that ALB is priced inside the EB line; do not re-add it — the double-balancer trap). service_id: "standing-load-balancer", cluster_id: null.

The standing NAT line is $0 strictly for a design that emits NO NAT at all — a fully-public design, or a SingleInstance Elastic-Beanstalk-only estate, with no private subnets. Reserve the zero-with-basis note for that genuine no-NAT case (say so in the basis); a private-subnet design is NOT a $0 case — it prices the 2-AZ standing NAT above. The standing balancer line stays $0-safe as before: a design whose only balancer is already inside an EB line emits it at$0with its own note. Emitting a genuine no-NAT / no-standalone-balancer line zero-with-basis rather than omitting it matches the Part 2 convention that a considered line stays visible.

Part 2D: Totals

lift_total        = sum(per-service lift costs)        — excluding every line with an exclusion_reason
right_sized_total = sum(per-service right-sized costs) — excluding every line with an exclusion_reason

Each total must equal the arithmetic sum of its own per-service lines. A total that does not reconcile is a gate failure, not a rounding note. When any line was excluded, both totals are floors, and every presentation of them says so.

Excluded lines still appear in the breakdown, carrying their exclusion_reason, whatever partial figure is known, and excluded_from_total: true. Dropping them from the breakdown entirely would make the estate look smaller than it is, which is the failure this whole section exists to prevent.

Part 2E: The three pricing scenarios the shared schema requires

The dual output does NOT replace the three scenarios, and this is the easiest thing in the phase to get wrong. They are different axes:

references/vendored/estimate/estimation-infra.schema.json lists all three scenario keys under projected_costs.required. It has no additionalProperties: false, so the azure lift / right_sized keys are legal additions — but "no additionalProperties: false" permits ADDING, it does not permit OMITTING a required key. An artifact carrying only the dual output fails the schema this phase declares.

The anchor: aws_monthly_balanced IS the right-sized total. They are the same number by definition — the recommended design at on-demand rates — so emit them equal rather than computing a second figure that could drift from it.

Derive the other two as stated adjustments off Balanced, never as fresh rate lookups:

State the discount rate and the two subtotals, so the arithmetic is checkable without trusting the author. And note the eligibility carefully on an Azure estate: MSK has no RI or Savings Plan product, so it belongs in the ineligible subtotal even though it looks like the kind of thing that would be covered.

Every scenario figure inherits the floor. If any line was excluded, all three scenarios are floors, and Optimized is the most misleading of them — a discounted floor reads as the cheapest credible number in the artifact when it is the least complete.

Two shape constraints the schema imposes

• projected_costs.breakdown is an OBJECT, not an array — keyed by service_id, values being the line shape above, plus a total key holding the Balanced total. This matches what the other skills emit; an array here is a schema violation that _validate_json will not catch, because it checks parseability rather than conformance.

• accuracy_confidence is a STRING, e.g. "floor — five lines unpriced; ±5-10% on the rest". Any structured detail belongs in pricing_source.message or its own key, not here.

Part 3: Comparison, and the licensing delta

Azure vs AWS

When Part 1 produced a baseline from any rung except unavailable, present:

• The Azure monthly baseline, labeled with its rung and accuracy, repeating baseline_note next to the number whenever it is not invoice data.

• Both AWS totals — lift and right-sized — each marked a floor when any line was excluded.

• The difference against each, monthly and annual.

• A per-cluster breakdown of the right-sized total, using clusters[] from the design, so the customer can see which part of the estate drives the bill.

"cost_comparison": {
  "azure_monthly_baseline": "<Part 1 figure or null>",
  "baseline_source": "<rung>",
  "lift": { "aws_monthly": "<lift_total>", "is_floor": true, "monthly_difference": "<lift - azure>", "annual_difference": "<x12>", "percent_change": "<+/-X%>" },
  "right_sized": { "aws_monthly": "<right_sized_total>", "is_floor": true, "monthly_difference": "<right_sized - azure>", "annual_difference": "<x12>", "percent_change": "<+/-X%>" },
  "rightsizing_delta": {
    "monthly": "<lift_total - right_sized_total>",
    "annual": "<x12>",
    "basis": "<'declared_waste' | 'utilization' | 'both' | 'none'>",
    "explanation": "<REQUIRED — and REQUIRED to say WHY whenever monthly is 0>",
    "declared_waste_found": ["<REQUIRED whenever the IaC declares waste, even when it moves no dollars>"],
    "what_would_change_this": "<what evidence would make the delta non-zero>"
  },
  "per_cluster": [
    {
      "cluster_id": "<a cluster_id from aws-design.json clusters[], or null for an estate-wide line>",
      "right_sized_monthly": "<sum of this cluster's priced lines>",
      "is_floor": "<true when any of this cluster's lines was excluded>",
      "lines": ["<service_id, ...>"],
      "note": "<REQUIRED when the figure is 0 and the cluster is not actually free>"
    }
  ]
}

declared_waste_found is not optional decoration. The idle-capacity finding is often the estate's clearest cost problem, and it can be real while moving no dollars — because the design flagged it rather than removing it, or because its line was excluded. Losing it on the grounds that the delta is zero drops the finding a customer would most want.

Every per_cluster figure of $0.00 needs its note. A cluster whose every line was excluded reads as free, and it is not — it is unpriced. The per-cluster figures plus any cluster_id: null estate-wide line must sum to the right-sized total.

Also emit financial_summary, which restates the headline in the opposite sign convention because report readers expect "savings" to be positive:

"financial_summary": {
  "azure_monthly": "<baseline or null>",
  "aws_monthly_right_sized": "<right_sized_total>",
  "aws_monthly_is_floor": "<true when any line was excluded>",
  "monthly_savings_right_sized": "<azure - aws; the NEGATION of cost_comparison.right_sized.monthly_difference>"
}

The two sign conventions are the trap: cost_comparison and roi_analysis use difference = AWS − Azure (negative means AWS cheaper), and financial_summary uses savings = Azure − AWS (positive means AWS cheaper). They are the same fact and must be exact negations of each other. Never print either as a bare signed value.

Sign convention: difference = AWS − Azure, so a negative number means AWS is cheaper. Never print a bare signed value; always label it, e.g. "AWS is $X/mo cheaper".

When current_costs.source == "unavailable", set azure_monthly_baseline to null and present the AWS totals alone: "No Azure baseline was established, so these are AWS costs without a comparison. Tell us your approximate Azure monthly spend and we will produce the side-by-side."

The licensing delta line

Render this line if and only if preferences.licensing._fired is true. When Clarify's licensing category did not fire, no licensing line appears anywhere — not as a zero, not as "not applicable".

It is one delta row, not a cost model. What it says depends on licensing.windows_model:

Two facts to carry across from preferences.licensing:

• ahub_in_use: false means the Azure baseline carries an unreduced Windows rate, so the Azure side is not understated on licence grounds. When it is true, the Azure baseline already benefits from Hybrid Benefit and the comparison is not like-for-like — say so rather than comparing anyway.

• Anything in licensing.blockers[] is a prerequisite, not a cost. An Azure-Edition Windows image that AWS Application Migration Service refuses is work that must happen before replication starts; it is not a line item. Reference it, and do not price it.

"licensing_delta": {
  "fired": true,
  "windows_model": "<from preferences>",
  "windows_workload_count": "<N>",
  "windows_vcpu_total": "<N>",
  "ahub_in_use": false,
  "monthly_delta": null,
  "delta_basis": "<the rate and where it came from, or why this is null>",
  "note": "<per the table above>",
  "blockers_are_not_costs": ["<one entry per licensing.blockers[] entry, naming it and why it is a prerequisite>"]
}

blockers_are_not_costs entries must carry no dollar figure. Putting one there converts a scheduling fact into a fabricated cost, which is exactly the confusion the key exists to prevent.

monthly_delta is null whenever the Windows rate is unavailable. A null with a stated reason is honest. A remembered per-vCPU figure is not, however plausible it looks.

Part 4: Migration cost considerations

Azure charges egress and Heroku does not, so do not carry a "no egress fees" framing across from another skill. Categories — none of them priced without a data volume:

No human labor. No professional-services figure, no people-time, no day rate, no "N engineer-weeks × $X". Effort belongs to the timeline band, never to a dollar column. This holds across every part of this fragment.

Part 5: ROI

Present the monthly and annual difference between the Azure baseline and each AWS total. If AWS is cheaper, state the saving against each. If AWS is more expensive, state that plainly and justify it with operational benefits rather than burying it below the fold.

Qualitative factors only — assign no dollar value to any of these: infrastructure control, autoscaling granularity, service breadth, reduced dependence on the cloud being left, compliance posture, and access to commitment products Azure priced differently.

Repeat the sign convention beside any signed number, and repeat the floor caveat wherever a total that excludes lines appears in an ROI sentence.

Part 6: Optimization opportunities

Eligibility, the three-state rendering model, and the required caveats are defined in references/vendored/estimate/ri-sp-eligibility.md. Execute that file's matrix as this step — it is the source of truth on eligibility. Only the azure-specific shaping lives here.

Always render this section, even when nothing qualifies: state which of the three states the design landed in rather than omitting the section.

• The customer may already hold Azure reservations or a savings plan. If reservation_substitutions is non-empty, or the user mentioned reservations, a commitment product is not a new idea to them — it is what they already do, and migrating resets its clock. Frame it as continuity. An unexpired Azure commitment is a sunk cost that survives cutover, and it belongs in Part 4.

• Graviton is not offered by default. The design chose x86_64 deliberately, for Windows and .NET. Raise an arm64 opportunity only for a workload whose stack is known to be portable, and raise it in the workshop sidebar where the customer sees both prices — not as an assumed saving here. A withdrawn recommendation costs more trust than one never made.

• Declared waste is not an "opportunity" — it is already inside the right-sized total. Listing it here double-counts the saving.

Part 7: Complexity tier

Load the thresholds from references/vendored/estimate/complexity-tiers.json and classify from the largest tier down, first match wins. Inputs:

Three azure-specific notes. A deferred[] entry raises complexity even though it carries no cost — deferred work is still work. A floor total must not pull the tier down: when lines were excluded, classify on the evidence that those services exist, not on a total that omits them. And:

Read preferences.design_constraints.compliance. Clarify now always asks this (Q-A1c, ESSENTIAL). Normalize the array before classifying:

• No frameworks (explicit none): [] (canonical) or ["none"] (accepted alias from the AI-only path). Record complexity_inputs.compliance as []. compliance_present is false. Do not emit compliance_never_asked.

• Unconfirmed: ["unknown"], or a still-null ESSENTIAL row that somehow reached Estimate. Record the raw value, treat the catalog like "none" (no speculative BAA-only stack), emit compliance_unconfirmed, and let Part 8 hard-trigger 1 evaluate its second clause (regulated signals) rather than treating unknown as permanently true.

• Named frameworks: ["soc2"], ["pci"], … — compliance_present is true when any entry is a named framework (not none/unknown).

Never invent "none" as a string scalar. Never write compliance: null on a run whose Clarify artifact already has a compliance row.

compliance_never_asked remains in the closed vocabulary only for pre-question frozen artifacts (the after-estimate/ capability-run snapshot). Live Estimate must not emit it once Q-A1c exists.

The tier here is driven by a row count, not by money. service_count_gte: 9 fires on the literal services[] length, which includes $0 networking primitives, while monthly_spend_gt: 10000 can be missed by an order of magnitude. A $465/month estate can therefore classify large. That is the shared table's behaviour and it is followed literally — complexity-tiers.json says metadata.total_services and nothing distinguishes billable from free — but the artifact should say which condition fired, so a reader is not left inferring that the estate is expensive.

"complexity_tier": "small|medium|large",
"complexity_inputs": {
  "service_count": "<N>", "cluster_count": "<N>",
  "monthly_spend": "<right-sized>", "monthly_spend_is_floor": true,
  "has_databases": true, "availability": "<...>", "compliance": "<...>",
  "multi_region": false, "licensing_fired": true, "deferred_count": "<N>"
}

Part 8: Recommendation

path says how a migration would run; outcome says whether to run it now.

Hard triggers — any one forces outcome: "defer_for_evidence":

defer_for_evidence is expected to be rare: AWS almost always has the services, and the AWS-side estimate can almost always be produced. Prefer conditional_go with named conditions when in doubt.

Soft triggers — never force a defer. Each becomes an entry in conditions[] (so outcome becomes conditional_go) and in would_flip_if[]:

Derivation:

IF any hard trigger fired      -> "defer_for_evidence"
ELSE IF path == "stay"         -> "stay"
ELSE IF any soft trigger fired -> "conditional_go"   (conditions[] = the fired triggers)
ELSE                           -> "go"

Complexity alone selects path: "migrate_phased"; it never moves outcome away from go or conditional_go.

Populate decision_basis from provenance — inventory-extracted or invoice values are measured, defaulted inputs are assumed, declined or unknown ones are unknown — and would_flip_if[] with the 1–3 changes most likely to alter the outcome, each with its direction.

Presenting a defer: lead with what IS established ("AWS can host this estate; the AWS-side floor is $X/mo") before naming the one missing piece of evidence and how to obtain it. Never present a defer as "no answer".

"recommendation": {
  "path": "migrate_optimized|migrate_phased|stay",
  "path_label": "<label>",
  "outcome": "go|conditional_go|defer_for_evidence|stay",
  "outcome_label": "<label>",
  "roi_justification": "<one sentence>",
  "confidence": "high|medium|low",
  "migrate_if": ["<specific to THIS estate>"],
  "stay_if": ["<specific to THIS estate>"],
  "conditions": ["<non-empty when outcome is conditional_go>"],
  "decision_basis": { "measured": [], "assumed": [], "unknown": [] },
  "would_flip_if": [],
  "next_steps": []
}

outcome: "stay" only ever accompanies path: "stay".

Cost labeling. Every dollar figure presented anywhere — chat, report, metric box — is labeled as an estimate ("Est." or "estimated monthly"). Never present a computed figure as exact.

The Estimate warning vocabulary — CLOSED

Discover and Design each declare a closed warning vocabulary, on the grounds that an invented code makes the report's grouping unstable. Estimate had none, which left every code in this phase improvised. This vocabulary is closed on the same terms: add a row here first, then use it.

Each warning carries code, a human message, and the service_id it concerns where it concerns one. If a situation needs a code that is not here, add the row in this file before emitting it — an improvised code is indistinguishable from a typo to whatever groups the report.

When Parts 1–8 are complete, control passes to estimate-assemble.md.