DEV Community: CarbonLayer

I Built the First Version of an AI Impact Receipt

CarbonLayer — Tue, 29 Sep 2026 00:49:30 +0000

An AI API usually gives you an answer. I wanted to explore what it would look like if it also returned a record of the request’s environmental impact—and how those figures were produced.

That’s the idea behind the Impact Receipt: impact information should travel with the AI request, not live in a separate dashboard with no link to the work that generated it.

In Part 1, I argued that carbon should travel with every AI request. Here’s what I’ve built so far—and what this first version does not do.

The prototype flow
A caller supplies a model or routing identifier, a prompt, a token budget, and a latency preference. The prototype returns dispatch information alongside environmental estimates.

There’s an important boundary: it does not call Claude or another language-model provider. The model identifier is simulated, and the response echoes the supplied prompt. This prototype tests the shape of the dispatch and receipt—not a real model call, provider-reported usage, or physical measurement.

Here’s a shortened example of the response shape:

{
"id": "",
"model": "claude-sonnet",
"tokens": 800,
"device": {
"region": "eu-north-1",
"country": "Norway",
"carbonIntensity": 68,
"renewableMix": 0.97,
"waterIntensity": 0.32,
"carbonIntensitySource": "modeled",
"waterIntensitySource": "modeled"
},
"energyKwh": 0.216045,
"carbonGrams": 14.691,
"waterMl": 69.134,
"carbonSource": "modeled",
"energySource": "modeled",
"waterSource": "modeled",
"source": "synthetic"
}
These are example prototype values—not meter readings for an individual inference.

The label matters as much as the number
A field like "carbonGrams": 14.691 looks precise. Without context, a developer could read it as a physical measurement of what that request emitted.

It isn’t.

In this prototype, the energy, carbon, and water figures are modeled allocations based on modeled or seeded infrastructure data. They are not measured at the level of an individual request. The tokens field is dispatch data, not provider-reported usage, because no model provider is executing the request.

That’s why the response labels the metrics as "modeled". The root-level "source": "synthetic" describes the data path; it does not turn the estimates into measurements.

A number needs provenance before someone can decide how much to trust it.

What the fields are for
The dispatch ID gives the record an identifier. The model field records the routing label used by the prototype; it does not prove which provider ran the request. The device and region fields add location context, which matters because energy, carbon intensity, water, and latency can vary by location.

Energy, carbon, and water are separate metrics, each with its own source label. A modeled estimate can still be useful—but only if it’s clear that it’s modeled, and clear about the assumptions behind it.

The ID is an identifier in this response. I’m not claiming that the prototype already provides a way to retrieve a saved receipt later.

What this first version proves—and what it doesn’t
This is an early prototype of the receipt contract, not a complete production feature. It shows one way a dispatch response can carry environmental estimates and provenance together.

It does not yet demonstrate a real provider call, per-inference physical metering, or a verified record of what a live model processed. It also doesn’t include a cost figure, confidence labels, or a methodology version.

Those omissions matter. A fuller receipt will need to say not only what the figures are, but also what boundaries and data sources produced them, how fresh the inputs are, and where uncertainty remains.

The first lesson from building this prototype is simple: an Impact Receipt isn’t just a set of numbers. It’s numbers plus context and provenance. Without those, precision can look like certainty. With them, even a modeled estimate can be interpreted honestly.

Next: what should a complete Impact Receipt contain?

What If Every AI Inference Came With a Transparent Impact Receipt?

CarbonLayer — Sun, 27 Sep 2026 23:51:51 +0000

An AI API gives you the model’s answer. Often, it also gives you token counts. But when you’re running inference in production, you may also need to know: What did that request cost? How long did it take? And what energy, carbon, and water estimates can be associated with it?

That’s the developer experience I want CarbonLayer to help make possible: useful information attached to each inference, with enough context to understand what the numbers do—and don’t—mean.

A response might look something like this:

{
"response": "…",
"usage": {
"input_tokens": 184,
"output_tokens": 658,
"total_tokens": 842
},
"latency_ms": 731,
"impact": {
"cost_usd": {
"value": 0.0041,
"status": "estimated",
"basis": "token usage and applicable pricing"
},
"carbon_g": {
"value": 0.73,
"status": "modeled",
"basis": "estimated energy use and grid carbon intensity"
},
"water_ml": {
"value": 12.4,
"status": "modeled",
"basis": "estimated facility and electricity-related water use"
}
},
"methodology": {
"version": "example",
"data_freshness": "example",
"confidence": {
"cost": "example",
"carbon": "example",
"water": "example"
}
}
}
This is an illustrative payload—not a live CarbonLayer response, and the values are examples. The shape matters because a number without its status and basis is easy to misread.

