Sustainability Methodology

Every carbon number on a FrootAI marketplace card, in a wizard preview, or in a CLI report is computed by the Verified Carbon Engine. This page documents the full math, every data source, the accuracy band we promise, and the engineering doctrine that keeps every number honest.

1. What we compute

For every Solution Play, every wizard preview, and every CLI report, the engine produces a monthly carbon footprint measured in g CO2e / month (and a kg helper for human readability):

monthly_g_co2e = monthly_kwh × grid_intensity_g_per_kwh

The right-hand side breaks down into:

• monthly_kwh — energy consumed per month by the deployed Azure resources, derived from per-family energy coefficients (compute, storage, database, network, AI) × an operator-supplied sizing intent (small, medium, large).
• grid_intensity_g_per_kwh — full-lifecycle CO2-equivalent grams per kWh for the Azure region the workload is deployed to, sourced from ElectricityMaps, Microsoft Cloud for Sustainability, and IEA national averages.

We then surface a 5-band classification (minimal, low, moderate, high, severe) and an optional region-hint advisory (“moving to norwayeast would reduce carbon by 93 %“).

2. Energy model

Each Azure resource family has a sealed energy coefficient. Bumping any of these requires bumping the engine’s ENERGY_MODEL_DATA_VERSION, so downstream consumers can detect silent shifts.

Worked example — a small VM running 24×7 for one month in eastus:

energy = 75 Wh × 1 instance × 730 hours / 1000  = 54.75 kWh
carbon = 54.75 kWh × 369 g/kWh                  = 20,202.75 g CO2e/month
                                                = 20.20 kg CO2e/month
                                                → "low" band (10 ≤ x < 100 kg)

2.1 Why these specific coefficients?

• Compute (75 Wh/inst-hr) — average modern x86 server class running a mixed workload (CPU 30-50 % utilization typical). Vendor-published peak values (~150 W) are TDP, not actual sustained draw; the Uptime Institute survey of operational datacentres is the conservative real-world average.
• Storage (1.2 kWh/TB-mo) — accounts for both spinning disk (~1.5 kWh/TB-mo) and SSD (~0.4 kWh/TB-mo) — we use the higher value when the tier is unknown to stay conservative.
• Database (110 Wh/vCore-hr) — higher than raw compute (~85 Wh) to account for replication, transaction log IO, and durable storage overhead that PaaS DB services bundle in.
• Network (0.06 kWh/GB) — datacentre-edge + transit network + customer- edge router stack, per Aslan et al. 2018. Conservative for modern fibre; older studies cited 1-2 kWh/GB.
• AI (350 Wh/inf-hr) — GPU-accelerated inference is much heavier than general compute. Training is excluded from this number (that’s a one-off capital cost; ongoing inference is the operational footprint).

3. Grid intensity

We ship a sealed table of grid carbon intensity for every Azure commercial region (52 regions as of the 2025-10 data snapshot). Every record carries its source, year, methodology, and confidence.

3.1 Data sources (in priority order)

1. ElectricityMaps  — 2024 yearly LCA averages per electricity-grid zone. Covers 35 of 52 Azure regions. Best-quality source; preferred when available.
2. Microsoft Cloud for Sustainability  — Microsoft’s published per-region values for some regions not covered by ElectricityMaps.
3. IEA / national-grid public averages — used when no datacentre-zone value is published (17 of 52 regions). Lower confidence; the operator should treat these as advisory.

3.2 Methodology

We use lifecycle assessment (LCA) averages — the full upstream-to-grid carbon cost of generating each kWh, including:

• Fuel-cycle emissions (gas / coal extraction + combustion).
• Plant construction (amortized over lifetime kWh).
• Transmission + distribution losses.

We deliberately do NOT mix LCA and operational-only values; that would silently corrupt comparisons across regions.

3.3 Confidence levels

• high — published with a documented methodology by a recognized source (ElectricityMaps, MS Sustainability).
• medium — national-grid average used as a proxy for the datacentre-zone (e.g. country-level IEA data).
• low — region with limited public data; operator should cross-check.

3.4 Sample grid intensities

The full table is available in the engine source: grid_intensity.py.

4. Carbon-band classification

We classify the monthly carbon total into one of five bands. The thresholds are sealed; bumping any one is a contract bump and would shift every marketplace badge in lockstep.

The >1 ton masterplan spec was split into high (1-10 t) and severe (10 t+) so very-heavy workloads stand out on a marketplace card rather than blending into the “high” band.

5. Carbon-aware region hints

For every attributed line item, the engine surfaces a “moving to <region> would reduce carbon by X %” advisory — provided:

1. A compatible alternative region exists in the same geographic zone (Americas, Europe, Asia-Pacific, Middle East, Africa), AND
2. The saving exceeds 10 % (below the engine’s own confidence band, a smaller saving would be noise).

Why same-zone-only by default? Cross-zone moves typically hit:

• Data residency (GDPR, HIPAA, SOC 2 Type II commitments).
• Latency to your user base.
• Inter-region egress costs.

Operators can opt into cross-zone suggestions explicitly with --allow-geographies europe,americas on the CLI. The hint output flags every cross-zone suggestion with cross_geography: true so a reviewer can see at a glance what compliance implications need checking.

6. Accuracy bounds

The 15 % band is wider than the cost engine’s 10 % bound because:

• Grid intensities are yearly LCA averages; instantaneous values swing 2-3× with renewable supply (a solar-heavy grid can be 50 g/kWh at noon and 350 g/kWh at 11pm).
• Energy coefficients are published averages over diverse workloads; a specific application can vary 30-50 % from the average.

For most accurate numbers, an operator should layer the Microsoft Cloud for Sustainability emissions dashboard  on top of the FrootAI engine output for their actual deployed subscriptions; that gives measured-emissions data instead of LCA-average modeled estimates.

7. Doctrine — what makes every number honest

We follow ten core invariants under the heading NEVER FAKE A SIGNAL. Every one is enforced by sealed test contracts in the engine source:

1. Honest absence on unknown regions — an Azure region not in our sealed grid table raises a typed region_not_in_table error. We never fall back to a “global average” — that would silently attribute a wrong number to a real region.
2. Honest absence on unknown families — same posture for resource families. An unknown family raises unknown_family; we never invent a coefficient.
3. Provenance carried on every record — every grid-intensity record and every energy coefficient ships with source, source_year, methodology, and confidence. You can always trace a number back to where it came from.
4. Honest zero, distinguished from skip — a module with zero usage signal (e.g. storage_gb = 0) is attributed (we know about it) but reports monthly_kwh = 0, usage_signal_present = false. Skipping it silently would falsely lower the rollup total.
5. Honest absence on the marketplace card — an empty composition classifies as minimal but with has_any_attributed_lines = false. The marketplace UI shows a GREY “n/a” badge rather than a green minimal that would mislead a buyer.
6. No mixing methodologies — we only use LCA-average values; we never silently substitute operational-only when LCA isn’t available.
7. Data-version pinned — bumping the grid table or coefficient table bumps CARBON_ENGINE_DATA_VERSION / ENERGY_MODEL_DATA_VERSION in lockstep. Diffs across versions raise rather than silently corrupting numbers.
8. Carbon engine is hermetic — no live HTTP calls. The grid table + coefficients ship with the package. A regression that pulled in a network dependency would fail a sealed contract test immediately.
9. Confidence intervals propagated — the confidence field flows from raw data → engine output → marketplace badge so a buyer always sees the quality of the data behind the number.
10. Reproducibility — same inputs always produce the same numbers, byte-for-byte. Independently verifiable.

8. Known gaps

We’re explicit about what we don’t model. If any of these matter to your use case, treat the engine output as a baseline and layer measured data on top.

• Embodied carbon (manufacturing) — the 75 Wh/inst-hr figure is operational only. Manufacturing carbon would add ~10-20 % over a 3-year hardware lifecycle.
• PUE (Power Usage Effectiveness) — Microsoft datacentre PUE (~1.12) is implicitly baked into the LCA-average grid intensities but not surfaced separately.
• Time-of-day variation — yearly averages only. Renewable-heavy grids vary 2-3× hour-by-hour; a carbon-aware-scheduling feature is on the future roadmap.
• Free-tier credits — not modeled; affects the smallest workloads.
• Government and China clouds — not in the current table; only commercial regions covered.
• Spot vs reserved pricing — affects cost but not carbon (same hardware, same grid).

9. How to use this

9.1 Marketplace card

Every Solution Play card on frootai.dev/marketplace shows a carbon sub-badge. The colour scale (green → red) maps to the 5 bands in §4. Hover the badge to see the exact kg CO2e/month + the region the carbon was computed for.

9.2 Wizard preview (live recalculation)

When you customize a play with the wizard, the carbon number recomputes live as you change the deployment region or scale. The preview shows baseline (default settings) vs with-policy (your edits) side by side, so the carbon impact of a region move from eastus to norwayeast is visible before you deploy.

9.3 CLI

frootai orchard carbon ./my-play.json \
    --sizing medium \
    --region norwayeast \
    --allow-geographies europe \
    --json

The --json mode emits the full envelope (rollup, band, region advisory) for scripting.

9.4 Telemetry

If you set the FAI_VERIFIED_TELEMETRY_SINK env var, every carbon calculation emits a verified_carbon_call JSONL event with the monthly g CO2e, latency, and module counts. This lets you build an operator-side dashboard tracking carbon across all your deployments.

10. Reproducibility checklist

If a reviewer wants to independently verify a published carbon number:

1. Pin the data versions — note the grid_data_version and energy_data_version from the engine output.
2. Pin the composition — the ComposedTemplate JSON used as input.
3. Pin the sizing + region — small/medium/large + the Azure region.
4. Re-run the engine at the same data versions:

   frootai orchard carbon <play.json> --sizing <s> --region <r> --json

5. Compare — the per-line monthly_g_co2e values must match byte-for-byte (the wall-clock computed_at timestamp is the only non-deterministic field).

The engine source, sealed tables, and test contracts are all available in the frootai-core repository .

11. References

• ElectricityMaps — primary grid-intensity source. https://electricitymaps.com/ 
• Microsoft Cloud for Sustainability — Azure-specific per-region values + measured-emissions dashboard. https://www.microsoft.com/en-us/sustainability/emissions-impact-dashboard 
• IEA Data Centres & Data Transmission Networks — operational-grid + global-averages reference. https://www.iea.org/reports/data-centres-and-data-transmission-networks 
• Aslan et al. 2018 — Electricity Intensity of Internet Data Transmission: Untangling the Estimates. https://doi.org/10.1111/jiec.12630 
• Patterson et al. 2024 — Carbon Emissions of ML Inference: A Practical Update.
• Uptime Institute Server Energy Survey 2024 — server-class operational draw averages.
• GHG Protocol Corporate Standard — Scope 1/2/3 definitions and methodology framework. https://ghgprotocol.org/ 

12. Get involved

We treat the carbon engine as a public good. If you spot a wrong grid intensity, an outdated coefficient, or a missing region, open an issue on the frootai-core repository .

• Internal engineering reference: see docs/internal/verified-carbon-engine.md for the full pipeline, schemas, and test coverage.
• Companion docs: Cost Engine (cost computation methodology).
• Solution Plays using this engine: Carbon Footprint Tracker, Smart Energy Grid AI, Climate Risk Assessor.