Methodology

CO2 Router is not a scheduler.It is a control plane.

Modern infrastructure is no longer optimized. It is governed. Most existing systems operate as schedulers or advisors. They suggest better placements or defer workloads based on forecasts. CO2 Router introduces a different model: a deterministic compute control plane that enforces execution decisions before workloads run, with SAIQ governance and replayable proof attached to the same frame.

Category overview

Advisory systems optimize.CO2 Router enforces.

The architectural difference is decision authority. Most products in this category are informational or advisory layers. They expose telemetry, recommend a cleaner region, or tune scheduling heuristics. CO2 Router sits in front of execution targets and returns a binding action before compute is admitted.

System TypeDecision AuthorityProofMulti-ObjectiveReal-Time Enforcement
Academic schedulersAdvisoryNoPartialNo
Carbon APIsInformationalNoCarbon-onlyNo
Cloud policiesStatic rulesNoLimitedPartial
CO2 RouterDeterministicYesCarbon + water + latency + costYes
Existing approaches

Academic schedulers

PCAPS, carbon-aware cluster schedulers, and microservice placement systems optimize placement with mathematical models, heuristics, or probabilistic guarantees.

PCAPS / CAPDRO fleet schedulersAceso
Limitations
Advisory, not binding
No audit-grade proof
Not built as production enforcement layers

Signal providers

Carbon and water signal providers expose telemetry that others can consume, but they do not decide or enforce where compute runs.

WattTimeWRI AqueductAWARE
Limitations
No decision authority
No enforcement path
No multi-objective reasoning on their own

Audit systems

Tamper-evident logging systems prove that a record was not modified, but they do not control execution or policy outcomes.

RatifioHash-chain audit patterns
Limitations
No decision intelligence
No execution control
No routing or workload governance

Enforcement primitives

Admission controllers and policy engines can block unsafe resources, but they do not perform multi-objective routing or generate full decision proof on their own.

GatekeeperValidating admission policy
Limitations
No carbon-water decision intelligence
No replayable baseline-vs-selected proof
Require a control plane to tell them what to enforce
What CO2 Router does differently

One decision engine. Five binding outcomes.

CO2 Router unifies real-time signal evaluation, deterministic decisioning, enforcement at execution time, replayable audit proof, and multi-objective tradeoffs across carbon, water, latency, and cost. Every workload is evaluated before execution and results in one binding action.

run_now
Execute immediately because the current target satisfies doctrine, latency, and cost constraints.
reroute
Move execution to a cleaner or less water-stressed region before resources are allocated.
delay
Hold execution until a cleaner time window arrives inside the workload deadline.
throttle
Reduce resource intensity when the job must proceed but environmental conditions are degraded.
deny
Block execution when doctrine is violated and no acceptable alternative exists.
Proof + audit

Audit-grade verification instead of estimated reporting.

Every decision produces the evidence required to explain, replay, and verify what happened. This is the difference between a sustainability narrative and a defensible control surface.

Baseline vs selected outcome
Shows the counterfactual target beside the enforced choice and the delta achieved.
Signal lineage
Records which carbon and water signals were used, with freshness and fallback state.
Policy trace
Captures which doctrine rules and thresholds produced the final action.
Replayable decision frame
Preserves the exact decision context so the engine can recompute the result later.
Cryptographic hash-chain record
Makes the historical trail tamper-evident instead of narrative-only logging.
Positioning line
CO2 Router is not a scheduler.
It is a control plane.
It does not recommend. It enforces.
Source base

Primary references behind the category argument

This methodology is grounded in control-plane architecture, marginal emissions logic, water risk datasets, hash-chain audit patterns, and carbon-aware scheduling literature.