The Autonomous Enterprise · AE Platform Layer · M-06

GreenOps Platform
Carbon-Aware Scheduling
— Defer when the grid is dirty. Dispatch when it's clean.

GreenOps is a cross-cutting platform service — it shifts every flexible AE workload from every domain suite to low-carbon grid windows without touching a single domain module. Hard-deadline jobs are never deferred. All carbon savings are auditable to the job level and exported as CSRD Scope 3 Category 11 emissions data, shared across the entire platform.

Carbon-aware scheduling · ±6h window GCP Carbon Footprint API GKE Autopilot · Cloud Scheduler CSRD Scope 3 · EU taxonomy AE Platform · H3 · PI-7 · Minimal Risk
System Context — C4 Level 1

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

GreenOps is the only AE Platform service with no HITL checkpoint and no human decision path. Scheduling decisions are fully autonomous within the ±6 hour deferral window. It serves all domain suites equally — the Autonomous Seller, Autonomous HR, and every suite that follows. The CTO and sustainability team are consumers of GreenOps output (the ESG metrics dashboard and Strategy Dashboard feed), not participants in its decisions.

Deferral Eligibility — AE Platform Batch Jobs (Representative — All Domain Suites)
JobSuite / ModuleScheduleDeadline typeMax deferralEligible for carbon deferral?
Weekly model retraining (RevRec AI)AS Suite · M-03Sundays 02:00 UTCSoft — weekly freshness±6 hours✓ Deferrable
Weekly model retraining (Asset IQ RUL)AS Suite · M-05Sundays 03:00 UTCSoft — weekly freshness±6 hours✓ Deferrable
Weekly model retraining (ContractGuard)AS Suite · M-02Sundays 04:00 UTCSoft — weekly freshness±6 hours✓ Deferrable
Daily feature pipeline backfillAE Platform · M-08Daily 01:00 UTCSoft — before daily RUL run±3 hours✓ Deferrable
Daily RUL batch predictionAS Suite · M-05Daily 02:00 UTCHard — FSM queue same dayNone✗ Never deferred
FinRisk anomaly model refreshAS Suite · M-04Daily 03:00 UTCHard — streaming model currencyNone✗ Never deferred
ContractGuard Vector Store reindexAS Suite · M-02Monthly, 1stSoft — monthly precedent freshness±12 hours✓ Deferrable
Container Diagram — C4 Level 2

Four deployable units. One scheduling boundary.

The GreenOps Platform boundary contains four distinct deployable containers. Each maps to a GCP-managed service with an explicit IAM surface and VPC-SC perimeter membership. Technology choices are documented in ADR-GO02 through ADR-GO05.

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 — no human is in the path. A circuit breaker wraps every Carbon Footprint API call: on timeout or 5xx, GreenOps enters degraded mode — all queued jobs dispatch immediately with api_fallback:true flagged in the ESG record, and full scheduling resumes on the next successful API response.

State Machine — Job Lifecycle

Five states. No dead ends. Every job dispatched eventually.

The GreenOps job state machine has no failure state — every job reaches COMPLETE. Hard deadline jobs bypass the DEFERRED state entirely. Window-expired jobs dispatch at whatever the current intensity is; the ESG record captures the actual emissions accurately (saving_pct = 0% in the worst case — the data is honest, not optimistic).

Data Flow Sequence

One deferred job. One ESG record. Every step timestamped.

The sequence shows a weekly ContractGuard Vector Store reindex arriving at 02:00 UTC, deferred because europe-west3 is at 142 gCO₂eq/kWh, re-evaluated five times across the 30-minute loop, dispatched at 06:12 when intensity drops to 74, and completing with a 49% carbon saving logged to BigQuery.

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 aggregates savings across all AE domain suites and is generated monthly from these records. The figures below are indicative of a full H3 platform deployment at ClaraVis's workload volume.

Monthly Carbon Saved
18.4
kgCO₂eq / month · all suites · all deferred jobs
Jobs Deferred (monthly)
14
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)
180 110 40 80 Dispatch window Dispatch window 00:00 04:00 08:00 12:00 16:00 20:00 24:00
Green shading = typical GreenOps dispatch windows · Dashed green = 80 gCO₂eq/kWh dispatch threshold Source: GCP Carbon Footprint API · europe-west3 · representative week
GreenOps Platform SLOs — Reliability Targets
Dispatch Latency P99
<90s
job submission → GKE dispatch · hard deadline path
Re-eval Loop Availability
99.5%
30-min cycle completes within 35 min · error budget: 3.6h/month
ESG Record Write SLO
99.9%
every dispatch writes BigQuery ESG record · CSRD completeness guarantee
SLO breach triggers Cloud Monitoring alert to the AE Platform on-call. Downstream suites are notified via the platform event bus. Circuit breaker (ADR-GO04) activates automatically — no manual intervention required. Error budget is tracked monthly and reviewed alongside CSRD savings figures.
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 across all domain suites — 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 feeds directly into ClaraVis's sustainability reporting tool and satisfies the EU taxonomy technical screening criteria for climate change mitigation.
Architecture Decision Records

