Latency and tokens already travel with an AI request.
Carbon usually does not.
It remains trapped inside a provider dashboard, separated from the model, region, workload, and time window that produced it. That makes the number difficult to compare, difficult to audit, and nearly useless for routing decisions.
Carbon should be treated as an infrastructure metric. It should travel with the same request context as latency and tokens.
What an Impact Receipt contains
An Impact Receipt is a portable record attached to an AI request. It describes the workload, where and when it ran, the estimated or measured impact, and the evidence behind that result.
At minimum, it should include:
Area Fields
Request Provider, model, input tokens, output tokens, timestamp
Execution Region, route, duration, latency, time window
Impact Energy, carbon, water, units
Evidence Data source, version, system boundary, resolution
Basis Measured, modeled, or unavailable
Status Verified, unverified, or unavailable
Tradeoffs Cost, latency, availability, alternative route
The important part is not simply adding more fields. It is keeping the evidence attached to the number.
A carbon value without an execution region is incomplete. A water value without duration and system boundaries is incomplete. A modeled estimate presented as a measurement is misleading.
Modeled does not mean useless
Most AI infrastructure will not have a direct meter for every individual inference.
That does not make modeling worthless. It means the result needs to say what it is.
A modeled attribution can support comparison and planning. It should not quietly become a measured facility flow. Likewise, a grid-level estimate should not be presented as a precise facility-level observation.
The receipt should make the distinction explicit:
{
"impact": {
"energy": {
"value": null,
"unit": "Wh",
"basis": "modeled",
"status": "unverified"
},
"carbon": {
"value": null,
"unit": "gCO2e",
"basis": "modeled",
"status": "unverified"
},
"water": {
"value": null,
"unit": "L",
"basis": "modeled",
"status": "unverified"
}
},
"evidence": {
"source": null,
"source_version": null,
"system_boundary": null,
"spatial_resolution": null
}
}
This is only the shape of the record, not a claim that these values are currently available for every request.
If the evidence is missing, the correct answer is unverified or unavailable. It is not zero.
“Unverified” should be a first-class result
A successful API response does not prove that its environmental attribution is correct.
A test that uses the same credentials or code path as the action it is checking may only prove that the action returned successfully. It does not necessarily prove the external result.
Environmental reporting has the same problem. A number can be present without being sufficiently supported.
“Unverified” preserves that distinction. It tells the operator:
The request completed.
An attribution may have been calculated.
The available evidence does not justify calling it verified.
That is more useful than false certainty.
From reporting to sustainable operations
A portable receipt makes several operational decisions possible:
Compare providers using carbon alongside latency and cost.
Route flexible workloads toward lower-impact regions or time windows.
Identify when a smaller model is sufficient.
Measure the effect of caching, batching, or token limits.
Audit whether a sustainability claim still holds after infrastructure changes.
Keep carbon, energy, and water data attached to the workload instead of a dashboard screenshot.
The receipt should also preserve tradeoffs. A lower-carbon route may have higher latency, different availability, or a different price. Hiding those costs makes the metric less trustworthy.
Sustainability is not achieved by producing a green number. The useful loop is:
Measure → compare → reduce → report the evidence and tradeoffs.
CarbonLayer is exploring whether the Impact Receipt should serve primarily as a live routing signal, a post-run audit record, or both.
If you operate AI infrastructure, which field would you require before trusting an environmental metric in production?
Top comments (0)