GreenOps Platform: Carbon-Aware Scheduling
Defer When the Grid Is Dirty

The deferral window is the single most important GreenOps design parameter. Too short (±1 hour) and the window is rarely wide enough to capture a meaningful carbon intensity improvement — europe-west3 intensity changes gradually, and a 1-hour window often doesn't span a low-carbon trough. Too long (±24 hours) and flexible jobs start to accumulate in the deferred queue for periods that affect model freshness. ±6 hours was chosen on two empirical observations: (1) analysis of 90 days of europe-west3 Carbon Footprint API data shows a low-carbon window (below 80 gCO₂eq/kWh) occurs within 6 hours of any given time approximately 73% of the time. (2) the ML models across the platform's process pillars were evaluated for freshness sensitivity — all maintain acceptable prediction quality with weekly retraining cycles; a 6-hour delay on a weekly job represents a 0.4% increase in the retraining interval, statistically indistinguishable from expected model performance at the weekly evaluation frequency.

Electricity Maps and WattTime were evaluated — both provide more granular real-time and forecast carbon intensity data than GCP's Carbon Footprint API, including marginal emissions rates. Rejected for three reasons. (1) GCP's Carbon Footprint API is available within the VPC-SC perimeter as a GCP-native service — no outbound internet call required; third-party APIs require outbound HTTPS calls that must be documented in the VPC-SC threat model and approved by the CISO. For a governance-layer module serving all process pillars, adding an external API dependency for a Minimal Risk module is not justified. (2) GCP Carbon Footprint API data is directly aligned with the GCP billing carbon reporting ClaraVis already uses internally — using the same data source for scheduling decisions and CSRD reporting ensures internal consistency. (3) at the forecast granularity required (30-minute intervals, 12-hour horizon), the GCP API is sufficient — the marginal vs average emissions distinction matters more for real-time demand response than for batch job scheduling with a 6-hour window.

Cloud Tasks was the primary candidate — it is the canonical GCP service for delayed/scheduled task execution. Rejected for two reasons. (1) GreenOps does not need guaranteed-once delivery with a fixed delay; the deferred queue requires re-evaluation on every 30-minute loop against the current carbon intensity — the dispatch decision is "dispatch when a condition is met on a schedule," a query pattern, not "dispatch after N minutes." (2) Firestore enables the query GreenOps actually needs: SELECT all jobs WHERE window_expiry > NOW() AND state = DEFERRED — a predicate query over a mutable document store that Cloud Tasks does not expose. The tradeoff — no native dead-letter queue — is mitigated by window-expiry forced dispatch: every job that cannot be deferred successfully is force-dispatched at window_expiry, not lost. Document accumulation is bounded by job volume (≤30 jobs/week at ClaraVis H3 workload), so unbounded growth is not a concern at this scale.

When the GCP Carbon Footprint API is unavailable (timeout, 5xx, or stale data beyond 90 minutes), GreenOps must choose between two degraded modes: (A) block all job dispatch until the API recovers, or (B) dispatch all queued jobs immediately and flag records as api_fallback:true. Option A preserves carbon optimisation intent but violates the "every job dispatched eventually" safety property — a multi-hour API outage would hold all process pillar training jobs in DEFERRED state, potentially cascading into model freshness violations. Option B sacrifices carbon savings for the duration of the outage but maintains the scheduling reliability guarantee GreenOps promises to all process pillars. Degraded-mode dispatches are flagged in BigQuery and excluded from CSRD savings calculations — the audit trail remains accurate. The circuit breaker threshold: 3 consecutive API failures within a 5-minute window triggers degraded mode; recovery requires 2 consecutive successful calls.

Google's carbon-aware computing research (Radovanovic et al., 2021) uses a rolling percentile threshold — typically the 75th percentile of the trailing 30-day distribution — rather than a static absolute value, adapting to seasonal variation in europe-west3's carbon intensity. The adaptive approach is architecturally superior and is the target state for Phase 2. It is deferred for MVP for two reasons. (1) it requires 30 days of historical Carbon Footprint API data before the rolling window is statistically meaningful — deploying in H3 means the threshold logic would run on incomplete data for the first month. (2) a static threshold is easier to audit: CSRD reviewers can verify that every job dispatched below 80 gCO₂eq/kWh meets the threshold without reconstructing the rolling window at each dispatch time. Phase 2 will introduce a threshold_type field (static | rolling_p75) in the ESG record to maintain auditability across the transition.