Can an AI Impact Receipt Be Standardized?

Here's the problem with building a useful developer tool:

If only one company can use it, it's a product feature.

If different systems can produce and consume the same information, it has the potential to become infrastructure.

That's the question I've been thinking about while developing the Impact Receipt concept at CarbonLayer.

In Part 3, What Should an AI Impact Receipt Actually Contain?, we explored what an AI Impact Receipt should contain: workload information, model identity, latency, environmental metrics, methodology, provenance, and uncertainty.

But identifying useful fields is only the beginning.

What happens when two AI providers describe the same concept differently?

What happens when two systems return carbon values calculated using completely different boundaries?

And what happens when a provider doesn't have enough evidence to calculate a value at all?

Can we standardize an AI Impact Receipt without standardizing misleading assumptions?

I think that's the problem worth solving.

1. Standardize the interface—not necessarily the calculation

Let's start with a distinction.

I don't think the first goal should be:

Every AI provider must calculate environmental impact in exactly the same way.

Different providers operate with different hardware, workloads, measurement systems, data sources, and accounting boundaries.

A universal calculation methodology would require agreement on questions that are still being researched.

But perhaps we can start somewhere more practical:

Can we agree on how to describe what we know, what we don't know, and how we know it?

Imagine a future system that has a defensible carbon estimate. It might represent the result as:

{
"carbon": {
"status": "available",
"value": 14.7,
"unit": "gCO2e",
"evidenceType": "modeled",
"methodology": {
"name": "example-method",
"version": "1.0"
}
}
}

This is an illustrative design, not an actual CarbonLayer API response or a verified emissions result.

The important feature isn't the number.

It's that the receiving application can distinguish the value, unit, evidence type, and methodology.

A shared interface could make this information easier to exchange without pretending every provider's calculations are equivalent.

1. Consistent JSON doesn't guarantee comparable results

Suppose three hypothetical providers return environmental data:

Provider A

{
"carbon": 14.7
}

Provider B

{
"emissions": 0.0147
}

Provider C

{
"impact": {
"co2e_g": 14.7
}
}

Even before we discuss measurement, we have an integration problem.

Are these grams or kilograms? Are they CO2 or CO2-equivalent? What activities are included?

An application must interpret each response separately.

A common interface could eliminate some of that ambiguity.

But now imagine every provider returns the same JSON structure while using different accounting boundaries.

One includes only accelerator electricity.

Another includes server and cooling overhead.

A third includes additional lifecycle impacts.

The data looks standardized, but the results still may not be comparable.

Standardizing syntax is not the same as standardizing meaning.

That's why provenance, accounting boundaries, and methodology have to be part of the conversation.

1. The most important field might be "unavailable"

One of the biggest mistakes an environmental API can make is returning a precise-looking number without adequate supporting evidence.

Suppose a system knows which model was requested but cannot establish how much electricity was attributable to that individual inference.

Should it return a default energy value?

Should it infer carbon emissions from token count alone?

Should it fill missing water data with zero?

I would argue no.

A proposed receipt could instead return:

{
"impact": {
"energy": {
"status": "unavailable",
"value": null,
"unit": "kWh"
},
"carbon": {
"status": "unavailable",
"value": null,
"unit": "gCO2e"
},
"water": {
"status": "unavailable",
"value": null,
"unit": "mL"
}
}
}

This example is a proposed representation, not a response contract currently implemented by CarbonLayer.

Why is this important?

Because zero is a value; unavailable is an evidence state.

Those two things must never be interchangeable.

A standard that permits explicit missing values would be more trustworthy than one that pressures every provider to populate every field.

It also creates a path forward: a system can adopt the interface before it has the evidence necessary to populate every environmental metric.

1. Measured, modeled, derived, and unavailable are different things

A useful future specification should distinguish several kinds of evidence.

Measured: A value supported by a documented measurement process, with a clearly defined boundary.

Modeled: A value estimated using assumptions, coefficients, or a computational model.

Derived: A value calculated from other inputs, whose original evidence types must remain traceable.

Unavailable: A value that cannot currently be supplied with adequate support.

These categories should not be treated as interchangeable.

Consider a conceptual calculation:

Energy attributed to workload
|
v
Grid carbon intensity
|
v
Calculated emissions

Even when the arithmetic is correct, the result depends on the quality, coverage, and compatibility of the inputs.

A calculated emissions value doesn't become a direct measurement merely because one of its inputs was measured.

Nor does adding decimal places make an estimate more accurate.

A receipt needs to preserve the evidence behind the result.

And when that evidence is insufficient, it should say so.

1. Methodology and versioning matter

Imagine an organization reports environmental impact in January and again in June.

The second value is lower.

Did the workload become more efficient?

Did the infrastructure change?

Did the accounting boundary change?

Or did the methodology change?

Without methodology versioning, a trend can be difficult to interpret.

A future receipt might include:

{
"methodology": {
"id": "example-impact-method",
"version": "1.0",
"boundary": "documented-separately",
"reference": "https://example.org/methodology"
}
}

Again, this is an illustrative schema, not a claim that CarbonLayer has implemented or validated this methodology.

The goal is to make changes visible rather than silently mixing incompatible results.

A specification should also define what happens when a methodology is deprecated, when a data source changes, or when historical values are recalculated.

A number without a methodology is difficult to verify. A number without a methodology version is difficult to compare over time.

1. Location matters—but privacy does too

The environmental characteristics of computing infrastructure can depend on location, time, electricity supply, and system boundaries.

That suggests location context could be useful in an Impact Receipt.

But there is a complication.

The location needed for environmental accounting isn't necessarily the location a provider should disclose to every API consumer.

A future specification might need to support different levels of detail:

Geographic region

Electricity-grid region

Country-level information

Restricted or undisclosed location

It would also need to identify whether a location represents an actual execution site, a billing region, a modeled assumption, or something else.

Otherwise, developers could mistakenly interpret a routing label as proof of where computation physically occurred.

This is a good example of why standardization is a semantic problem, not merely a JSON-design problem.

1. A minimal receipt should separate known facts from impact claims

Rather than requiring every environmental field, I'd start by separating three layers:

      AI REQUEST / DECISION
               |
               v
   +-----------------------+
   | Operational context   |
   |-----------------------|
   | Identifier            |
   | Timestamp             |
   | Model / route context |
   | Workload metadata     |
   +-----------------------+
               |
               v
   +-----------------------+
   | Environmental status  |
   |-----------------------|
   | Energy: unavailable   |
   | Carbon: unavailable   |
   | Water: unavailable    |
   +-----------------------+
               |
               v
   +-----------------------+
   | Evidence & semantics  |
   |-----------------------|
   | Data provenance       |
   | Methodology / version |
   | Accounting boundary   |
   | Completeness          |
   +-----------------------+

This is a proposed architecture, not a diagram of CarbonLayer's currently shipping per-inference receipt system.

Notice something important.

The operational information can still be useful even when environmental impact values are unavailable.

Developers may be able to inspect routing decisions, latency information, request identifiers, and data completeness without pretending those fields establish a carbon footprint.

That separation could make the interface more useful and more honest.

1. What existing standards can teach us

We don't need to invent every concept from scratch.

Several existing efforts provide useful foundations.

OpenTelemetry

OpenTelemetry's Generative AI Semantic Conventions provide a useful reference for describing AI operations, model-related attributes, and telemetry.

An Impact Receipt proposal should investigate how to reuse compatible observability concepts rather than introducing unnecessary competing terminology.

However, compatibility with observability conventions would not, by itself, validate an environmental calculation.

Software Carbon Intensity

The Green Software Foundation's Software Carbon Intensity specification provides an approach to expressing software carbon intensity, including defined boundaries and functional units.

It offers important lessons about methodology and normalization.

But referencing SCI does not mean a particular inference receipt is an SCI score or that a product conforms to the specification.

CodeCarbon

CodeCarbon demonstrates approaches to estimating emissions associated with computing workloads.

It is a useful example of why data sources, assumptions, and workload boundaries matter.

But a workload-level estimation approach does not automatically establish defensible attribution to every individual API request.

These efforts provide building blocks.

They do not automatically establish a universal, interoperable, verified per-inference Impact Receipt standard.

That remains an open design problem.

1. What could developers eventually build?

If a useful, interoperable receipt format emerged—and providers supplied adequate evidence—it could support several workflows.

Observability: Examine model and routing context alongside the availability and provenance of environmental data.

Model selection: Compare operational tradeoffs and, where defensible measurements or estimates exist, investigate environmental differences.

CI/CD evaluation: Track methodology changes, data completeness, and reproducibility before using environmental metrics as automated decision inputs.

Reporting: Aggregate compatible observations without silently treating missing values as zero or mixing incompatible boundaries.

Routing: Inform application-level decisions using supported metrics and explicitly declared constraints.

These are possible applications of a future interface.