Five GreenOps decisions. All 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 across AE Platform domain suites 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, which is statistically indistinguishable from expected model performance at the weekly evaluation frequency.
Accepted · Phase GreenOps Design · AE Platform
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, introducing a network egress path that must be documented in the VPC-SC threat model and approved by the CISO. For a platform-layer service serving all suites, 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 uses 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 · AE Platform
ADR-GO03 — GreenOps specific
Firestore (Datastore mode) as deferred queue — not Cloud Tasks
Cloud Tasks was the primary candidate for the deferred job queue — it is the canonical GCP service for delayed/scheduled task execution. Rejected for this use case 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 not "dispatch after N minutes" (Cloud Tasks' model) but "dispatch when a condition is met on a schedule" (a query pattern). (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. Cloud Tasks does not expose its queue as a queryable datastore. Firestore in Datastore mode provides this with native TTL on window_expiry, strong consistency within a single collection, and VPC-SC perimeter membership. The tradeoff — no native dead-letter queue — is mitigated by the window-expiry forced dispatch: every job that cannot be deferred successfully is force-dispatched at window_expiry, not lost. Document accumulation is bounded by the job volume (≤30 jobs/week at ClaraVis H3 workload) making unbounded growth not a concern at this scale.
Accepted · Phase GreenOps Design · AE Platform
ADR-GO04 — GreenOps specific
Carbon Footprint API circuit breaker — dispatch-all degraded mode, not block
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 domain suite training jobs in DEFERRED state, potentially cascading into model freshness violations for jobs approaching their window_expiry. Option B sacrifices carbon savings for the duration of the outage but maintains the scheduling reliability guarantee that GreenOps promises to all domain suites. Degraded-mode dispatches are flagged in BigQuery (api_fallback:true, saving_pct:0%) and excluded from CSRD savings calculations — the audit trail remains accurate. The circuit breaker threshold is: 3 consecutive API failures within a 5-minute window triggers degraded mode; recovery requires 2 consecutive successful API calls.
Accepted · Phase GreenOps Design · AE Platform
ADR-GO05 — GreenOps specific
Static 80 gCO₂eq/kWh dispatch threshold for MVP — adaptive threshold deferred to Phase 2
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. This approach adapts to seasonal variation: europe-west3's carbon intensity is meaningfully lower in summer (higher solar generation) than winter, so a static 80 gCO₂eq/kWh threshold may produce near-zero deferral in winter and near-100% deferral in summer. The adaptive threshold 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 Carbon Footprint API historical 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 needing to reconstruct 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.
Accepted (MVP) · Phase 2 target: rolling P75 · AE Platform
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 is the right number for this scope. GreenOps addresses Scope 2 emissions from ClaraVis's own GCP workloads across all domain suites, 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 platform-wide), produces auditable evidence (BigQuery per-job records), and contributes to the CSRD reporting obligation 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 — 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 model's performance metrics 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 at a single-deferral level. To guard against compounding deferrals (e.g., three consecutive Sunday deferrals during a sustained high-carbon-intensity period), Vertex AI Model Monitoring is configured with a weekly drift-detection check against the holdout set — if skew exceeds the defined threshold, an alert fires and the next retraining job is marked hard_deadline regardless of carbon intensity.
Evidence: ADR-GO01 (0.4% retraining interval increase · weekly evaluation frequency) · Job eligibility table (daily RUL and FinRisk = hard deadline, never deferred) · AS Suite RevRec AI Model Card (weekly retraining cycle) · Vertex AI Model Monitoring (weekly drift check · compounding-deferral safeguard)
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 captured in the metered_kwh field (sourced from GKE resource utilisation via Cloud Monitoring — 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 — every deferred job will hit its window expiry and dispatch 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 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 — a burst of three training jobs does not saturate GKE because each 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, saving_pct = 0%, and the CSRD export reflects 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.

00
Setup · 30s before
Open GreenOps monitoring and Carbon API dashboard
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 from across all active domain suites. This establishes the normal operating state before the demo job is submitted.
GreenOps monitoringCarbon API dashboardFirestore deferred queue
01
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 · suite: as_suite · 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 from the Autonomous Seller suite. GreenOps doesn't care which suite sent it — it checks the carbon intensity: 138 right now, above the 80 threshold. But the forecast shows 72 in about 3.8 hours. The job can wait."
Cloud Scheduler triggerCarbon Footprint APIGreenOps decision engine
02
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, suite_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
03
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
04
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, suite_id as_suite, actual_intensity 71, metered_kwh 1.8 (source: GKE Cloud Monitoring — not estimated), 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 metered and traceable.
"One row in BigQuery. One job from the AS Suite. The metered_kwh field is sourced from GKE resource utilisation via Cloud Monitoring — not an estimate. The saving_pct is calculated from actual carbon intensities. An auditor can verify the 71 gCO₂eq/kWh figure directly from the Carbon Footprint API at that timestamp. No estimates in this audit trail — none."
BigQuery ae_greenops.job_metricsCSRD eligible flag
05
CSRD Export · 2:00
Show the monthly CSRD Scope 3 export query — platform-wide
Run the monthly CSRD export query: SELECT reporting_period, 'Scope 3' as scope, 'Category 11' as category, 'GCP ML workload carbon optimisation — AE Platform all suites' 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) = DATE_TRUNC(CURRENT_DATE(), MONTH). Show the result. One query covers jobs from every domain suite.
"Monthly CSRD export. One SQL query. Covers every job across every AE domain suite. The CFO and sustainability team can run this themselves — they don't need a data engineer. GreenOps makes the numbers, BigQuery makes them reportable."
BigQuery CSRD export queryScope 3 Category 11EU taxonomy aligned
ESG Monitoring Dashboard — Live View Simulation

What the sustainability team sees. Every number from BigQuery.

This is the GreenOps monitoring view as it appears to the CTO and sustainability team — a read-only consumer of ae_greenops.job_metrics. No decisions are made here. Every figure shown is derived from the same BigQuery table that feeds the CSRD Scope 3 export. The live queue panel shows the current state of the Firestore deferred_jobs collection.

GreenOps ESG Dashboard · ae_greenops.job_metrics · europe-west3
● LIVE Last sync: 30s ago
MTD Carbon Saved
18.4
kgCO₂eq · all suites · 14 jobs
64% deferral rate this month
Current Intensity
92
gCO₂eq/kWh · above 80 threshold
Forecast min: 64 in +2.4h
Jobs In Queue
3
deferred · waiting for clean window
1 expiring soon · 2 waiting
API Status
OK
Carbon Footprint API · nominal
Circuit breaker: CLOSED · 0 fallback dispatches MTD
Carbon Intensity Forecast — europe-west3 · next 12h · gCO₂eq/kWh
160 110 80 50 80 NOW min 64 (+2.4h) Now +2h +4h +6h +9h +12h
Actual
Forecast
80 threshold
Dispatch window
Firestore deferred_jobs · 3 active
revrec_ai_weekly_retrain EXPIRING
suite: as_suite · M-03
submitted: 02:00 · expiry: 08:00 · 41m remaining
asset_iq_rul_weekly_retrain DEFERRED
suite: as_suite · M-05
submitted: 03:00 · expiry: 09:00 · 1h41m remaining
contractguard_weekly_retrain DEFERRED
suite: as_suite · M-02
submitted: 04:00 · expiry: 10:00 · 2h41m remaining
Next re-eval in 8m 22s · Forecast shows clean window at +2.4h · Expected dispatch: all 3 jobs
Recent Dispatches — ae_greenops.job_metrics · last 7 days
Job ID Suite Intensity metered_kwh CO₂ Saved Saving % CSRD
contractguard_vectorstore_reindex as_suite 71 1.8 0.120 kg 49% ✓
revrec_ai_weekly_retrain as_suite 68 4.2 0.318 kg 52% ✓
asset_iq_rul_weekly_retrain as_suite 74 6.1 0.391 kg 43% ✓
feature_pipeline_backfill ae_platform 86 0.9 0.000 kg 0% —
daily_rul_batch_prediction as_suite 104 2.3 — HARD —
Source: ae_greenops.job_metrics · BigQuery · europe-west3 metered_kwh: GKE Cloud Monitoring · carbon_intensity: GCP Carbon Footprint API · all figures audit-traceable
AE Platform Navigation
Three platform services.
GreenOps is the second.

Data Governance (M-08) is the H1 foundation — deployed first, before any suite. GreenOps (M-06) activates in H3 once workload volumes justify carbon scheduling. The Strategy Dashboard (M-07) closes the platform layer — reading GreenOps ESG metrics alongside signals from every domain suite and presenting the unified executive view.

M-07
Strategy Dashboard →
All suites, all signals, one screen · reads GreenOps ESG feed
→
M-08
← Data Governance · H1 Foundation
Deployed first · validates every record GreenOps defers
→
PG 09
← AE Platform Index
All platform services · deployment order · dependency matrix
→