Skip to content

Carbon intensity sources

Per-region grid carbon intensity is the most consequential time-varying input to the methodology. We use a tiered fallback across multiple authoritative sources, and we record both the source label and the source timestamp that supported each receipt.

Why a fallback chain matters

A single source can fail or publish late. When grid intensity falls back to a lower-fidelity source, the receipt becomes less precise but should not become wrong. We track that provenance directly in the receipt:

  • vetted.grid_intensity_source
  • vetted.grid_intensity_observed_at
  • vetted.grid_intensity_requested_at
  • vetted.grid_intensity_age_minutes
  • vetted.grid_temporal_match

Source priority by region

For each region, we use the first available source in the fallback chain.

France (Scaleway PAR, OVH GRA/RBX)

  1. RTE eCO2mix (5-minute real-time)
  2. ENTSO-E Transparency Platform (nominally sub-hourly, publication lag varies by zone)
  3. JRC NEEFE 2024 (annual average)
  4. IPCC AR6 default (fallback of last resort)

Sweden (atNorth STO)

  1. Svenska kraftnät svk_production (measured Sweden-wide quarter-hour production mix)
  2. Svenska kraftnät svk_zonal_plan (operational provisional bidding-area plan overlay; not receipt-grade measured evidence)
  3. eSett esett_production (measured delayed bidding-area production backfill; calibration and retrospective audit path)
  4. ENTSO-E Transparency Platform (measured fallback path; publication lag varies by zone)
  5. Ember Climate (annual or monthly averages)
  6. JRC NEEFE 2024 (annual)

Denmark

  1. Energinet CO2Emis (measured 5-minute inventory)
  2. Energinet CO2EmisProg (official forecast bridge for operational use)
  3. ENTSO-E Transparency Platform
  4. JRC NEEFE 2024
  5. Ember annual anchor

Germany / Finland

  1. Regional ISO/TSO source where available
  2. ENTSO-E Transparency Platform
  3. JRC NEEFE 2024
  4. Ember annual anchor (where JRC is unavailable for the zone/year)

What "live" means in the receipt

Different sources have different cadences and different publication behavior.

  • RTE, Energinet, Fingrid, SMARD, Svenska kraftnät measured production: true sub-hourly operational feeds
  • ENTSO-E: nominally sub-hourly, but observed publication lag can vary materially by zone
  • Energinet forecast / Svenska kraftnät zonal plans: operational bridges, not receipt-grade measured truth
  • JRC NEEFE / Ember / IPCC AR6: annual or static fallbacks

For ENTSO-E-backed receipts, "live" is a strict methodological claim, not just an operational one:

  • entsoe_derived_live means the source timestamp was within +/-15 minutes of the inference timestamp
  • entsoe_derived_prev_week means we fell back to the same hour-of-day-of-week from the previous week
  • entsoe_derived_lagged is a reserved label for future use; we do not currently emit it

If the source timestamp is too far from the inference timestamp, we do not pretend the value is live. The receipt instead exposes the fallback explicitly through the source label and temporal-match fields.

Operational live vs receipt live

For Denmark and Sweden, the operational control plane may use stronger live-routing inputs than the receipt plane:

  • Denmark can bridge from measured CO2Emis to official forecast CO2EmisProg
  • Sweden can bridge from measured Sweden-wide svk_production to provisional zonal svk_zonal_plan
  • Sweden also has a delayed measured zonal backfill path via esett_production; this improves calibration and retrospective audit quality, not live eligibility

These operational bridges improve routing quality, but they do not change the strict receipt semantics in this phase:

  • receipts remain conservative
  • provisional or forecast routing signals are not silently re-labeled as measured receipt truth

Current regional readiness

We use three public coverage buckets:

  • Live-ready: source observations are consistently within the methodology's strict +/-15 minute receipt window
  • Fresh-but-not-live: the signal is recent and operationally useful, but not consistently within the strict live window
  • Fallback-dominant: the system often falls back outside the near-time window under current production reality

As of the current retrospective production analysis, the buckets are:

Bucket Regions How to describe them
live-ready None today Do not make a strict live claim yet
fresh-but-not-live FR, FI, GB, DE_LU Near-time, auditable, suitable for stronger customer positioning
fallback-dominant DK_1, DK_2, SE_1, SE_2, SE_3, SE_4, ES Supported in the fallback chain, but not strong enough for a live or near-time promise

This means:

  • FR, FI, GB, and DE_LU are useful for fresh, auditable regional carbon signals
  • no current region should be marketed as strict live under the present methodology
  • DK, Swedish ENTSO-E, and ES remain available, but should be described as weaker current coverage

This bucket list is driven by recent retrospective analysis plus ongoing live-hit telemetry. It will change over time as source behavior or source coverage improves.

Freshness monitoring vs receipt matching

These are different controls:

  • Receipt matching: the resolver only accepts direct ENTSO-E data within +/-15 minutes
  • Operational monitoring: the production freshness monitor alerts only once ENTSO-E data is more than 180 minutes behind

The 180-minute number is an alerting threshold for provider publication lag. It is not a claim that a 3-hour-old ENTSO-E point is acceptable as a live receipt match.

Public transparency

Freshness is monitored operationally against the production database. The status surface should be read as service health, not as a guarantee that every source behaves like a perfect 15-minute feed in every zone.

A green status page means the pipeline is healthy. It does not mean every region is currently live-ready.

The live gateway resolves receipt intensity from the production database as follows:

  • intensity_cooked when a pre-materialized row is available
  • otherwise directly from matching intensity_raw live-source rows
  • with intensity_annual as the annual fallback layer

That bridge means newly integrated live sources can contribute to receipts immediately, even before any separate cooked-data materializer is introduced.

Operational readiness is measured separately from raw freshness:

  • freshness asks whether the source is arriving within its calibrated alert window
  • live-hit rate asks whether a real lookup(now) would have produced a strict direct live match for that zone

For mission-critical production use, both need to be healthy. A source can be operationally fresh and still miss the strict receipt window if the latest published point is older than 15 minutes at request time.

Auditors and methodologists should rely on the receipt timestamps themselves:

  • grid_intensity_observed_at is the timestamp of the source observation we used
  • grid_intensity_requested_at is the inference timestamp we were trying to match
  • grid_intensity_age_minutes is the absolute gap between those timestamps
  • grid_temporal_match explains whether the receipt used a live window or a fallback class

Why we do not use a single global source

  • Provenance. Regional ISO/TSO sources are methodologically cleaner than opaque aggregation alone.
  • Latency. The best regional sources are genuinely closer to real time than generic aggregators.
  • Resilience. A fallback chain is more honest and more robust than pretending one provider is always current.
  • Auditability. Each receipt can be tied back to a named source and a concrete observation timestamp.