They are not claims that CarbonLayer currently delivers verified environmental optimization, demonstrated savings, or production-ready versions of every workflow.

And any implementation would need to establish which metrics are actually observed, which are modeled, and which remain unavailable.

1. Where CarbonLayer fits today

CarbonLayer is exploring how AI routing decisions, operational observability, and environmental accountability might eventually work together.

Today, CarbonLayer has two distinct demonstration surfaces.

The /api/inference endpoint returns simulated, illustrative routing metadata. It does not execute production inference workloads or provide verified environmental impact measurements.

Separately, the Playground supports cost and latency scenarios. When configured, it may make a direct call to an AI provider. That does not mean CarbonLayer is routing production workloads or measuring their environmental impact.

Per-inference energy, carbon, and water values remain unavailable because CarbonLayer does not have a validated request-to-kWh attribution method.

Production per-inference Impact Receipts remain a future capability.

That distinction matters.

A future Impact Receipt should preserve the difference between simulated decisions, observed operational data, modeled environmental values, and unavailable evidence.

An interface should be able to say:

We can describe the routing scenario.

We can identify which operational information is available.

We cannot substantiate the environmental impact of this individual inference.

That's more useful than attaching a convincing-looking carbon number that cannot be defended.

And it raises an interesting possibility:

Perhaps the first genuinely useful contribution of an Impact Receipt isn't a carbon number.

Perhaps it's a shared way of distinguishing evidence from assumption.

1. The danger of standardizing too early

A standard can make data easier to exchange.

It can also make weak data appear more authoritative.

If every AI provider returns a field called carbon.value, developers may assume the values are comparable.

But what if one provider uses physical measurement, another uses a fleetwide average, and a third uses a token-based proxy?

A common field name doesn't solve those differences.

So a credible specification would need to answer difficult questions:

What qualifies as a measured value?

What boundaries must be disclosed?

How are modeled and derived values labeled?

When should a field be unavailable?

What information is necessary for reproducibility?

How should uncertainty be represented without inventing confidence scores?

How are incompatible results prevented from being aggregated?

What operational or geographic information can be disclosed safely?

How should the interface evolve without breaking existing consumers?

Those questions deserve answers before anyone declares victory.

1. The next step isn't to declare a standard

It's to propose something developers can challenge.

A small, inspectable, machine-readable contract.

One that explicitly supports unavailable environmental data.

One that makes evidence types and methodologies visible.

One that doesn't confuse a simulated decision with a verified physical outcome.

One that can be implemented independently of CarbonLayer.

And one that doesn't claim authority simply because a company published it.

If developers disagree with the structure, that's useful.

If they find an ambiguity, that's useful.

If they identify a field that encourages misleading comparisons, that's especially useful.

Because the goal shouldn't be to make every AI system return the same impressive-looking numbers.

The goal should be to make every returned claim understandable, traceable, and appropriately qualified.

Coming next: Part 5

Let's Put Impact Metadata Into an Open API Specification

We've explored what an Impact Receipt could contain.

We've examined the problems with provenance, methodology, missing values, and interoperability.

Now it's time to turn those questions into a concrete proposal.

In Part 5, we'll outline a draft machine-readable interface that developers can inspect, challenge, and potentially implement.

Not an adopted industry standard.

Not a claim that CarbonLayer has solved per-inference environmental measurement.

A starting point for an open technical discussion.

Because before AI infrastructure can make environmental impact comparable, we need to agree on something more fundamental:

What evidence must accompany the claim?

Help shape what CarbonLayer builds next

We're also asking developers who work with AI APIs, LLM applications, inference infrastructure, and developer tooling to share their experiences.

Where do AI integrations become unnecessarily complicated?

How do you evaluate cost, latency, and reliability?

What information do you wish your AI providers exposed?

And would more transparent routing and impact metadata actually help your workflow?

We've put together a short, 7-question developer survey to learn what matters most before deciding what to build next.

Take the CarbonLayer Developer Survey

Your feedback will help us understand real developer needs, challenge our assumptions, and prioritize useful capabilities.

You don't need to use CarbonLayer to participate. We're interested in hearing from developers with different tools, providers, and perspectives.

And if you think an AI Impact Receipt is the wrong approach—or that we're missing a fundamental problem—we'd especially like to hear why.

Better infrastructure starts with better questions.

CarbonLayer explores AI routing, decision transparency, and the challenges of making environmental impact data trustworthy.

Explore CarbonLayer | Follow the Impact Receipt series on DEV.to | Developer Survey

Part 4 of 5 — The Impact Receipt Series