How Compute measures electricity and emissions

Your Monthly Compute impact report follows the work recorded for your account and the electricity Lithi can attribute to that activity. It shows whether each figure is measured, estimated, or unavailable, how much activity the evidence covers, and which parts of the service boundary are still missing. An unavailable value is not zero.

The report keeps four questions separate: what useful work was accepted, what physical activity used electricity, what emissions factor fits that electricity, and what money records say. Failed attempts, retries, independent checks, preparation, and finalization can use electricity even when they do not become accepted customer work or another customer charge.

Follow one task from execution to the monthly report

One logical task can have more than one physical attempt. A result check can also run on a Mac. These branches return to one task record; they do not become several customer tasks.

One task
  ├─ First attempt → failed
  ├─ Retry         → accepted
  └─ Independent check
             ↓
Electricity from the covered activity
             ↓
One task's impact record

The sequence is illustrative. A particular task may have no retry, a different checker arrangement, or no reportable energy line. A device rejected during admission is not an executed task attempt. If an admission check or another pre-execution activity uses electricity, it needs its own attributable evidence; it must not be folded into a task attempt that never ran.

Three checks answer different questions:

Passing a result check does not validate an electricity measurement. A failed attempt that actually ran remains physical activity even when its result is rejected. The monthly Work count covers accepted customer outcomes by completion time; the energy figure covers physical consumption intervals, including failed and unpaid work.

Turn Mac observations into reportable energy

Macs can provide a bounded energy interval, a calibrated device reading, or runtime and workload evidence that supports a reportable profile. A timing, thermal, or power observation can be real without containing a reportable electricity quantity. Not every Mac reports direct kWh for every task.

Use these reader labels when you read a figure:

For the report’s aggregate fields, see Compute Impact Reports API. The energy check considers the device, release, workload, interval, measurement boundary, profile, and allocation evidence. A profile outside its validation envelope or a missing observation leaves that line unavailable or recorded without a reportable amount.

Attribute shared electricity once

Lithi may receive a source window that includes several activities. For task work, it attributes each share using the recorded activity and the declared allocation method. Platform prewarm or idle overhead can use overlapping customer active time. Device-load and grid-input quantities remain separate boundaries, and a grid-input reading that already includes the Mac's electricity must not have the Mac reading added again.

Electricity used
(measured or estimated)
          ↓
The share attributed to your work
          ↓
Emissions factor for that place and time
          ↓
Operational emissions estimate

For an illustrative example, suppose a failed attempt accounts for 0.20 Wh, a successful retry for 0.50 Wh, and an independent checker for 0.10 Wh. The covered activity totals 0.80 Wh before an emissions factor is applied. These numbers are teaching examples, not a Lithi measurement. Platform retries and default verification do not create another charge for the same accepted work; separately requested comparisons follow their quote. Impact evidence follows attributable physical activity, while billing follows the commercial contract.

When an approved grid-input amount already includes the device load, the same interval appears once in the grid input. The device-load field describes that boundary; it is not an extra amount to add to the grid input.

Match electricity to place and time

Operational emissions use the execution or grid region, the consumption interval, and a factor whose geography, gas basis, boundary, and validity fit that interval. A report generated later uses the factor that applied when the electricity was consumed. Customer reporting region, execution or grid region, and provider or payee business region are different facts; a broad reporting region or a provider address does not prove where work ran.

Each factor keeps its dataset year, publication date, revision date when supplied, and retrieval date. The report also retains the requested and used method, fallback tier and reason, source version, units, gas basis, boundary, geography, and validity. If no factor fits the usable evidence, emissions are unavailable rather than silently assigned a coarser method. A forecast remains labelled as forecast.

