You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Redefining the boundary of what you are measuring can improve your score and increase your rating compared to past scores or competitors' scores.
For physical products, that might be similar to deciding not to include the accessories. For digital, it's redefining what you consider a component of your software system, e.g. moving a database away from your DC to a SaaS provider and then deciding not to include it in your measurement.
This is a core discussion point of the SCI since inception and the reason the SCI has provision to ensure that the software boundary is documented in any report of an SCI score. The first step is transparency, the next step is defining the expected boundary for different categories of products.
Equivalence
In the physical world, this is not a problem; you can't submit a fridge that is missing a door to be scored. So, methods like the Nutri-score and Energy Star do not need to be so concerned about boundary redefinition; it's objectively true what the boundaries of their products are.
The closest equivalent is perhaps the ingredient label on a food product and the nutri-score, the list of ingredients is a statement of what is actually being measured, and the score is the rating but it's based off a transparent record of exactly what the food contains.
The nutri-score scale might be voluntary but it is based on decades of transparent ingredient data enforced and regulated by government agencies, with many follow on studies run on the data.
Counter
Any claim made needs to be backed up by evidence and a clear statement regarding what is being included and excluded in the computation.
Any change to the claimed metric needs to be backed up by a document explaining what triggered the change, a boundary redefinition, or a re-engineering effort.
If this is an SCI score, then SCI should make it clear exactly what should be included and excluded in the boundary for different domains.
The impact manifest file format is a good candidate for this type of reporting, as it is transparent about what is being included in the computation, how that computation was made, and the aggregate emissions values.
The text was updated successfully, but these errors were encountered:
Redefining the boundary of what you are measuring can improve your score and increase your rating compared to past scores or competitors' scores.
For physical products, that might be similar to deciding not to include the accessories. For digital, it's redefining what you consider a component of your software system, e.g. moving a database away from your DC to a SaaS provider and then deciding not to include it in your measurement.
This is a core discussion point of the SCI since inception and the reason the SCI has provision to ensure that the software boundary is documented in any report of an SCI score. The first step is transparency, the next step is defining the expected boundary for different categories of products.
Equivalence
Counter
The text was updated successfully, but these errors were encountered: