Can AI Impact Receipts Be Standardized? CarbonLayer's Open Exploration

When a developer tool can only serve one company, it's just a product feature. But when different systems can produce and consume the same information, it has the potential to become infrastructure. The CarbonLayer team is exploring the concept of an "Impact Receipt," trying to answer a core question: Can we standardize how AI environmental impact is described without standardizing misleading assumptions?

Why AI Impact Receipts Need Standardization

The energy and environmental cost of training and running AI models is becoming an issue the industry cannot avoid. Yet the current reality is this: different AI providers use completely different ways of describing the same concept, carbon values are calculated with different boundaries, and when providers lack sufficient evidence, they often choose to return a seemingly precise number rather than honestly saying "unavailable."

In the third part of its article series, CarbonLayer already explored what fields an AI impact receipt should contain: workload information, model identity, latency, environmental metrics, methodology, provenance, and uncertainty. But identifying useful fields is only the starting point. The real challenge is: what happens when two AI providers describe the same concept in different ways? When two systems return carbon values calculated based on completely different boundaries, how should developers interpret them?

The answers to these questions determine whether an impact receipt is industry infrastructure or just another flashy product feature.

Accounting boundary refers to the explicit definition of which emission sources are included in the scope when calculating environmental impact. For example, a boundary that only includes GPU accelerator electricity consumption will ignore server hosts, cooling systems, network transmission, and even lifecycle emissions from hardware manufacturing and disposal. With different boundaries, the carbon value for the same inference can differ by several times. This is why even if two systems return the same field names and units, their results may still be incomparable. If standardization only unifies fields without disclosing boundaries, it is using consistency in format to conceal semantic incommensurability.

Standardize the Interface, Not the Calculation

The first key distinction CarbonLayer proposes is: the goal of standardization should not be to require every AI provider to calculate environmental impact in exactly the same way. Different providers use different hardware, workloads, measurement systems, and data sources. A universal calculation methodology would require consensus on questions that are still in the research stage, which is not realistic in the short term.

But we can start from a more practical level: can we agree on "how to describe what we know, what we don't know, and how we came to know it"?

Imagine a system with a defensible carbon estimate. It might represent the result as structured data containing status (available), value (14.7), unit (gCO2e), evidence type (modeled), and methodology version. The key is not the number itself, but that the receiving application can distinguish value, unit, evidence type, and methodology. A shared interface can make information exchange easier without pretending that every provider's calculation is equivalent.

Consistent JSON Does Not Equal Comparable Results

Suppose three providers return environmental data: Provider A returns {"carbon": 14.7}, Provider B returns {"emissions": 0.0147}, and Provider C returns {"impact": {"co2e_g": 14.7}}. Before discussing measurement, we first face an integration problem: are these grams or kilograms? Is it CO2 or CO2 equivalent? What activities are included?

A common interface can eliminate some ambiguity. But the truly difficult case is: every provider returns the same JSON structure, yet uses different accounting boundaries—one includes only accelerator electricity consumption, another includes servers and cooling overhead, and a third also includes additional lifecycle impacts. The data looks standardized, but the results are still incomparable. Standardizing syntax is not the same as standardizing semantics, which is exactly why provenance, accounting boundaries, and methodology must be central to the discussion.

"Unavailable" May Be the Most Important Field

One of the biggest mistakes an environmental API can make is returning a number that looks precise but lacks sufficient supporting evidence. Suppose a system knows what the requested model is, but cannot determine how much electricity that specific inference consumed. Should it return a default energy value? Should it infer carbon emissions solely from token count? Should it fill missing water data with zero?

CarbonLayer's position is clear: it should not. A proposed receipt can return a structure with each metric's status as "unavailable" and value as null. Zero is a value; unavailable is an evidence state, and the two should never be interchangeable. A standard that allows explicit missing values is more trustworthy than one that forces every provider to fill every field. This also creates a gradual path for systems: they can adopt the interface before they have sufficient evidence.

The Essential Difference Between Measured, Modeled, Derived, and Unavailable Values

A useful specification should distinguish several evidence types:

• Measured: Supported by a documented measurement process with clearly defined boundaries
• Modeled: Estimated using assumptions, coefficients, or computational models
• Derived: Calculated from other inputs, whose original evidence types must remain traceable
• Unavailable: A value that currently cannot be sufficiently supported

These categories should not be treated as interchangeable. Even if the calculation process is correct, the result still depends on the quality, coverage, and compatibility of the inputs. A calculated emissions value does not become a direct measurement just because one of its inputs is measured. Adding more decimal places does not make an estimate more accurate. A receipt needs to preserve the evidence behind the result, and when the evidence is insufficient, it should say so honestly.

Expressing uncertainty is a long-standing challenge in environmental accounting. Confidence scores seem intuitive, but they easily create a false sense of precision: what exactly does a confidence of 0.8 mean? Is it a statistical interval, expert judgment, or the probability of a model output? CarbonLayer prefers not to invent such numbers, but instead to express credibility indirectly through evidence type and provenance. Measured values come with a measurement process and boundaries, modeled values come with assumptions and coefficient sources, and derived values require that original evidence types remain traceable. The advantage of this approach is that the receiver can judge for themselves based on the evidence chain, rather than being misled by an unexplainable score.

Why Methodology and Version Management Matter

Imagine an organization reported environmental impact data in January and reported lower values again in June. Is it because the workload became more efficient? Did the infrastructure change? Did the accounting boundary change? Or did the methodology itself change?

