AI COMPUTE · Playbook

Carbon-Aware ML Training

Every training run, large or small, carries a per-resource emissions record signed daily under Sigstore.

Time
18h
Difficulty
Elite
Practice Level
Elite
Steps
7
Score V2 lift
+52
Fellow points
2

IFO

Playbook

The Problem

The problem

Training runs are scheduled on the basis of GPU availability and engineer convenience, not on the basis of grid carbon intensity. The institution carries embedded carbon that cannot be defended on a regulatory disclosure form. As scope-2 disclosure becomes mandatory under SEC Climate, EU CSRD, and IFRS S2, the absence of per-resource emissions attribution becomes a regulatory exposure rather than an aesthetic choice.

The Detection

How you know it is happening

If the institution cannot produce, for any training run, a per-resource per-day emissions record under UFMS:003:2026, with a documented methodology and a named owner, the practice is below Best on this capability.

Practice Spectrum

AI Cost Attribution

You are here at Anti-Pattern

Anti-Pattern

Reactive

Best

Elite

Autonomous

AI inference is one consolidated invoice from the provider. Nobody can tell you the cost-per-token of the customer-support agent versus the marketing copy generator.

API keys are split per project, but attribution stops there. Per-feature, per-customer, and per-model cost is unknown.

Every inference call carries a tag for product, model, and customer cohort. Per-feature unit economics are reported monthly.

Cost-per-inference is computed per call, streamed to a real-time ledger, and exposed to the product team. Budget guardrails fire at the agent level.

AI cost is allocated per token, per call, per customer, in real time, with model card lineage and carbon disclosure attached. The agent budget is itself a controlled object.

III

The Outcome

What success looks like

Every training run, large or small, carries a per-resource emissions record signed daily under Sigstore. Region selection is informed by grid carbon intensity. Training schedules are deferred where possible to lower-intensity windows. Disclosure is regulator-grade and externally verifiable.

Cost delta

-2 to -8 percent training cost via region and window selection

Efficiency

+9 efficiency points (Score V2)

Value lift

+24 value points (Score V2 GreenOps modifier)

Risk reduction

-19 risk points (regulatory disclosure posture)

Ship It

The steps, in order.

I
Step 01
Adopt UFMS:003:2026 GreenOps Annex
Adopt the UFMS:003:2026 schema for per-resource per-day emissions ledgers. The schema includes nine attribution columns plus a methodology field. Treat the schema as the single accepted format for all internal disclosure.
II
Step 02
Map every training environment to a region
For every training cluster, capture the region, the cloud provider, and the published power-usage-effectiveness factor. Where the provider publishes hour-by-hour grid emissions data, integrate it. Where the provider publishes only annual averages, document that and treat the average as a floor rather than a ceiling.
bash
```
gcloud compute regions list \
  --format="table(name,description,cfeRegions.cfeScore)"
```
III
Step 03
Stream the training-run ledger
For every training job, emit a record to BigQuery containing job_id, model, framework, GPU type, GPU hours, region, kWh estimated, kgCO2e estimated, methodology, and signed_at. The aim is that every run is queryable, and queries do not depend on log archaeology.
IV
Step 04
Stand up the daily Sigstore signature
At the close of each day, hash the day’s training-run ledger and sign the hash with the IFO4-style Sigstore key. Publish the signature alongside the ledger. The aim is that any external verifier (auditor, regulator, customer) can independently confirm the ledger has not been tampered with.
V
Step 05
Author the carbon-aware scheduler
For training jobs that tolerate latency, accept a carbon-intensity-window argument. The scheduler defers job start until the next acceptable window in the chosen region, or migrates the job to a paired region where supported. Document the decision rule and the supported job classes.
yaml
```
job:
  id: train-rec-v3
  framework: pytorch
  duration_estimate_hours: 9
  carbon_window:
    max_intensity_g_co2e_per_kwh: 150
    timeout_hours: 24
  region_preference: ["us-central1", "europe-west1"]
```
VI
Step 06
Publish a monthly disclosure record
Each month, publish the institution’s aggregate training emissions, decomposed by team, model family, and region. The disclosure is intended to be regulator-grade and is published under CC-BY-4.0 so external parties may cite it without licensing.
VII
Step 07
Integrate disclosure with the Score V2 modifier
Wire the monthly emissions ledger into the Score V2 GreenOps modifier. The aim is that the institution sees a direct link between disclosure discipline and its position on the Score V2 trajectory.

