A draft would name software carbon inside OpenTelemetry
A Green Software Foundation assembly is drafting OpenTelemetry names for software carbon intensity. The CNCF post says the conventions are not adopted yet.
The short version
No. A foundation assembly is drafting names for the pieces of the software carbon intensity formula, and an OpenTelemetry community issue asks for review. The CNCF post says the work is a proposal, not an entry already in the registry.
A vocabulary, not a shipped field
Diana Todea's October 15 post on the CNCF blog describes a keynote at Observability Summit Europe about treating software carbon intensity as something OpenTelemetry could name. The post says the Green Software Foundation's work is aimed at a common language for carbon-related telemetry. It also says the point is not to replace existing signals. A consistent description, beside the context operators already collect, is the claim. An emissions number and the hour it belongs to are a standing question on the energy desknameplate capacity.
What the assembly is for
The foundation's assembly page says OpenTelemetry's semantic-conventions registry is the shared vocabulary for metrics, logs, traces, and profiles. Without carbon names in that registry, each team invents attribute names and metric keys. The assembly's job is to draft conventions for the formula's components and submit them to the OpenTelemetry Semantic Conventions SIG. The page dates the work from July 23, 2026, through December 31, 2026. A draft with an end date is not a merged registry. The distributed-cloud desk isDistributed Cloud.
The four pieces the issue lists
OpenTelemetry community issue 3539 asks for semantic conventions covering operational energy, the carbon intensity of electricity, embodied carbon, and the functional unit. It says the foundation, with named collaborators, will propose a baseline and follow a federated model, hosting a registry under the foundation while seeking review from the general semantic-conventions group. Standardizing the names would let collectors and backends agree. The issue is the request. It is not the approval. The software desk is Asked directly, Is ISO 21031 the same document as the OpenTelemetry registry? The GitHub issue identifies the software carbon intensity specification with ISO/IEC 21031:2022, maintained by the Green Software Foundation. The registry change is the thing still under discussion.Software.
What the first phase closed
The CNCF post says the first phase of the assembly, focused on scope and use cases, has concluded with community consensus. It says a shared requirement came out of the use cases: carbon telemetry has to state its boundaries, its calculation method, its functional unit, and what kind of value is being reported. Those are labels a reader would need before comparing two scores. They are also the part that is still a requirement, not a field in a released schema. The energy desk isEnergy.
What a keynote does not settle
The summit schedule lists the talk as a keynote on designing a standard. A talk can show the shape of a convention. The adoption path the assembly describes runs through a SIG review after the draft exists. This page will not report the conventions as live in OpenTelemetry collectors. The paper is Asked directly, Which formula pieces does the GitHub issue name? Operational energy, the carbon intensity of electricity, embodied carbon, and the functional unit. The issue uses the letters E, I, M, and R for those pieces.Futureweb.
Who is in scope
The audience is people who already emit OpenTelemetry and want a shared name for a carbon figure, plus the foundation members drafting that name. A company dashboard that already invented its own keys is the fragmentation the assembly page describes. Nothing here requires a team to publish a carbon score. The security desk is Asked directly, When does the assembly page say the work runs? It lists a start of July 23, 2026, and an end of December 31, 2026. The CNCF post says the first phase, on scope and use cases, has concluded with community consensus.Security.
What this brief will not convert
A methodology for software carbon intensity is not an emissions inventory of a data center, and a proposed attribute is not a bill. The registry, if it later accepts the names, would say how to label a measurement. It would not say that the measurement was done correctly. That limit is why the post's phrase, a first-class signal, stays a design goal on this page. The open-source desk is Asked directly, Does the CNCF post say carbon replaces latency and errors? It says the opposite shape: carbon would sit beside the operational context engineers already collect, not instead of it.Open Source.
The specification and the registry
The issue ties the formula to the foundation's specification and to ISO/IEC 21031:2022. Those documents can exist while the OpenTelemetry names do not. A reader can study the formula and still have no standard attribute to put on a span. That gap is the story. Hardware is Asked directly, What does the assembly say it will hand over? A proposed set of semantic conventions for submission to the OpenTelemetry Semantic Conventions SIG. The assembly page says the goal is formal adoption. Goal is not the same word as adopted.Hardware.
The line to re-check
If the semantic-conventions registry later lists these names, this page's answer changes. Until that landing, the record is an assembly, an issue, and a CNCF post that says the work is underway. Consensus on scope is not consensus on the final keys. The short answer this page will stand on is this: No. A foundation assembly is drafting names for the pieces of the software carbon intensity formula, and an OpenTelemetry community issue asks for review. The CNCF post says the work is a proposal, not an entry already in the registry.
Sources
The reports this brief is filing. Futureweb did not republish them.
Questions
What does the assembly say it will hand over?
A proposed set of semantic conventions for submission to the OpenTelemetry Semantic Conventions SIG. The assembly page says the goal is formal adoption. Goal is not the same word as adopted.
Which formula pieces does the GitHub issue name?
Operational energy, the carbon intensity of electricity, embodied carbon, and the functional unit. The issue uses the letters E, I, M, and R for those pieces.
When does the assembly page say the work runs?
It lists a start of July 23, 2026, and an end of December 31, 2026. The CNCF post says the first phase, on scope and use cases, has concluded with community consensus.
Does the CNCF post say carbon replaces latency and errors?
It says the opposite shape: carbon would sit beside the operational context engineers already collect, not instead of it.
Is ISO 21031 the same document as the OpenTelemetry registry?
The GitHub issue identifies the software carbon intensity specification with ISO/IEC 21031:2022, maintained by the Green Software Foundation. The registry change is the thing still under discussion.