In standard CRUD apps, if a user updates their profile name, you overwrite the database row. No big deal. But in CSRD (Corporate Sustainability Reporting Directive) software, overwriting a row is a compliance nightmare.
If an auditor asks, "Why did your Scope 1 emissions for 2024 change between July and October?" and your answer is "A dev ran a migration that updated the emission factors," you've just failed the audit.
To build a compliant carbon engine, you have to move away from "Current State" databases and toward Immutable Data Architectures. This is the pattern I use at GreenCalculus.com to ensure that once a report is "frozen," the data stays frozen—even if the underlying code or emission factors change.
The Problem: The "Floating" Emission Factor
Most carbon calculations look like this in the backend:
