GreenOps Platform — Module 06 · The Autonomous Enterprise

System Context — C4 Level 1

Carbon intensity in. Optimal dispatch time out. No humans required.

GreenOps is the only module in the AE Suite with no HITL checkpoint and no human decision path. Scheduling decisions are fully autonomous within the ±6 hour deferral window. The CTO and sustainability team are consumers of GreenOps output — the ESG metrics dashboard — not participants in its decisions.

GreenOps Platform — System Context (C4 Level 1)

Fully autonomous within ±6h window · no HITL · hard-deadline jobs never deferred · CSRD audit trail per job

GreenOps boundary

Carbon API + BigQuery ESG

GKE Autopilot dispatch

CSRD export

Deferral Eligibility — All AE Batch Jobs

Job	Module	Schedule	Deadline type	Max deferral	Eligible for carbon deferral?
Weekly model retraining (RevRec AI)	RevRec AI · M-03	Sundays 02:00 UTC	Soft — weekly freshness	±6 hours	✓ Deferrable
Weekly model retraining (Asset IQ RUL)	Asset IQ · M-05	Sundays 03:00 UTC	Soft — weekly freshness	±6 hours	✓ Deferrable
Weekly model retraining (ContractGuard)	ContractGuard · M-02	Sundays 04:00 UTC	Soft — weekly freshness	±6 hours	✓ Deferrable
Daily feature pipeline backfill	Data Governance · M-08	Daily 01:00 UTC	Soft — before daily RUL run	±3 hours	✓ Deferrable
Daily RUL batch prediction	Asset IQ · M-05	Daily 02:00 UTC	Hard — FSM queue same day	None	✗ Never deferred
FinRisk anomaly model refresh	FinRisk Sentinel · M-04	Daily 03:00 UTC	Hard — streaming model currency	None	✗ Never deferred
ContractGuard Vector Store reindex	ContractGuard · M-02	Monthly, 1st	Soft — monthly precedent freshness	±12 hours	✓ Deferrable

Architecture — Carbon-Aware Scheduling Pipeline

Forecast. Score. Defer or dispatch. Every decision logged.

The GreenOps scheduling pipeline runs every 30 minutes to re-evaluate deferred jobs against the latest carbon intensity forecast. A job that was deferred 90 minutes ago because the grid was at 142 gCO₂eq/kWh gets re-evaluated when the forecast shows a low-carbon window approaching. The decision to dispatch is autonomous and immediate.

GreenOps — Carbon-Aware Scheduling Pipeline

30-minute re-evaluation loop · hard-deadline bypass · Firestore deferred queue · BigQuery ESG record per dispatch

GreenOps Agent + Decision Engine

Deferred queue (Firestore)

GKE Autopilot dispatch

BigQuery ESG metrics

--- hard deadline bypass (never deferred)

Agent State Machine

Simple states. Clear thresholds. No ambiguity.

The GreenOps state machine is deliberately simple — the scheduling decision is binary (dispatch or defer) with a hard-deadline bypass that is never conditional. The complexity is in the re-evaluation loop: a deferred job re-enters the FORECASTING state every 30 minutes until it dispatches or its window expires.

GreenOps — Agent Finite State Machine

Hard-deadline bypass · 30-minute re-eval loop · window-expiry forced dispatch · ESG record at every dispatch

Forecast + Evaluate

DEFERRING (30-min loop)

DISPATCHING

--- hard deadline bypass

--- window-expiry forced dispatch

Data Flow — Deferred Job Sequence

Weekly retraining submitted at 02:00. Dispatched at 06:12. 34% carbon saving.

The weekly RevRec AI model retraining job is submitted at 02:00 UTC on Sunday. GreenOps checks the carbon intensity forecast — europe-west3 is currently at 142 gCO₂eq/kWh. The forecast shows a low-carbon window at 06:12 UTC (68 gCO₂eq/kWh). The job is deferred. At 06:12, GreenOps dispatches. The ESG record shows 34% carbon reduction versus immediate dispatch.

Sequence — Weekly RevRec AI Retraining · Deferred 4.2h · 52% Carbon Saving

Submitted 02:00 UTC · deferred through 3 re-evaluation cycles · dispatched 06:12 · completed 07:14 · ESG record written

ESG Metrics Dashboard

Carbon savings. Per job. Per month. Per CSRD export.

GreenOps produces auditable carbon savings data — not estimates or projections. Every dispatch writes an actual-vs-baseline record to BigQuery. The CSRD Scope 3 Category 11 export is generated monthly from these records. The figures below are indicative of a full H3 deployment at ClaraVis's workload volume.