A token count may come directly from the model provider’s response. Latency can be observed at the point where the request passes through a routing layer—but that’s not necessarily the same as the model’s own processing time. Cost might be calculated from usage and a pricing schedule; it may not include every infrastructure or business cost.

Carbon and water require even more context. In many systems, those figures are modeled estimates, not measurements taken for that individual request. A model may estimate energy use, then combine it with data such as grid carbon intensity. A water estimate may depend on assumptions about cooling and electricity generation. The result is only meaningful if developers can see the system boundary, data sources, assumptions, and uncertainty behind it.

There’s another complication: inference doesn’t always happen as one isolated request on one isolated machine. Workloads can be batched, hardware is shared, and providers may expose only some of the information needed to attribute resource use. A per-request figure can still be useful—but it may represent an allocation, not a direct reading from a meter attached to that call.

That’s why I’d want each field to carry its own label. “Measured,” “modeled,” “estimated,” and “unavailable” shouldn’t be interchangeable—and one label shouldn’t automatically apply to every metric in the response. If the region is unknown, the data is stale, or a calculation depends on a broad assumption, the receipt should say so.

The goal isn’t to make uncertain numbers look precise. It’s to give developers enough information to decide how to use them: compare workloads, spot trends, evaluate routing choices, or decide that a metric isn’t reliable enough for a particular decision.

For an impact receipt to be useful in production, I think it needs to answer a few basic questions:

What does each number represent?
Which parts were observed, and which were modeled?
What boundary and assumptions were used?
How fresh is the underlying data?
How uncertain is the estimate?
Which methodology version produced it?
That’s the direction I’m exploring with CarbonLayer: making inference economics and environmental estimates more transparent, one request at a time.

If you’re building AI systems, what would an inference response need to show before you’d trust its cost, carbon, or water figures?

A Per-Inference Number Is Not a Healthcare Emissions Inventory

CarbonLayer — Wed, 23 Sep 2026 03:17:44 +0000

Production AI teams already track latency, token usage, error rates, and cost.

The next question is increasingly environmental:

How much energy did this inference use?
What carbon impact can be attributed to it?
Can water use be estimated?
Which values are measured, and which are modeled?
Can the result support an internal or external disclosure?
These are reasonable questions. They are also easy to answer badly.

A per-inference estimate can be useful without being a complete emissions inventory. The important part is preserving the boundary between operational visibility and organizational disclosure.

At CarbonLayer, we use a simple rule:

Show what was measured. Label what was derived. Qualify what was modeled.

What a per-inference metric actually describes
A per-inference metric describes a specific workload within a defined boundary.

That boundary might include:

The model or model class
Input and output size
Runtime or execution environment
Region or facility assumption
Time period
Energy-allocation method
Carbon-intensity source
Water-intensity source
Baseline used for comparison
This can provide valuable operational context. For example, an engineering team might compare two routing strategies by looking at latency, cost, energy, and modeled carbon attribution.

But that same value does not automatically describe the healthcare organization’s complete environmental impact.

Workload-level data It can help explain It cannot prove
Per-inference energy Relative workload efficiency A facility’s total electricity use
Carbon allocation Impact of a defined workload A complete Scope 1, 2, or 3 inventory
Water attribution A modeled comparison between workloads Facility water withdrawal or consumption
Savings estimate A modeled baseline comparison Measured environmental savings
The number can be valid within its boundary while still being insufficient for a broader disclosure.

Scope boundaries still matter
A per-request estimate should not be presented as a replacement for organizational accounting.

Scope 1 covers direct emissions from sources an organization owns or controls, such as fuel combustion or refrigerant releases.

Scope 2 covers purchased electricity. A workload-level carbon estimate may allocate emissions using an electricity-intensity coefficient, but that is not the same as a utility-meter reading or a full facility-level Scope 2 disclosure.

Scope 3 covers value-chain emissions, including vendor services, equipment, transportation, and upstream energy impacts. A model-routing comparison is not automatically a Scope 3 inventory.

The key distinction is simple:

A workload estimate can support a disclosure process without becoming the disclosure itself.

Carry the status with the number
Environmental data should not be separated from its provenance.

A dashboard that displays 0.04 kWh or 12.3 g CO₂e without explaining the source creates false confidence. The value may be calculated correctly, but the reader still needs to know what it represents.

We recommend using three explicit states.

Measured
The value comes from a directly sourced input with documented evidence, geography, period, and boundary.

Examples might include:

A facility meter reading
A provider-issued energy report
A documented regional intensity factor for a defined period
Derived
The value comes from a calculation, conversion, or aggregation.

Examples include:

Converting watt-hours to kilowatt-hours
Summing request-level records for a reporting period
Converting milliliters to liters
Aggregating regional values into a defined workload total
A derived value may inherit uncertainty from the inputs underneath it.

Modeled
The value is an allocation, estimate, proxy, forecast, baseline, or counterfactual comparison.

Examples include:

Allocating shared compute energy to an individual inference
Estimating water attribution from energy use
Comparing a carbon-aware route with a conventional baseline
Forecasting impact from expected request volume
A precise-looking modeled value is still modeled.

Why a measured coefficient can produce a modeled result
Consider a simplified carbon calculation:

allocated carbon = allocated energy × regional carbon intensity
The regional carbon-intensity value might come from a documented source. That source can be measured.

The allocated energy assigned to one inference may still depend on assumptions about shared infrastructure, workload utilization, model behavior, and scheduling.

Therefore, the resulting per-inference carbon value should usually be labeled modeled, even if one of its inputs is measured.

The calculation may be sound. The label still matters.

This distinction is especially important when values are copied into reports or presented to non-technical stakeholders. “Measured coefficient” and “measured workload impact” are not interchangeable claims.

Water attribution needs extra caution
Water is particularly easy to overstate.

A value such as waterMl may represent a modeled allocation based on energy use and a water-intensity coefficient. It is not automatically:

A facility meter reading
Total facility water consumption
Water withdrawal
Water discharge
A complete water inventory
A clinical or patient-related impact
The same applies to a comparison field such as savedWaterMl.

If the value represents the difference between a selected routing strategy and a baseline, it is a modeled comparison. It should not be presented as measured water savings unless the underlying measurement supports that claim.

For example:

savedWaterMl = baseline modeled water attribution
- selected route modeled water attribution
That can be useful for evaluating routing decisions. It does not mean a facility consumed that exact amount less water.

An illustrative inference record
The following is an illustrative data model, not a required API format:

{
"workload": {
"model": "example-model",
"region": "example-region",
"period": "2026-09-01/2026-09-30"
},
"performance": {
"latencyMs": 184,
"inputTokens": 920,
"outputTokens": 240
},
"impact": {
"energyWh": {
"value": 0.04,
"status": "modeled",
"method": "workload allocation"
},
"carbonGrams": {
"value": 0.012,
"status": "modeled",
"method": "energy allocation × regional intensity"
},
"waterMl": {
"value": 0.3,
"status": "modeled",
"method": "energy allocation × water-intensity coefficient"
}
},
"provenance": {
"sourceVersion": "example-source-version",
"geography": "example-region",
"assumptionsDocumented": true
}
}
The important design choice is not the field names. It is that the value and its qualification travel together.

Do not make engineers or reporting teams reconstruct the meaning of a number from a separate dashboard legend six months later.

Healthcare adds a privacy boundary
Environmental data is not automatically patient data.

However, healthcare operations can still be sensitive. Facility identity, location, timing, utilization, and workload patterns may reveal more than intended when combined.

Environmental telemetry should therefore avoid including:

Patient identifiers
Encounter IDs
Diagnoses
Treatments
Clinical notes
Claims about patient outcomes
A workload-level environmental record should describe the infrastructure and reporting boundary, not the patient.

Aggregation may also be appropriate. A monthly or regional report can reduce exposure from publishing individual workload timing or facility-level utilization patterns.

Privacy review and environmental disclosure review are separate processes. Both are necessary.

Aggregation does not remove uncertainty
Rolling up request-level values into a monthly total makes the number larger. It does not automatically make it more certain.

If the underlying records are modeled, the total remains based on modeled inputs.

If the underlying records use proxy data, the aggregate inherits that limitation.

If different regions or source versions were used, the aggregation should preserve those distinctions or explain how they were normalized.

A reporting-period total might be derived from modeled records. Those are two different descriptions, and both may be needed:

Derived describes how the total was calculated.
Modeled describes the nature of the underlying attribution.
Do not replace both with the simpler word “actual.”

A practical review checklist
Before including an inference-level value in an external report, confirm:

Boundary — Which workload, facility, provider, and reporting category does it cover?
Period — Is it historical, current, forecast, or counterfactual?
Source — Who supplied the coefficient, and which version was used?
Geography — Which region, grid, facility, or provider boundary applies?
Fallbacks — Was proxy, synthetic, degraded, or forecast data used?
Aggregation — How were individual records converted into the reported total?
Uncertainty — Which assumptions could materially change the result?
Review — Have engineering, sustainability, facilities, privacy, and reporting owners reviewed it?
This is not paperwork for its own sake. It is what makes an operational metric defensible.

A disclosure sentence engineers can stand behind
A useful disclosure should explain both the result and its limits.

For example:

During the reporting period, the healthcare AI workload processed [request count] requests. The reported carbon and water values are modeled workload allocations based on [method and source], not facility meter readings or a complete organizational emissions inventory.

