Why Emission Factors Must Be Versioned & Fail Closed

In software engineering, nobody would build a financial ledger where tax rates change retroactively without version control, or where the database silently guesses a foreign exchange rate when an API call times out. Yet in carbon accounting software, this happens routinely: emission factors are stored as mutable database rows, updated silently in the background, and missing factors are substituted with unverified AI proxies.

When a statutory body like SEBI, the European Commission, or the Bureau of Energy Efficiency audits an enterprise carbon record, they do not just check the final number. They ask: Which exact edition of the factor was used, what was its effective validity period, and can you recompute this exact total five years from today?

The Reality of Annual Factor Drift

Emission factors are not universal physical constants like the speed of light. They are empirical averages calculated and republished annually by national energy ministries and scientific bodies. Consider the evolution of the Indian National Grid Factor published by the Central Electricity Authority (CEA) in its *CO2 Baseline Database*:

If an enterprise inventory recalculates its FY 2021-22 electricity emissions using Version 20.0 instead of Version 18.0, the reported historical footprint shifts by over 1.5% through factor drift alone. If thousands of megawatt-hours are involved, this variation breaches statutory materiality thresholds.

The Architectural Pattern: Effective-Dated Factor Schemas

To maintain audit integrity, an emission factor table cannot be a simple key-value store. It must be implemented as a temporal, bitemporal, or effective-dated database schema:

When an invoice with billing date `2023-08-15` is processed, the deterministic engine executes a temporal range query (`valid_from <= invoice_date <= valid_to`), ensuring that the statutory factor active during that specific transaction period is applied, regardless of when the calculation is executed. This architecture powers ZeroCarbon's Carbon Emissions API and developer endpoints.

The Principle of Failing Closed

In cybersecurity and mission-critical systems, a firewall or authorization engine 'fails closed' (denies access) when an exception occurs, rather than 'failing open' (allowing unauthorized traffic). The same discipline must govern carbon accounting engines.

When an automated parser encounters an obscure fuel grade (e.g., a regional agricultural biomass briquette with unverified moisture content) or a transport route in an unsupported territory, there are two engineering paths:

• The Permissive (Hallucinatory) Path: An LLM or heuristic algorithm silently guesses an approximate factor, fills the table cell, and presents a 'complete' dashboard. The calculation finishes, but the resulting filing contains an unevidenced proxy that fails third-party audit.
• The Fail-Closed Path: The calculation engine immediately halts execution for that transaction, throws a typed validation error (`UnmappedEmissionFactorException`), and flags the item for human review and laboratory assay verification.

Base Year Recalculation Mechanics under GHG Protocol

Chapter 5 of the *GHG Protocol Corporate Standard* mandates that companies establish a Base Year Recalculation Policy. When significant structural changes occur (mergers, acquisitions, insourcing, or major methodological improvements in emission factors exceeding a significance threshold, typically 5%), the historical base year inventory must be recomputed.

If historical raw activity data was merged with calculated emissions in a single destructible field, recalculation is impossible without re-collecting raw bills. With an immutable ledger storing raw activity quantities ($Q$) separately from factor versions ($EF_v$), re-running a baseline inventory across five years requires simply replaying the event store against the new factor matrix.

ZeroCarbon's Calculation Engine Architecture

At ZeroCarbon, our calculation engine is strictly decoupled from language models and heuristic estimations. All emission factors are stored in an immutable, version-controlled factor repository where every factor carries statutory publication citations, effective date windows, and SHA-256 source verification digests. If our engine encounters an unmapped code or ambiguous parameter, it fails closed: prompting human compliance officers for verification rather than risking client audit failure on our enterprise carbon accounting platform.