Monthly Carbon Saved

18.4

kgCO₂eq / month · all deferred jobs

Jobs Deferred (monthly)

of 22 flexible jobs · 64% deferral rate

Average Carbon Reduction

41%

vs immediate dispatch baseline

Avg Deferral Duration

3.8h

well within ±6h window

Representative Carbon Intensity Profile — europe-west3 · 24-hour window (gCO₂eq/kWh)

Green shading = typical GreenOps dispatch windows · Dashed green = 80 gCO₂eq/kWh dispatch threshold Source: GCP Carbon Footprint API · europe-west3 · representative week

CSRD Scope 3 Category 11 — Use of sold products

CSRD Scope 3 Category 11 covers emissions from the use of sold products. For a medical imaging OEM like ClaraVis, this includes the energy consumed by MRI and CT units in customer facilities. GreenOps addresses the indirect emissions from ClaraVis's own GCP workloads — a smaller but fully auditable contribution. The BigQuery ae_greenops.job_metrics table exports monthly to a CSRD-aligned CSV with: reporting_period, scope, category, activity_description, activity_units, activity_quantity, emission_factor, total_emissions_kgCO2eq. This export is directly ingestible by ClaraVis's sustainability reporting tool and satisfies the EU taxonomy technical screening criteria for climate change mitigation.

Architecture Decision Records

Two GreenOps decisions. Both defensible on their own terms.

ADR-GO01 — GreenOps specific

±6 hour deferral window — not ±1 hour, not ±24 hours

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 — a RevRec AI model that hasn't been retrained for 30+ hours is consuming a week-old training dataset. ±6 hours was chosen based on two empirical observations: (1) Analysis of 90 days of europe-west3 Carbon Footprint API data shows that 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 in the AE Suite were evaluated for freshness sensitivity — RevRec AI, Asset IQ, and ContractGuard 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, which is statistically indistinguishable from the expected model performance at the weekly evaluation frequency.

Accepted · Phase GreenOps Design · GreenOps module

ADR-GO02 — GreenOps specific

GCP Carbon Footprint API over third-party carbon intensity APIs (Electricity Maps, WattTime)

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 (which are arguably more accurate for scheduling decisions than average emissions rates). Rejected for three reasons: (1) External API dependency: GCP's Carbon Footprint API is available within the VPC-SC perimeter as a GCP-native service — no outbound internet call required. Electricity Maps and WattTime require outbound HTTPS calls from the Cloud Run agent to external services, which introduces a network egress path that must be documented in the VPC-SC threat model and approved by the CISO. For a portfolio-scale deployment, 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 that ClaraVis would use for its own internal GCP sustainability reporting — 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), GCP's Carbon Footprint 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.

Accepted · Phase GreenOps Design · GreenOps module

Stakeholder Rebuttals

Four objections. Each with an architectural answer.

CTO · S-01

What's the actual carbon saving — is this meaningful or greenwashing?

"18.4 kgCO₂eq per month sounds small. ClaraVis's installed MRI fleet consumes gigawatt-hours annually. Is a Carbon-aware scheduler for ML training jobs a genuine sustainability initiative or a token gesture that looks good in a CSRD report?"

Architectural response

18.4 kgCO₂eq per month from GKE batch scheduling is a small number in absolute terms — it's the right number for this scope. GreenOps addresses Scope 2 emissions from ClaraVis's own GCP workloads, not the Scope 3 Category 11 emissions from 12,000 MRI units in customer facilities. The ClaraVis installed fleet is a genuinely large Scope 3 emissions source — that requires a product-level energy efficiency programme, not a cloud scheduling optimisation. GreenOps is correctly scoped: it addresses what it can address (GCP compute carbon), produces auditable evidence (BigQuery per-job records), and contributes to the CSRD reporting obligation that ClaraVis has under EU taxonomy. The value is not in the kilogram figure — it is in the auditability. A CSRD auditor can query ae_greenops.job_metrics and verify every savings claim to the job level. That is genuinely harder to produce than a top-down estimate, and it is a meaningful differentiator in ClaraVis's sustainability disclosure.

Evidence: BigQuery ae_greenops.job_metrics (per-job audit trail) · CSRD Scope 3 export format · ADR-GO01 (model freshness impact analysis — 0.4% retraining interval increase)

CFO · S-03

Does deferring ML training jobs affect model freshness or prediction quality?

"If GreenOps defers the weekly RevRec AI retraining by up to 6 hours, and that model is used for ASC 606 classification the next morning, is there any risk that a 6-hour-stale model produces classifications that the Finance team later disputes?"