That sentence is less dramatic than claiming a precise environmental saving.

It is also more useful.

The standard
AI infrastructure needs better environmental visibility. Production teams should be able to compare cost, latency, utilization, carbon, and modeled water without hiding the assumptions behind those values.

But better visibility does not mean presenting every estimate as a fact.

The standard should be:

Show what was measured.
Label what was derived.
Qualify what was modeled.
Preserve source, period, geography, and boundary.
Never imply what the system cannot establish.
For the full healthcare-specific framework, see the CarbonLayer healthcare emissions and water disclosure guide.

Production Inference Needs More Than Token Counts

CarbonLayer — Fri, 18 Sep 2026 17:37:20 +0000

Token counts are easy to measure.

They are not enough to run inference in production.

Once an AI workload moves beyond experimentation, the important questions become more operational:

Why did the cost per request change?
Which route or site served the request?
Did latency improve or degrade?
What did the request consume in energy, carbon, and water?
Can the result be compared with a baseline?
Are those impact values measured, estimated, modeled, or unavailable?
A token dashboard cannot answer all of those questions.

The unit of production AI is the inference call
Monthly averages are useful for reporting. They are less useful for making infrastructure decisions.

The inference call is the better unit of analysis because it connects the request to the conditions that produced it:

Model and workload
Token usage
Latency
Route or serving location
Energy consumption
Carbon impact
Water impact
Cost and savings relative to a baseline
That context makes the numbers actionable.

If latency rises after a routing change, you can investigate the route. If cost increases while token usage stays flat, you can look at capacity or model selection. If impact changes by location or time, the router can account for that in future decisions.

Without per-call attribution, the dashboard only tells you that something changed.

It does not tell you what to change next.

Aggregated metrics hide infrastructure tradeoffs
A single average can make a production system look stable while important behavior changes underneath.

For example:

A lower average carbon value may come with higher tail latency.
A cheaper route may use more energy.
A regional shift may improve efficiency while violating data-residency requirements.
A model change may reduce token usage but increase compute intensity.
A reported water value may be modeled rather than directly measured.
None of these tradeoffs are inherently unacceptable. The problem is hiding them.

Production teams need enough context to decide which tradeoffs are acceptable for a particular workload.

Carbon-aware routing should be operational, not decorative
Carbon-aware infrastructure is most useful when it influences where and when inference runs.

That does not mean sending every request to the location with the lowest reported carbon intensity. A useful routing decision also considers:

Latency requirements
Available capacity
Workload characteristics
Data residency
Cost
Reliability
Carbon and water impact
The objective is not to optimize one metric while breaking the product.

The objective is to make those constraints visible in the same operational loop.

That is where CarbonLayer fits.

CarbonLayer provides carbon-aware inference routing, per-call attribution, and usage and savings reporting through an API designed for production workloads. The goal is to help engineering teams see the economics and resource impact of inference at the same level as the request itself.

Provenance matters as much as the number
Not every environmental metric has the same level of certainty.

A responsible inference system should make the provenance of each value clear:

Measured: directly observed from available infrastructure data
Estimated: calculated from an approximation
Modeled: derived from a defined model or methodology
Unavailable: not enough information to provide a defensible value
This distinction is especially important for water attribution.

A modeled water value can still be useful for comparison and planning. It should not be presented as though it came from a water meter attached to a single inference.

Precision without provenance creates false confidence.

The production control loop
A practical inference measurement system should support four steps:

Attribute the request and its operational impact.
Compare the result with a baseline.
Route future workloads using the available constraints.
Report the outcome through APIs and dashboards.
That turns sustainability data from a quarterly reporting exercise into an infrastructure input.

It also gives teams a better answer to a basic question:

What did this inference cost, and what should we do differently next time?

Start with a real API call
CarbonLayer is built for developers who want to test this workflow against an actual inference path.

Create a free API key, then follow the API documentation and quickstart.

The point is not to produce another dashboard full of disconnected numbers.

The point is to make every inference measurable enough to improve the next one.

Your Inference Metrics Can Be Correct—and Still Be Wrong

CarbonLayer — Sun, 30 Aug 2026 02:20:36 +0000

Configuration drift turns stale energy, carbon, cost, and latency measurements into misleading operational facts.

A metric can be arithmetically correct and still be invalid for the decision you are making.

This is an uncomfortable problem in production AI infrastructure.

Suppose you measured the energy used by an inference workload last week. The measurement was accurate. The calculation was correct. The dashboard displays it without errors.

Then the model changes.

Or the quantization changes. Or the GPU type. Or the batch size. Or the serving region. Or the scheduler starts routing traffic differently.

The old number may still be correct for the original configuration. It is no longer necessarily correct for the workload running today.

That distinction matters for more than carbon reporting. It affects cost estimates, capacity planning, latency comparisons, hardware selection, and model-routing decisions.

A measurement is a statement with premises
Most metrics are treated as simple pairs:

metric = value
For example:

energy_per_inference = 0.40 Wh
Operationally, that is incomplete.

A more accurate representation is:

metric = value + conditions + method + timestamp + provenance
The actual statement might be:

This workload used 0.40 Wh per inference when model version 3.2 ran with INT8 quantization, batch size 8, on a specific GPU type, in a specific region, during a defined measurement window.

Remove those conditions and the value looks more universal than it is.

That is how stale measurements become dangerous. Not because the original observation was bad, but because its boundaries disappear when the number is exported, reused, or republished.

An illustrative example
Imagine a team measures a production workload under these conditions:

Model: support-model v3.2
Precision: INT8
Hardware: GPU type A
Region: Region 1
Batch size: 8
p95 latency: 180 ms
Energy: 0.40 Wh per inference
The team uses that result to estimate monthly energy and carbon.

Two weeks later, the workload changes:

Model: support-model v4.0
Precision: INT4
Hardware: GPU type B
Region: Region 2
Batch size: 32
The dashboard still uses the original 0.40 Wh figure.

Nothing is wrong with the multiplication. The monthly total is calculated correctly from the stored value.

The problem is that the stored value describes a different workload.

The same issue appears when comparing two routing strategies. If one strategy is measured before a hardware change and the other afterward, the comparison may appear precise while mixing incompatible conditions.

Precision does not rescue invalid premises.

Why this gets worse after data leaves the system
Inside an observability system, metadata may still exist somewhere.

But the metric often gets copied into:

A spreadsheet
A quarterly report
A customer-facing sustainability claim
A model-selection document
A capacity-planning deck
An investor update
A benchmark article
At that point, the number has outlived its original context.

The value is no longer just being observed. It is being used to support a decision.

That is where provenance becomes an operational requirement rather than a documentation nice-to-have.

What should travel with the number?
At minimum, an inference-impact measurement should carry enough context to answer five questions:

What was measured?
Under which configuration?
How was it measured or estimated?
When was it valid?
Can it be compared with the current workload?
Useful fields include:

Context Why it matters Example
Model and version Model changes affect compute behavior support-model v4.0
Serving configuration Runtime settings change throughput and energy Batch size, precision
Hardware and region Devices and grid conditions differ GPU type, region
Request shape Token count and output length affect work Input/output tokens
Method and version Results depend on methodology Instrumentation or estimation method
Observation time Conditions change over time Measurement window
Configuration fingerprint Enables comparison with the current workload config_8f21...
A compact representation might look like this:

{
"metric": "energy_per_inference",
"value": 0.40,
"unit": "Wh",
"provenance": {
"kind": "measured",
"method": "power-sampling",
"methodology_version": "1.0"
},
"valid_for": {
"model": "support-model",
"model_version": "3.2",
"precision": "int8",
"batch_size": 8,
"hardware": "gpu-type-a",
"region": "region-1",
"config_fingerprint": "config_8f21"
},
"observed_at": "2026-08-01T12:00:00Z"
}
This is not bureaucracy for its own sake.

It lets a system distinguish between:

A current measurement
A historical measurement
A stale measurement
A measurement that cannot be compared
A number with missing provenance
Those should not all look identical in a dashboard or API response.

Invalidation should follow premise changes
A common approach is to expire every measurement after a fixed number of days.

Time-based expiry is useful, but it is not enough.

A measurement should be reconsidered when the conditions that support it change:

Model version changes
Hardware changes
Quantization changes
Batch or concurrency changes materially
Routing changes
Region changes
Runtime or serving software changes
The measurement methodology changes
The workload shape changes
A measurement from yesterday may be invalid if the deployment changed overnight.

A measurement from six months ago may still be useful for historical reporting if its original conditions are preserved.

The first invalidation signal should be a changed premise, not merely an older timestamp.

Measured, derived, and modeled are different claims
Environmental impact data often combines several types of values.

They should not be presented as one undifferentiated “impact” number.

Measured
Directly observed or instrumented:

Measured energy: 0.40 Wh per inference
Derived
Calculated from measured data and another input:

Carbon = energy × grid carbon intensity
Modeled
Produced using assumptions, external factors, or an estimation methodology:

Modeled water impact = energy × water-intensity factor
A modeled value can still be useful. It just needs to be labeled honestly.

The question is not whether every number is perfectly measured. That standard would make many operational systems useless.

The question is whether a reader can tell:

What was observed
What was calculated
What was modeled
Which assumptions were used
Whether those assumptions still apply
Clear labels create trust. False precision destroys it.

A practical validity model
A useful system does not need to delete old measurements when a deployment changes.