The method can use the UK Government greenhouse gas conversion factors, the UK Carbon Intensity API, and US EPA eGRID summary data when their source, geography, time, and boundary fit. These sources describe different things. The Carbon Intensity API's methodology provides CO2 for its actual and forecast values, which is not automatically CO2e. A dataset year, publication date, or revision date is not the month in which Lithi generates a report. A missing source date stays unknown; the retrieval date does not stand in for it. The GHG Protocol Scope 2 Guidance informs method choices; it does not assign a customer's inventory classification. The Software Carbon Intensity specification and ISO/IEC 21031:2024 provide methodology concepts for measurement, modeling, supporting infrastructure, operational energy, and embodied hardware. A Lithi report is not a certification or independent assurance.

Keep coverage, hardware, and infrastructure visible

The monthly report keeps coverage beside each figure. It can show physical-time coverage for all physical intervals, including failed and unpaid work, and grid-factor coverage for usable grid input with an approved factor. “80% of known active time” is not “80% of all emissions.” A covered subtotal is not the whole footprint, and a missing component does not become zero.

Operational service emissions, embodied hardware impact, and managed infrastructure are separate components. Embodied impact is a declared lifecycle allocation for the hardware evidence, using a basis such as time, resource share, or expected life. The gross modeled lifecycle figure follows its source boundary, which may include a supplier's renewable-electricity matching assumption; credits and offsets remain separate. If a source does not provide a numeric manufacturer-phase percentage or uncertainty value, that field stays unknown rather than becoming zero. An offset-adjusted zero is not a zero physical footprint.

Managed infrastructure covers the Lithi services inside the declared boundary, including control services, database and queue, artifact storage, and network transfer. Infrastructure energy and infrastructure emissions are separate evidence fields. If a supplier provides CO2e but no qualified kWh, the report can show emissions available and energy unavailable; it does not reverse-engineer energy from an assumed factor. Customer-chosen frontier providers and downstream tools remain outside the Lithi service boundary unless compatible evidence is supplied separately. If a required component is missing, the report keeps available components visible but does not publish a complete boundary total.

The method keeps five uncertainty components separate: energy in the usable observation or profile; allocation to the service activity; the factor source, gas coverage, and method; region-time matching; and the boundary covering preparation, retries, verification, transfer, storage, or infrastructure. It records a declared bounded_interval.v1. It does not present that interval as a 95% confidence interval. Missing telemetry, an unsupported profile, or a missing factor remains an explicit omission.

Keep Work, impact, and money in their own lanes

The Work section counts accepted useful outcomes for the account and period. Physical activity can include failed or retried work, verification, cancellation tails, or finalization. The Community section describes participation and eligible allocation records. A contribution allowance is noncash; it creates no customer charge, provider payout, or referral payout. A provider allocation or accrued value is not a confirmed payment.

Lithi reports service emissions under its declared boundary. It does not label that value as the customer's Scope 2 or Scope 3 classification. The customer's accounting team decides how a purchased service belongs in its own inventory using its organizational boundary and applicable guidance. A savings or avoided-emissions claim needs a qualified Stage D comparison: a documented comparable baseline, matched useful output and quality, the same relevant boundaries, and stated coverage and uncertainty. Inventory evidence alone is not that comparison.

The report keeps customer reporting, execution or grid, and provider business or payee regions distinct. Aggregate displays may withhold a small group or use a broader region to protect privacy. Existing Macs and people's choice to take part express Lithi's people-powered mission; they do not prove lower energy use, avoided manufacturing, work in a chosen region, available work, or income.

Trace a figure back to its filed report

Keep the report period, revision, snapshot digest, source watermark, method edition, units, denominator, evidence label, factor source, boundary, and omissions with any figure you share. Corrections create a new revision with lineage to the earlier snapshot; they do not silently rewrite a filed report. Read Read a Compute impact report for the customer guide, and use Compute Impact Reports API for exact fields and retrieval authority.

Use billing, invoice, and provider-payment records separately from impact evidence. An unavailable impact value does not establish that no work occurred, no electricity was used, or no charge exists. When a figure is disputed, share its report reference and calculation question, not customer files, device identities, private messages, or bank details.