The Templates

Templates and starter code

json

Template

ufms-003-greenops-schema.json

UFMS:003 GreenOps Schema

Reference schema for per-resource per-day emissions ledgers, including all nine attribution columns and a methodology field.

Download ↓

yaml

Template

carbon-aware-scheduler.yaml

Carbon-Aware Scheduler Configuration

YAML configuration for the carbon-aware scheduler, including region preferences, intensity thresholds, and timeout behaviour.

Download ↓

Template

monthly-greenops-disclosure.md

Monthly Disclosure Template

Markdown template for the monthly emissions disclosure, organised by team, model family, region, and methodology notes.

Download ↓

The Evidence

Prove it.

I
Training-run ledger sample
Thirty-day BigQuery export demonstrating UFMS:003 conformance and completeness.
Sigstore
II
Daily Sigstore signature trail
Thirty consecutive days of signed daily ledger snapshots, with verification key published.
Sigstore
III
Carbon-aware scheduler configuration
Committed YAML configuration with documented region and intensity thresholds.
Recorded
IV
Monthly disclosure publication
Three consecutive monthly disclosures published under CC-BY-4.0 and linked from the institution’s sustainability page.
Sigstore

VII

The Impact

What this earns you.

Score V2 lift

+52

across the four Score V2 vectors. Sustained practice raises the institutional trajectory.

Distinguished Fellow

contribution points toward the Fellow lineage when published with signed evidence.

Maturity Pillars

Visibility · Governance · Culture · Optimization

Adopters

Be among the first to publish your completion.

The cohort sample is below the publish threshold (N<5). When we have at least five completions, this panel will surface the median score lift, median cost savings, and median time to complete from the IFO4 impact API.

View impact →

VIII

Pair this with

Related playbooks.

AI Compute · Best

AI Cost-per-Inference Governance

AI inference invoices arrive as a single consolidated charge per provider per month.

Open →

Governance · Elite

Tag Enforcement at Provisioning Time

Tag policies exist on paper.

Open →

SaaS · Best

SaaS Sprawl Detection and Remediation

SaaS subscriptions accumulate quietly through expense cards, individual purchase orders, and shadow IT.

Open →

Begin the playbook

Ship it. With evidence.

Start the playbook, simulate the impact first, or take it to the community. Every move is logged.

Start this playbook Simulate the impact first Discuss in the community →

IFO4

Best PracticesAn IFO4 Platform

AI COMPUTE · Playbook

Carbon-Aware ML Training

Every training run, large or small, carries a per-resource emissions record signed daily under Sigstore.

Time
18h
Difficulty
Elite
Practice Level
Elite
Steps
7
Score V2 lift
+52
Fellow points
2

IFO

Playbook

The Problem

The problem

The Detection

How you know it is happening

Practice Spectrum

AI Cost Attribution

You are here at Anti-Pattern

Anti-Pattern

Reactive

Best

Elite

Autonomous

AI inference is one consolidated invoice from the provider. Nobody can tell you the cost-per-token of the customer-support agent versus the marketing copy generator.

API keys are split per project, but attribution stops there. Per-feature, per-customer, and per-model cost is unknown.

Every inference call carries a tag for product, model, and customer cohort. Per-feature unit economics are reported monthly.

Cost-per-inference is computed per call, streamed to a real-time ledger, and exposed to the product team. Budget guardrails fire at the agent level.

AI cost is allocated per token, per call, per customer, in real time, with model card lineage and carbon disclosure attached. The agent budget is itself a controlled object.

III

The Outcome

What success looks like

Cost delta

-2 to -8 percent training cost via region and window selection

Efficiency

+9 efficiency points (Score V2)

Value lift

+24 value points (Score V2 GreenOps modifier)

Risk reduction

-19 risk points (regulatory disclosure posture)

Ship It

The steps, in order.

