The last stage of the GreenCode pipeline rates a system before and after optimisation against the Software Carbon Efficiency Rating, and returns the figures, the evidence behind them and a report a non-engineer can read.
Every earlier stage of the GreenCode pipeline changes something. The last stage changes nothing. Its job is to state, in terms someone outside the engineering team can read, what the software costs to run and how much of that cost the run removed.
It does this by rating the system against the Software Carbon Efficiency Rating, or an equivalent measure aligned with ISO/IEC 21031 software carbon intensity, twice. The first rating is taken on the original codebase running on its generated infrastructure. The second is taken on the optimised version in the same environment, under the same load. The gap between the two is the only claim the project is prepared to stand behind.
View full sizeCertification is stage five of five, and it consumes the output of the four before it. From the mapping stage it takes the software bill of materials and the inventory of interfaces and endpoints. From the quality baseline it takes maintainability, security and quality scores. From the infrastructure stage it takes the definition of the environment the measurements were made on. From benchmarking it takes energy and performance figures attributed to specific code constructs.
What comes out is a package rather than a number: a rating before and after, a management report, recommendations for infrastructure change, training material generated from the changes made to the team's own code, and every code change as a pull request on an optimisation branch, so a human approves each one.
A grade is only worth as much as the method behind it. Three things make this one checkable. The measurement boundary, the load profile and the infrastructure are recorded, so the before and after figures describe the same system doing the same work. The rating scale is a published standard rather than a vendor benchmark, so two products assessed this way can be compared. And the run records what was changed as well as what was measured, so an auditor can follow a reduction to the commits that produced it.
The project's own thresholds sit alongside the rating: a net energy reduction of at least 15% per system, progression towards an "A" rating, and no net increase in quality issues, security flaws or error rate. An improvement bought by degrading the software does not count.
The state of the art review traced where software certification has got to. Software carbon intensity was adopted as ISO/IEC 21031 in 2024 and aligns with ISO 14064 and the GHG Protocol, which gives a rating a standards footing that earlier green software schemes lacked. The same review found the remaining weakness to be traceability: results are often produced in a form that cannot be assured, certified or compared during procurement. That finding is what turned certification from a report into an evidence bundle.
The consortium contributes to the Green Software Foundation's open rating and measurement tooling rather than running a private scheme, because a rating nobody else can reproduce is worth little.
A grade a buyer can put in a specification changes what gets built. Four uses are already visible: comparing candidate products, answering tenders that attach green requirements to IT purchases, supporting disclosures under the reporting and due diligence directives, and substantiating environmental claims made to customers under the Green Claims Directive, where an unsupported claim is a legal exposure rather than a marketing line.
An easy to understand energy efficiency certificate for a software product is one of the deliverables GreenCode will bring to the market. What it means for a buyer is set out under certified software energy efficiency, and what it contributes to a company's disclosures under accurate ESG data for CSRD reporting.
Organisations that want to trial the rating on their own software can get in touch via the contact page.
