Impact Framework

The engine operates through a composable plugin ecosystem where each plugin performs a discrete observation or calculation. Observers ingest real-world data from APIs like WattTime or Cloud Carbon Footprint, while models transform inputs into environmental metrics. This separation of concerns allows teams to swap data sources without rewriting calculation logic, ensuring adaptability as grid emission factors and hardware efficiency data evolve.

All measurement pipelines are defined declaratively through a manifest file (YAML), which specifies the directed acyclic graph (DAG) of plugin invocations. This approach provides:

• Reproducibility: The exact computation path is version-controlled alongside application code.
• Auditability: Every input, output, and transformation is explicitly declared, satisfying GHG Protocol documentation requirements.
• CI/CD Integration: Manifests execute deterministically in automated pipelines, enabling carbon budgets as deployment gates.

The framework synchronizes heterogeneous observations—such as CPU utilization sampled every 5 seconds and hourly grid carbon intensity—into a unified temporal resolution. It applies interpolation and aggregation strategies to align disparate data streams, ensuring that energy consumption and marginal emissions rates are multiplied at matching timestamps. This prevents the temporal mismatch errors common in manual spreadsheet-based carbon accounting.

The Impact Framework natively implements the Software Carbon Intensity (SCI) specification, calculating emissions per functional unit of work. The formula SCI = ((E * I) + M) / R is decomposed across plugins:

• E: Energy consumption from observers monitoring hardware or cloud billing data.
• I: Location-based marginal emissions rate from grid data providers.
• M: Embodied carbon amortized over hardware lifespan.
• R: Functional unit (e.g., API requests, users, transactions). This yields a rate metric actionable for comparison and optimization.

Beyond built-in calculations, the framework supports custom model plugins for domain-specific environmental impacts. Organizations can implement proprietary models for:

• Network data transfer carbon costs across internet infrastructure.
• On-device inference energy draw for edge AI deployments.
• Water consumption estimates for cooling systems. All custom models inherit the framework's validation and unit-conversion guarantees, maintaining calculation integrity across the pipeline.

Every computation produces a structured output file containing the full provenance chain: input parameters, plugin versions, timestamps, and intermediate values. This immutable record supports:

• Third-party assurance: External auditors can replay the manifest and verify results.
• Regulatory disclosure: Outputs map directly to CSRD and TCFD metric templates.
• Historical tracking: Stored outputs enable trend analysis without recomputation. The format ensures that sustainability claims are backed by transparent, verifiable evidence.

The total greenhouse gas emissions generated during the manufacturing, transportation, and disposal of hardware components. Distinct from operational emissions, embodied carbon is the M variable in the SCI specification and must be amortized over a device's useful life.

• Includes semiconductor fabrication energy
• Modeled via Life Cycle Assessment (LCA) databases
• Increasingly dominant as grids decarbonize
• Critical for edge and on-device AI sustainability reporting

The practice of time-shifting or location-shifting computational workloads to periods or regions where the carbon intensity of the electrical grid is lowest. This reduces operational emissions without reducing compute volume.

• Relies on real-time marginal emissions data
• Implemented via Kubernetes schedulers or batch job queues
• Can reduce training emissions by 30-50%
• A core use case for Impact Framework scenario modeling