It can preserve them and classify their relationship to the current workload:

current
historical
stale
not comparable
unknown
For example:

if measurement.config_fingerprint == current.config_fingerprint:
status = "current"
elif measurement.has_complete_provenance:
status = "historical_or_stale"
else:
status = "unknown"
The exact implementation can vary. The principle is stable:

Never silently reuse a measurement after its premises have changed.

If a historical value is still displayed, show why it is historical and which configuration it describes.

The export boundary is part of the data model
A metric is not safe merely because it was stored correctly.

It is safe when its meaning survives the places where people use it.

That means provenance should travel into:

API responses
Reports
CSV exports
Dashboards
Benchmark results
Customer-facing claims
Internal planning documents
A number that leaves the database without its configuration context is effectively a different, weaker data product.

This is especially important for environmental metrics. Carbon and water values are often reused in reporting long after the infrastructure that generated them has changed.

The report may be numerically consistent while no longer describing the current system.

The operational question
The useful question is not:

What was the energy impact of this inference?

It is:

What was the energy impact under which conditions, and do those conditions still describe the inference running now?

That same question applies to cost, latency, throughput, carbon, and modeled water.

For production AI, impact data should be treated like any other operational signal: contextual, versioned, and tied to the workload that generated it.

Otherwise, teams risk making confident decisions from numbers that have quietly lost their meaning.

CarbonLayer is validating this problem with teams running production inference. The goal is not to produce another attractive dashboard. It is to test whether trustworthy per-inference data can change a real decision about routing, batching, hardware, capacity, or scheduling.

Because the useful metric is not the one that looks precise.

It is the one that remains valid when someone has to act on it.

If you operate production AI inference and want to test this against one real infrastructure decision, I’d be interested in comparing notes. CarbonLayer is looking for focused design partners—not broad feedback surveys.

The Impact Receipt: Carbon Should Travel With Every AI Request

CarbonLayer — Sun, 23 Aug 2026 00:50:56 +0000

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?

Your AI API Tells You Latency and Tokens. Why Not Carbon?

CarbonLayer — Sat, 22 Aug 2026 02:45:18 +0000

When an AI request finishes, most APIs tell you:

The response
Latency
Token usage
Sometimes the estimated dollar cost
That is useful.

But most APIs do not tell you how much energy the request used, what its carbon impact was, or whether its water estimate was measured or modeled.

That missing layer makes it difficult to build genuinely carbon-aware AI products.

The request is the useful unit
Annual sustainability reports are too broad for developers.

A monthly average cannot tell you what happened during a specific workload, model choice, or routing decision.

The useful unit is the same unit developers already understand: the inference request.

For each request, an AI platform should help answer:

How much energy did this use?
What carbon impact should we attribute to it?
Was the value measured or modeled?
What assumptions and system boundaries apply?
Can the result be compared across workloads?
That data can support internal reporting, customer disclosures, workload optimization, and carbon-aware routing.

Trust starts with honest labels
The easiest way to make environmental data useless is to present estimates as facts.

A facility meter does not automatically reveal the exact water consumed by one inference. Grid-level carbon data does not provide perfect facility-level precision. A water rate without duration and system boundaries is not a defensible total.

Useful infrastructure should make those limitations visible.

That means:

Clearly separating measured and modeled values
Showing the basis of each estimate
Disclosing resolution limits
Keeping direct facility measurements separate from workload allocation
Avoiding false precision
The goal is not to produce a reassuring number.

The goal is to produce a number an engineering team can actually trust.

Carbon-aware inference should be part of the API
CarbonLayer is built around this idea.

It provides a carbon-aware inference API that makes per-call impact visible alongside normal inference usage:

Energy attribution
Carbon attribution
Modeled water attribution
Clear measured-versus-modeled labeling
Carbon-aware dispatch
Savings reporting for teams that want to optimize over time
This turns environmental impact from a static report into usable infrastructure data.

You can start with one workload, inspect the impact of real requests, and decide where the information changes an engineering or product decision.

No green dashboard theatre required.

Start with the workload you already have
You do not need to redesign your entire AI stack.

Choose one repeatable inference workload:

Customer support responses
Document classification
Embeddings
Image generation
Internal copilots
Batch processing
Measure the request-level impact. Compare the results with latency, token usage, and cost.

Then ask the practical questions:

Is a slightly slower route materially lower-impact?
Can lower-carbon windows handle batch workloads?
Should customers see impact metadata?
Which workloads are worth optimizing first?
Those are better questions than whether an entire AI product is simply “sustainable.”

Make every inference count
AI developers already track tokens, latency, and dollars because those metrics affect product decisions.

Energy and carbon deserve the same treatment.

Not because every request can be perfectly measured. It cannot.

