Veridian

Result and evidence

• −15% cloud emissionsControlled evaluationAgainst the default unscheduled Cloud Run service.
• 99.9% observed uptimeControlled evaluationCloud Run evaluation, not a production SLO.

The case

Problem

Selecting compute after provisioning or a demand-driven scale event means remediation arrives after the expensive decision has already been made.

Decision

Inspect Terraform before provisioning. Vertex AI recommends a lower-carbon compute configuration. The carbon ledger stays off the request path.

Constraint

The ledger had to stay off the request path so a slow or missing carbon number could not stall a provision.

Example

Input: a Terraform intent. Output: a recommended compute configuration, with the carbon ledger written beside the request, not on it.

Considered and rejected

Putting the ledger on the request path, which would stall provisioning; and selecting compute after provisioning, which arrives too late.

Architecture, on Cloud Run

1. GitLab Duo + MCP
2. Vertex AI

Around it

1. BigQueryESG ledger
2. Pythonglue

What was built

1. GitLab Duo plus MCP intercept Terraform and Kubernetes changes.
2. Vertex AI recommends a quantised, lower-carbon compute configuration.
3. BigQuery holds the ESG ledger, off the request path.

Limitations

The evaluation period, sample size and emissions-calculation source were not recorded.

What I would change now

Record those three items.