Without methodology version management, trend changes are difficult to interpret. A future receipt might include a methodology ID, version number, boundary description, and reference links. The goal is not to hide changes, but to make them visible and avoid silently mixing incompatible results. The specification should also define what happens when a methodology is deprecated, a data source changes, or historical values are recalculated. A number without methodology is hard to verify; a number without methodology versioning is hard to compare across time.

Location Information: Useful but Privacy-Sensitive

The environmental characteristics of computing infrastructure depend on location, time, power supply, and system boundaries, so location context may be useful in an impact receipt. But there is a complication here: the location needed for environmental accounting is not necessarily the location a provider should disclose to every API consumer.

Future specifications may need to support different levels of detail: geographic region, grid region, country-level information, restricted or undisclosed location. It also needs to identify whether the location represents the actual execution site, billing region, modeling assumption, or something else. Otherwise, developers may mistakenly interpret a routing label as proof of where the computation physically occurred. This again shows that standardization is a semantic problem, not just a JSON design problem.

What Existing Standards Can Teach Us

CarbonLayer emphasizes that there is no need to invent every concept from scratch. Several existing efforts provide useful foundations:

OpenTelemetry's semantic conventions for generative AI provide useful references for describing AI operations, model-related attributes, and telemetry. Impact receipt proposals should study how to reuse compatible observability concepts rather than introducing unnecessary new terminology. But compatibility with observability conventions does not by itself validate environmental calculations.

The Software Carbon Intensity (SCI) specification provides a way to express software carbon intensity, including defined boundaries and functional units, and offers important lessons in methodology and normalization. But citing SCI does not mean a particular inference receipt is an SCI score, nor does it mean a product complies with that specification.

CodeCarbon demonstrates methods for estimating emissions associated with computational workloads and is a useful example. But workload-level estimation methods do not automatically establish defensible attribution for every API request.

These efforts provide building blocks, but they do not automatically establish a universal, interoperable, validated per-inference impact receipt standard. That remains an open design question.

Generative AI semantic conventions are a specification effort being advanced by the OpenTelemetry community, aiming to define a unified telemetry attribute namespace for AI operations such as LLM calls, vector retrieval, and tool calls—for example, model name, token usage, and request latency. Its core value lies in turning "AI operations" into observable objects, so that trace data produced by different frameworks and providers can be consumed by the same set of backend tools. For impact receipts, this means receipt fields can reuse existing attribute semantics and reduce duplicate definitions. But one must be careful: observability conventions solve "how to describe an operation" and do not verify whether the environmental values bound to it are reliable. The trust foundations of the two are completely different.

The Danger of Premature Standardization

Standards can make data easier to exchange, and they can also make weak data look more authoritative. If every AI provider returns a field named carbon.value, developers may assume those values are comparable. But what if one provider uses physical measurements, another uses a whole-fleet average, and a third uses a token-based proxy? A common field name does not resolve these differences.

A credible specification needs to answer some difficult questions: What qualifies as a measured value? Which boundaries must be disclosed? How should modeled and derived values be marked? When should a field be marked unavailable? What information is necessary for reproducibility? How should uncertainty be represented without inventing confidence scores? How can incompatible results be prevented from being aggregated? What operational or geographic information can be safely disclosed? How should the interface evolve without breaking existing consumers?

Software Carbon Intensity (SCI) was proposed by the Green Software Foundation. Its core idea is to normalize software emissions into "carbon per functional unit," requiring explicit functional units, time boundaries, and included emission sources (operational, embodied, etc.). Its most valuable lesson is the discipline of "making boundaries explicit": without declaring boundaries, numbers are meaningless. But SCI is aimed at software as a whole or at the service level. When applied to a single inference, how the functional unit is defined and how shared infrastructure is allocated remain unresolved. Therefore, citing SCI is more of a methodological stance than a compliance endorsement of any specific receipt.

Value Beyond the Carbon Number

CarbonLayer currently has two different demo interfaces: the /api/inference endpoint returns simulated, illustrative routing metadata and does not execute production inference workloads; the Playground supports cost and latency scenarios and, when configured, may directly call AI providers. Per-inference energy, carbon, and water values remain unavailable because CarbonLayer does not have a validated request-to-kWh attribution method.

At the end of the article, CarbonLayer offers a thought-provoking point: perhaps the first truly useful contribution of an impact receipt is not a carbon number, but a shared way of distinguishing evidence from assumptions.

An interface should be able to say: we can describe the routing scenario, we can identify which operational information is available, but we cannot substantiate the environmental impact of this single inference. That is far more useful than attaching a carbon number that looks convincing but cannot be defended.

The team announced that the next part will attempt to put impact metadata into an open API specification—not an adopted industry standard, but an open, inspectable, machine-readable starting point for a contract.

One-line Summary

The key to standardizing AI impact receipts is not unifying carbon calculations, but unifying how evidence, boundaries, and uncertainty are described.

Paragraph Summary

The CarbonLayer team explores "AI impact receipts," pointing out that current descriptions of AI environmental impact are chaotic: different providers use different fields for the same concept, accounting boundaries vary, and when evidence is lacking they tend to return seemingly precise numbers. The article argues that standardization should aim to unify "how we describe what we know and do not know," rather than forcing all providers to use the same calculation method. A consistent JSON structure does not equal comparable results, and differences in accounting boundaries can make data appear standardized while actually being incomparable. "Unavailable" should be a first-class field, strictly distinguished from zero. Methodology versioning, location privacy, and evidence-type differentiation are all necessary components of a credible specification. The article also examines existing standards such as OpenTelemetry, SCI, and CodeCarbon, warning that premature standardization may make weak data appear authoritative, and proposes that the first real contribution of impact receipts may be a shared language for distinguishing evidence from assumptions.