Because better-labeled estimates are still more useful than invisible impact, and transparent limitations are better than false certainty.

Try CarbonLayer free with up to 50,000 calls:

https://carbonlayer.polsia.io

Why "water usage" numbers in AI infrastructure are almost always wrong

CarbonLayer — Mon, 17 Aug 2026 01:53:55 +0000

Every water and carbon number you see reported for data center operations is, more often than not, a market-based average — blended across a grid region, smoothed across a reporting period, often built from utility-level estimates rather than the facility itself.

That's not malicious. It's just what the existing frameworks (like ISO/IEC 30134) were built to produce: a defensible average, not a traceable measurement.

The problem shows up the moment you try to do per-inference accounting. If your water/carbon number can't tell you which basin or which grid node it came from, it's not measurement — it's a regional estimate wearing a specific-looking decimal point.

At CarbonLayer we split these into two explicit categories instead of blending them:

Modeled — projections built on climate-scenario water-gap data (we work with 5 climate models × 2 warming scenarios), useful for forward risk, explicitly not a claim about what happened
Measured — facility-level, tied to the actual site an inference workload ran on, with regional water-stress scoring (via WRI Aqueduct) layered in
Reporting these as one blended number is how you get compliance theater: technically defensible, operationally meaningless. Reporting them separately is more honest and, frankly, more useful — a facility operator or regulator can act on "here's our modeled exposure vs. here's what we actually measured" in a way they can't act on a single smoothed average.

We think this distinction becomes mandatory as soon as regulation catches up — the two legislative failures we've been tracking (Texas's water-reporting rider, Rhode Island's energy-benchmarking bill) both died in part because there was no measurement standard underneath the mandate. You can't legislate what you haven't defined how to measure.

When "Water Reporting Required" Doesn't Mean What It Sounds Like: Texas and Rhode Island, Two Ways a Mandate Dies

CarbonLayer — Sun, 16 Aug 2026 04:08:43 +0000

Data centers use enormous, and growing, amounts of water for cooling. In the last two years, at least two states tried to write laws requiring data centers to report that usage. Neither one produced what its own sponsors promised — and the two failures didn't even fail the same way.

Texas: the mandate that became a survey

In 2023, Texas state representative Armando Walle authored Rider 6 (GAA VIII), directing the Public Utility Commission, the Texas Water Development Board, and the Texas Commission on Environmental Quality to jointly develop a data reporting mechanism for large power users, including their water use. Walle's own press release called it "a critical early step" [1] — language that, read closely, was already hedging what the rider would actually deliver.

What it delivered: a voluntary survey, not a mandatory disclosure regime, per the PUC's own FAQ on the program [2]. The underlying docket shows the filing history behind it [3].

Rhode Island: the mandate that never left committee

S2776 and its House companion H7331 [4] bundled three things: data center-specific cost allocation, a siting consultation requirement, and a water-use disclosure and planning requirement for facilities of 50 MW or greater.

The Rhode Island PUC's own testimony to the Senate Commerce Committee (March 10, 2026) [5] is the clearest documentary evidence of why this stalled: the bill required data centers to develop a water plan, but created no matching requirement for water suppliers to develop a data-center rate — regulating demand-side planning while leaving the supply-side rate structure untouched. Both bills were held for "further study" and died when the session ended in June 2026, never reaching a floor vote.

Two failure depths, same underlying pattern

Texas got a law passed, then watched it shrink to a voluntary survey. Rhode Island's water provision never survived committee, with the state's own regulator identifying the design flaw likely responsible. Different depths, same conclusion: even where nobody disputes that data-center water use deserves scrutiny, turning that agreement into enforceable, adequately-designed law has failed twice, two different ways.

Sources

Rep. Armando Walle press release — www.wallefortexas.com/press/2026puc
Texas PUC, Energy and Water Use Survey FAQ — www.puc.texas.gov/industry/water/utilities/energy-and-water-use-survey/faq/
Texas PUC docket, Control Number 59281 — interchange.puc.texas.gov/Search/Filings?ControlNumber=59281
Rhode Island Bill H7331 (2026) — legiscan.com/RI/bill/H7331/2026
RI Public Utilities Commission testimony on S2776, Senate Commerce Committee — www.rilegislature.gov/senators/SenateComDocs/2026%20Commerce/S2776%20RI%20Public%20Utilities%20Commission.pdf

Why "Same Operator" Doesn't Mean "Same Water Risk"

CarbonLayer — Sat, 15 Aug 2026 03:29:14 +0000

We've been building out CarbonLayer's facility-level water stress metrics, and one pattern keeps showing up in the underlying research: the biggest variable in water stress isn't the operator, or even the infrastructure standard a facility is built to. It's the site.

The problem with fleet-level numbers

Most water usage reporting for data centers happens at the company or portfolio level — one WUE (Water Usage Effectiveness) figure representing an entire fleet. That number is easy to report and easy to compare. It's also structurally incapable of showing you the thing that actually matters: whether any specific facility sits in a water-stressed region.

Two facilities built to the identical infrastructure standard, run by the identical operator, can have completely different water risk profiles — because water stress is a function of local supply and demand, not build spec. A facility in a water-scarce region can carry a deficit for most of the year while a sister facility, averaged into the same company-wide number, sits in a low-stress basin. Blend them into one figure and the site carrying the real risk disappears into the average.

This isn't a hypothetical edge case — it's the norm. Water availability is regional and seasonal; data center portfolios are geographically distributed by design. The mismatch between how the risk actually varies and how it typically gets reported is the gap CarbonLayer exists to close.

Modeled vs. measured — a separate axis entirely

The other place aggregation causes false confidence: conflating modeled stress signals (built from frameworks like WRI Aqueduct) with audited or measured facility data. These are different confidence levels. A modeled estimate is a reasonable starting signal. A third-party audited figure is a verified claim. Reporting them side by side as if they're interchangeable is how a portfolio ends up looking safer on paper than it is on the ground.

Why we measure at the facility level

This is the core design decision behind CarbonLayer: metrics at the facility level, not the company level, with modeled and measured signals kept explicitly separate rather than blended into one sustainability score. If you're an operator, regulator, or customer trying to assess real exposure, the resolution you measure at determines whether the risk is visible at all.

Where this is going

We're expanding audited facility coverage (Toronto and Singapore next) and working on a standard for disclosing modeled vs. measured water metrics side by side, instead of as one blended number.

If you work in data center ops, ESG reporting, or hydrology/geospatial data and have thoughts on how facility-level disclosure should work — I'd like to hear them.

Every inference call already returns your response. We added three more fields: cost, CO2, and water.

CarbonLayer — Sat, 15 Aug 2026 03:02:43 +0000

Most carbon/sustainability tooling for AI means a separate dashboard, a monthly export, or a spreadsheet someone fills in manually. We built it into the call itself.

Point your existing model API calls at our endpoint at carbonlayer.polsia.io. Same response you already parse — plus:

{
...your normal response,
costUsd: 0.0021,
co2Grams: 4.7,
savedWaterMl: 12.3
}
No separate integration. No batch job reconciling usage logs against a sustainability report six months later. The number is attached to the call, generated by the routing decision, at request time.

If you're already switching between model providers or regions for latency/cost, you're one header away from also seeing the environmental cost of that same decision — check the docs at carbonlayer.polsia.io to see the exact fields.

Why "Data Center Water Usage" Numbers Are Mostly Guesses — and How We're Fixing That

CarbonLayer — Sat, 15 Aug 2026 00:42:35 +0000

Every data center water/energy stat you've seen in a headline this year is probably a model, not a measurement. That distinction matters more than it sounds like it should — and it's currently playing out in real policy decisions, not just spreadsheets.

The trigger for this post: Louisville just moved to ban new data centers outright. Stacy Griggs wrote a good breakdown of why that's the wrong tool for the job — and the core argument tracks with what I keep seeing from the technical side: a moratorium isn't a policy, it's a symptom. It's what a city does when the only inputs available are fear and headlines, because nobody handed them facility-level numbers to make a real cost/benefit call. Ban-or-blind-trust is a false choice, and it's a data availability problem before it's a political one.

The actual technical problem: Most public water-stress numbers for data centers come from vendor-published PUE, generic regional averages, or top-down estimates that don't account for facility-specific cooling systems, local water sourcing, or recycling infrastructure. Two facilities in the same city, same operator, same building spec, can have wildly different actual water demand depending on how they're built and run. Regulators and communities making zoning and moratorium decisions are working off averages that hide that variance completely — which is exactly how you end up with a binary ban/no-ban choice instead of a nuanced one.

What we're building at CarbonLayer: We're extending the ISO/IEC 30134 data center efficiency framework — the standard that gave the industry PUE and WUE — to produce a facility-level metric we call WUE+: water usage effectiveness that incorporates on-site recycling and is layered against regional water stress data from WRI Aqueduct.

The core design decision: modeled and measured data are never merged into one number. A model gives you a directional estimate. An audit gives you a verified fact. Collapsing those into a single score is how the industry got into a trust problem in the first place — so we tag every metric with its provenance and let the two live side by side instead of averaging away the uncertainty.

Where we are: Currently auditing facilities across our initial footprint, expanding to Toronto and Singapore next based on where operators and regulators are asking for coverage.

If you're working on infra observability, ESG tooling, or anything touching facility-level resource accounting, curious what you're running into — drop it in the comments.