Architectural response

RevRec AI is retrained weekly, not hourly. A 6-hour deferral on a weekly job changes the retraining interval from 168 hours to 174 hours — a 3.6% increase. The RevRec AI model's performance metrics (precision, recall, override rate) are evaluated on a weekly basis against the holdout set. At weekly evaluation frequency, a 6-hour deferral produces no statistically measurable change in model quality. The model that the Finance Controller sees on Monday morning is functionally identical whether the retraining ran at 02:00 Sunday or 08:00 Sunday. The hard-deadline bypass rule additionally ensures that any job with a genuine operational dependency — the daily RUL batch job, the FinRisk model refresh — is never deferred. The freshness concern is real for daily jobs. For weekly jobs with a ±6 hour deferral window, the concern does not apply.

Evidence: ADR-GO01 (0.4% retraining interval increase · weekly evaluation frequency) · Job eligibility table (daily RUL and FinRisk = hard deadline, never deferred) · Page 06 RevRec AI Model Card (weekly retraining cycle)

CCO · S-02

Does GreenOps produce audit-quality CSRD Scope 3 data?

"CSRD requires third-party assurance of sustainability disclosures from 2025 onwards for large companies. Will the data GreenOps produces satisfy an external auditor — or is it an internal estimate that needs a separate verification process?"

Architectural response

The BigQuery ae_greenops.job_metrics table is designed for external audit from the start. Every row contains: the GCP job ID (traceable to the Cloud Logging job execution record), the Carbon Footprint API response at dispatch time (with the API's own audit reference), the actual kWh consumed (from GKE resource utilisation metrics, not estimated), the emission factor applied (gCO₂eq/kWh from the API), and the calculated emissions figure. An auditor can verify each savings claim by checking the source API data, the actual compute utilisation, and the arithmetic independently. The CSRD export format aligns with the EU taxonomy technical screening criteria — the column structure matches the reporting standard for Scope 3 Category 11. The remaining assurance gap is the carbon intensity data itself — GCP's Carbon Footprint API data is published by Google with their own methodology statement. ClaraVis would need to reference that methodology in their CSRD disclosure, which is standard practice for Scope 2 location-based calculations.

Evidence: CSRD Scope 3 export format (§05) · BigQuery job_metrics schema (GCP job ID + API reference + actual kWh) · ADR-GO02 (GCP Carbon API aligned with GCP billing reporting)

Enterprise Architect · S-08

What if the low-carbon window never arrives within the ±6 hour window?

"If europe-west3 has an extended period of high carbon intensity — a heat wave reducing renewable generation for 12+ hours, for example — every deferred job will hit its window expiry and dispatch anyway at high intensity. Does GreenOps handle this gracefully or does it produce a burst of forced dispatches that overload GKE?"

Architectural response

Window expiry dispatches are handled in the decision engine with two protections against burst dispatch. First, the Firestore deferred queue tracks each job's window_expiry independently — jobs with expiry times staggered across a 6-hour window dispatch sequentially as their individual windows expire, not simultaneously. The Sunday weekly retraining jobs for RevRec AI, Asset IQ, and ContractGuard have submission times at 02:00, 03:00, and 04:00 UTC respectively, and maximum window expiries at 08:00, 09:00, and 10:00 — so even in a worst-case no-low-carbon scenario, the three forced dispatches are spaced an hour apart. Second, GKE Autopilot's per-pod scheduling absorbs burst workloads gracefully — the Autopilot scheduler queues pod requests and provisions nodes as capacity is available. A burst of three training jobs does not saturate GKE because each job runs on its own node pool, provisioned independently. The window-expiry scenario is a degraded mode, not a failure mode — jobs run at higher carbon intensity than optimal, the saving_pct in the ESG record is 0%, and the CSRD export reflects the actual emissions accurately.

Evidence: Job eligibility table (staggered submission times) · State machine (window-expiry = forced dispatch, not failure) · GKE Autopilot (per-pod scheduling, no burst saturation) · BigQuery ESG record (saving_pct = 0% in worst case, still auditable)

Demo Pathway

Three minutes. One deferred job. One dispatch. One ESG record.

The demo shows the complete GreenOps lifecycle: job submitted, carbon intensity checked, job deferred, intensity drops, job dispatched, ESG record written. The key moments are the Firestore deferred queue entry and the BigQuery ESG record — which together show that every decision is logged, every saving is calculated, and every claim is auditable.

Setup · 30s before

Open GreenOps dashboard and Carbon API monitoring

Open the GreenOps monitoring panel. Show the current carbon intensity for europe-west3 (set to 138 gCO₂eq/kWh for the demo). Show the Firestore deferred queue — currently empty. Show the BigQuery ae_greenops.job_metrics table with recent dispatch records. This establishes the normal state before the demo job is submitted.

GreenOps monitoringCarbon API dashboardFirestore deferred queue

Submit job · 0:00

Trigger the weekly ContractGuard Vector Store reindex via Cloud Scheduler

Manually trigger the Cloud Scheduler job for contractguard_vectorstore_reindex with flexibility_window: flexible, deadline: +12h. Watch the GreenOps Cloud Run logs: "Job received · contractguard_vectorstore_reindex · flexible · calling Carbon Footprint API…", "Current intensity: 138 gCO₂eq/kWh · min forecast (next 6h): 72 gCO₂eq/kWh at +3.8h · threshold: 80 · decision: DEFER".

"The job arrives. GreenOps checks the carbon intensity — 138 right now, which is above the 80 threshold. But the forecast shows 72 in about 3.8 hours. The job can wait. It gets added to the deferred queue."

Cloud Scheduler triggerCarbon Footprint APIGreenOps decision engine

Deferred · 0:20

Show the Firestore deferred queue entry — job waiting

Open Firestore. Navigate to the deferred_jobs collection. Show the document for contractguard_vectorstore_reindex: job_id, submitted_at, window_expiry (submitted_at + 12h), current_intensity: 138, forecast_min_intensity: 72, forecast_dispatch_time: +3.8h. The job is waiting.

"The job is in Firestore — every 30 minutes, GreenOps re-evaluates it. If the carbon intensity drops below 80 before the window expires, it dispatches. If the window expires, it dispatches at whatever the current intensity is. Either way, the ESG record captures the actual carbon cost."

Firestore deferred_jobs30-min re-eval loop

Dispatch · 0:45 (simulated +3.8h)

Simulate carbon intensity dropping — watch GreenOps dispatch

Update the simulated carbon intensity in the demo environment to 71 gCO₂eq/kWh (below the 80 threshold). Watch the GreenOps re-evaluation cycle fire: "Re-evaluation: contractguard_vectorstore_reindex · current intensity: 71 < 80 threshold · DISPATCH". Cloud Run submits the job to GKE Autopilot. Show the GKE workload appearing in the Console.

"Intensity just dropped below 80. GreenOps catches it on the next 30-minute re-evaluation and dispatches immediately. The job runs now, at 71 gCO₂eq/kWh instead of 138. That's a 49% carbon reduction on this job — and it took no human intervention whatsoever."

GreenOps re-evaluationGKE Autopilot dispatchCloud Run logs

ESG Record · 1:30

Show the BigQuery ESG metrics record

After the simulated job completes, open BigQuery ae_greenops.job_metrics. Show the new row: job_id contractguard_vectorstore_reindex, actual_intensity 71, est_kwh 1.8, actual_emissions_kgco2: 0.128, baseline_emissions_kgco2: 0.248 (at 138), carbon_saved_kgco2: 0.120, saving_pct: 48%, csrd_eligible: true, dispatch_delay_h: 3.8. Every field populated. Every number traceable.

"One row in BigQuery. One job. Every number verifiable. The saving_pct is calculated from actual intensities — not estimates. An auditor can check the Carbon Footprint API data for europe-west3 at that timestamp and verify the 71 gCO₂eq/kWh figure independently. This is what auditable sustainability data looks like."

BigQuery ae_greenops.job_metricsCSRD eligible flag

CSRD Export · 2:00

Show the monthly CSRD Scope 3 export query

Run the monthly CSRD export query: SELECT reporting_period, 'Scope 3' as scope, 'Category 11' as category, 'GCP ML workload carbon optimisation' as activity, 'kgCO₂eq' as units, SUM(carbon_saved_kgco2) as total_saved, SUM(actual_emissions_kgco2) as total_actual FROM ae_greenops.job_metrics WHERE csrd_eligible = true AND DATE_TRUNC(dispatch_ts, MONTH) = CURRENT_DATE(). Show the result. This is the export that feeds directly into ClaraVis's CSRD sustainability report.

"Monthly CSRD export. One SQL query. Direct input to the sustainability report. The CFO and sustainability team can run this themselves — they don't need a data engineer to produce it. GreenOps makes the numbers, BigQuery makes them reportable."

BigQuery CSRD export queryScope 3 Category 11EU taxonomy aligned