I
Step 01
Adopt UFMS:003:2026 GreenOps Annex
Adopt the UFMS:003:2026 schema for per-resource per-day emissions ledgers. The schema includes nine attribution columns plus a methodology field. Treat the schema as the single accepted format for all internal disclosure.
II
Step 02
Map every training environment to a region
For every training cluster, capture the region, the cloud provider, and the published power-usage-effectiveness factor. Where the provider publishes hour-by-hour grid emissions data, integrate it. Where the provider publishes only annual averages, document that and treat the average as a floor rather than a ceiling.
bash
```
gcloud compute regions list \
  --format="table(name,description,cfeRegions.cfeScore)"
```
III
Step 03
Stream the training-run ledger
For every training job, emit a record to BigQuery containing job_id, model, framework, GPU type, GPU hours, region, kWh estimated, kgCO2e estimated, methodology, and signed_at. The aim is that every run is queryable, and queries do not depend on log archaeology.
IV
Step 04
Stand up the daily Sigstore signature
At the close of each day, hash the day’s training-run ledger and sign the hash with the IFO4-style Sigstore key. Publish the signature alongside the ledger. The aim is that any external verifier (auditor, regulator, customer) can independently confirm the ledger has not been tampered with.
V
Step 05
Author the carbon-aware scheduler
For training jobs that tolerate latency, accept a carbon-intensity-window argument. The scheduler defers job start until the next acceptable window in the chosen region, or migrates the job to a paired region where supported. Document the decision rule and the supported job classes.
yaml
```
job:
  id: train-rec-v3
  framework: pytorch
  duration_estimate_hours: 9
  carbon_window:
    max_intensity_g_co2e_per_kwh: 150
    timeout_hours: 24
  region_preference: ["us-central1", "europe-west1"]
```
VI
Step 06
Publish a monthly disclosure record
Each month, publish the institution’s aggregate training emissions, decomposed by team, model family, and region. The disclosure is intended to be regulator-grade and is published under CC-BY-4.0 so external parties may cite it without licensing.
VII
Step 07
Integrate disclosure with the Score V2 modifier
Wire the monthly emissions ledger into the Score V2 GreenOps modifier. The aim is that the institution sees a direct link between disclosure discipline and its position on the Score V2 trajectory.

The Templates

Templates and starter code

json

Template

ufms-003-greenops-schema.json

UFMS:003 GreenOps Schema

Reference schema for per-resource per-day emissions ledgers, including all nine attribution columns and a methodology field.

Download ↓

yaml

Template

carbon-aware-scheduler.yaml

Carbon-Aware Scheduler Configuration

YAML configuration for the carbon-aware scheduler, including region preferences, intensity thresholds, and timeout behaviour.

Download ↓

Template

monthly-greenops-disclosure.md

Monthly Disclosure Template

Markdown template for the monthly emissions disclosure, organised by team, model family, region, and methodology notes.

Download ↓

The Evidence

Prove it.

I
Training-run ledger sample
Thirty-day BigQuery export demonstrating UFMS:003 conformance and completeness.
Sigstore
II
Daily Sigstore signature trail
Thirty consecutive days of signed daily ledger snapshots, with verification key published.
Sigstore
III
Carbon-aware scheduler configuration
Committed YAML configuration with documented region and intensity thresholds.
Recorded
IV
Monthly disclosure publication
Three consecutive monthly disclosures published under CC-BY-4.0 and linked from the institution’s sustainability page.
Sigstore

VII

The Impact

What this earns you.

Score V2 lift

+52

across the four Score V2 vectors. Sustained practice raises the institutional trajectory.

Distinguished Fellow

contribution points toward the Fellow lineage when published with signed evidence.

Maturity Pillars

Visibility · Governance · Culture · Optimization

Adopters

Be among the first to publish your completion.

View impact →

VIII

Pair this with

Related playbooks.

AI Compute · Best

AI Cost-per-Inference Governance

AI inference invoices arrive as a single consolidated charge per provider per month.

Open →

Governance · Elite

Tag Enforcement at Provisioning Time

Tag policies exist on paper.

Open →

SaaS · Best

SaaS Sprawl Detection and Remediation

SaaS subscriptions accumulate quietly through expense cards, individual purchase orders, and shadow IT.

Open →

Begin the playbook

Ship it. With evidence.

Start the playbook, simulate the impact first, or take it to the community. Every move is logged.

Start this playbook Simulate the impact first Discuss in the community →