Impact Manifest Protocol (IMP) Specification Project

[jawache]

@navveenb, @Henry-WattTime, @atg-abhishek, @seanmcilroy29

I'd like to start a conversation regarding turning the Impact Framework Manifest file into a standard for the transparent communication of the environmental impacts of software.

This is an example of a specification (the SCI) which drive the creation of software (IF) which in return drove the creation of a specification (IMP).

Background

Impact Framework is the evolution of a long series of discussions which started with the question, "How to make it easier to compute the SCI score of software" and ended by answering the question "How to compute an SCI score for software and provide enough evidence so others can verify".

IF is tooling but at it's core is a file format which is called the Impact Manifest. A very structured, formal method of writing and communicating the environmental impacts of software.

Link to the SCI

An Impact Manifest is a YAML format which enables you to express an SCI calculation in a way where the software boundary, the functional unit, the granular data, the coefficients and models are all transparently recorded.

One of the first exercises of the IF team was to convert all of the hand-written SCI Case Studies over to more formal Impact Manifest Files which can be executed and verified by IF tooling. This link shows all the SCI Use Cases expressed as Manifest Files: https://github.com/Green-Software-Foundation/if/tree/v0.1.9/examples/impls/case-studies

This link is the specific expression of the NTTData Hand Written Case-Study: https://github.com/Green-Software-Foundation/sci-guide/blob/dev/use-case-submissions/nttdatta-On-Premise-Web-system.md

As a more formal Manifest File Specification: https://github.com/Green-Software-Foundation/if/blob/v0.1.9/examples/impls/case-studies/ntt-data-on-premise.yaml

Motivation

If the Impact Manifest File was standardized as a communication protocol for Software Environmental Impact Reporting we would have a common way to express environmental impacts of software, a common language. A common communication standard encourages and supports the growth of the ecosystem of tooling which is starting to appear in this domain.

• Tooling is being built which is reporting an SCI score. We need a common way to communicate the evidence backing up that SCI score claim. A file where we can example the software boundary, the functional unit, the choices of I, the granularity of the data to ensure that the SCI is being computed in a way that adheres to the SCI specification.

• If you make a claim regarding an SCI score, i.e. disclose it using a SCER label or some other method. You should export an IMP file which shows evidence backing up that score, for example the QR code in a SCER label takes you to the IMP file which shows the evidence backing up your emissions claim.

Scope

• A specification which describes the environmental impacts of software in a YAML file format.
• The file must be re-executable to enable others to verify your claims.
• The file must contain enough information so your software boundary is transparent.
• The file must contain enough information so that your functional unit is transparent.
• The file must have enough information to make clear determinations regarding which models/methods/approaches/coefficients were used in the computation of your environmental impacts, e.g. did you use marginal or average.