open-standards/eoc/standards/sci-for-ai-energy-provenance-annex.md

Proposed Annex: the provenance and validity of E

Draft submission for filing to github.com/Green-Software-Foundation/sci. Licensed CC-BY-4.0.

Status: working draft v0.1. Authors: Transaction Science. Target: SCI-for-AI, as an annex to the treatment of E. Companion to sci-for-ai-submission.md, which maps EOC receipts onto the four-component formula and assumes E is already trustworthy; this annex is about whether it is.

---

a. Summary

SCI = (E × I + M) per R is well specified in every term but one. I has a location-based methodology. M has a lifecycle methodology. R is deployment-defined and the specification is explicit that it must be stated and reproducible. E has no comparable requirement. A figure may be labelled "measured" without saying what measured it, over what span, on which silicon, or on whose behalf — and in current practice it frequently is.

This annex proposes five requirements (E1–E5) that make an E figure self-describing, and one refusal: a figure taken over a span shorter than its counter's update period is not a measurement of that span and MUST NOT be reported as measured. All five are machine-checkable, and a reference implementation exists.

What this annex does not propose. No change to R. SCI-for-AI already supports diverse functional units — tokens for language models, inferences for classifiers, FLOPs for training — so non-generative inference, including the typed-decision models that emerged in September and October 2026 and emit no tokens at all, is already expressible as R = one inference. The gap is not in the unit of work. It is in the energy.

b. The problem, as evidenced

Three independent observations, none of them about a careless implementer:

1. Published work that has a sensor reports only part of the machine. A survey of recent AI-energy measurement work finds the instrumented studies are GPU-rail-only — no CPU package, no DRAM, no NIC, no storage, no power-supply loss — and that none of them declares its sampling interval, the device's update rate, or the integration method actually used.
2. "Measured" is being applied to estimators. A reference implementation in this ecosystem stamps measured on the output of a lifecycle estimator whose own documentation calls it an estimation. The alternative path uses hard-coded kWh-per-token constants calibrated from a single figure at ±50%. Neither is wrong as an estimate; both are wrong as a measurement.
3. Per-call energy is being taken from provider SDKs, which report a number with no stated counter, period or boundary. The reporter cannot tell a hardware reading from a model, and neither can the reader.

Why this is not pedantry

The error is not symmetric. A figure used in a budget or a ceiling that under-reports admits work the budget cannot cover, silently; one that over-reports refuses work that would have fit, visibly. A figure used in a disclosure that under-reports understates an obligation. In both cases the unsafe direction is the one an uncharacterised counter takes.

And counters do take it, by large factors. A 588-run study of one widely used cumulative-energy counter measured it under-reporting integrated power by 95.4% at 0.5 ms sampling, recovering to 1.6% only at 1 s, and recommended against unvalidated use. Three weeks later a separate paper built its entire per-token energy decomposition on that same counter, specifically because power sampling cannot resolve short decode windows. Neither cites the other. A third observation, on different hardware, has the same counter class reading 4–30× the board's actual draw when polled at 100 ms. Three mutually inconsistent characterisations of one counter class — which means the validity bound is itself sampling-interval-dependent and cannot be assumed.

We reproduced the shape on a fourth counter. Burning one thread's CPU and sampling the macOS per-process energy counter 60 times per interval, the fraction of intervals in which it advanced was 0% at 10 µs and 50 µs, 2% at 100 µs, 5% at 500 µs, 35% at 1 ms, 63% at 2 ms, 87% at 5 ms, and 100% at 10 ms. Below 1 ms it does not lag smoothly — on the intervals where it moved at all, the median step was ~20 mJ, two orders above the 1 ms step. It accrues in lumps. A sampler reading it every 500 µs would see nothing most of the time and a 20 mJ jump occasionally, and would report both as measurements.

The lumps are the kernel's bookkeeping, not the hardware's. A thread's energy is added to its process's count when the thread leaves its core, so a reader on a running thread sees nothing until that thread's scheduling quantum ends, and then sees all of it at once. A reader that first leaves its core, and checks that its own thread's count moved across that pause, reads the same 1 ms spans to within a few percent of an independent read; unchecked, on an idle host, it read none of them. The counter is exact; an unchecked read of it is not.

c. Proposed requirements

An E figure claiming to be measured MUST carry:

E1 — Source. The named counter or instrument: rapl, nvml, rocm-smi, level-zero, ioreport, proc-rusage, tegra-ina, qualcomm-qpt, ascend-smi, hl-smi, cnmon, external-meter, … Not the word "measured". Two figures from different sources are not interchangeable: they have different domains, different periods and different attribution.

E2 — Period, and the span rule. The counter's documented or measured update period, and the span the figure covers. If the span is shorter than the period, the figure MUST be reported as modelled, not measured. A source whose period is undeclared can never support a measured claim at any span, because the direction of its error is unknown. A per-operation figure for work shorter than the period is sound only as the mean of many operations over a span longer than it.

E3 — Attribution boundary. Whether the figure counts one principal's work (a per-process or per-container counter) or the whole machine (an SoC rail, a package counter, a board shunt). These are different claims, and the distinction is independent of how much of the task is covered. A machine-wide figure attributed to one workload MUST state the condition under which that is valid — normally exclusive use — and MUST report the magnitude of its idle correction, so a reader can see whether the correction is a rounding error or the result.

E4 — Fabric breakdown. Where the work crosses silicon, E SHOULD be reported per fabric (cpu, gpu, npu, dram, package, …) and MUST state which fabrics are not covered. A total that silently omits a fabric the work used is an understatement, and on accelerated inference the omitted fabric is usually the dominant one.

E5 — Why a fabric is uncovered. Where a fabric is not measured, the reason MUST be one of five, because they are not interchangeable:

status	meaning
frozen	counter present, not advancing
absent	no such silicon on this host
needs-privilege	present, requires privilege the reporter lacks
no-counter-exists	present, and exposes no energy counter at all
not-implemented	a counter exists; this reporter has no reader for it

Only no-counter-exists is a property of the hardware. The other four are properties of the deployment or the tooling, and they are fixable.

This matters beyond accounting hygiene. The EU AI Act's GPAI Code of Practice requires providers to document known or estimated energy consumption for training and inference, while permitting an exemption where the provider lacks "critical information from compute or hardware provider". That exemption is a claim of no-counter-exists. E5 is what distinguishes it from the four statuses that do not justify it — and an unprivileged on-die counter, which needs no cooperation from the compute provider at all, narrows the set of accelerators for which the claim can honestly be made.

d. Worked example

A three-question typed decision served by a 421M-parameter decision model on an Apple M5 Max, R = one inference:

E       = 1.0413e-4 Wh   (104 127 µJ)
R       = 1 decision
source  = { gpu: ioreport, cpu: proc-rusage }
period  = 10 ms both; span = 2.606 s over 200 decisions  → measured (E2 met)
fabrics = gpu 96 591 µJ  attribution=machine, idle-corrected by 0.08%
          cpu  7 536 µJ  attribution=process, coverage=whole for CPU work
          npu  0 µJ      frozen (no ANE Energy aggregate on this part)
          dram —         not-implemented (rails exist; this reader omits them)

Two things the annex makes visible that a single number hides. First, the figure is a mean over 200 decisions, because one decision takes 11.85 ms and a 10 ms-period counter cannot resolve it — under E2 a per-decision counter read would have had to be reported as modelled. Second, 93% of the energy is on a machine-attributed rail, so the figure is this workload's only under exclusive use; the idle correction was 0.08%, which is what makes that credible here and would not be on a shared host.

The same decision class run on the CPU instead costs 0.486–0.555 J — roughly five times more energy — and is entirely principal-attributed and whole-coverage. Under E3 those are different claims, and a reporter choosing the cheaper figure is also choosing the weaker one. Without E3 the two look like the same kind of number, and the cheaper one wins every comparison.

e. Conformance

All five requirements are machine-checkable, and we have an implementation rather than only a proposal:

• A metering ladder that tags every figure with its source and refuses to upgrade a model's output to a reading.
• A per-fabric survey that returns E1, E3, E4 and E5 for every (fabric, source) pair on a host, probing presence so an unread accelerator reports not-implemented rather than the false claim absent.
• The E2 refusal as a predicate over (declared period, span), with the counter characterisation above as its evidence.
• Measurement harnesses for both the counter characterisation and the per-decision figures, so the numbers in §d are reproducible rather than quoted.

We propose filing this as an annex under the extension URN urn:gsf:sci-ai:ext:energy-provenance:v1, additive and imposing nothing on deployments that report estimates — which remain perfectly conformant, provided they say so.

f. References

• ISO/IEC 21031:2024 — Software Carbon Intensity (SCI) specification.
• GSF SCI for AI — ratified 2025; functional units for language models, classifiers and training.
• GSF, SCI for AI and EU AI Act environmental compliance — the policy framing this annex is intended to support.
• EU AI Act GPAI Code of Practice, Model Documentation Form — energy consumption for training and inference; the compute/hardware-provider exemption.
• Dauner et al., Evaluating the Influence of Measurement Frequency on [GPU energy counters], ACM SIGENERGY Energy Informatics Review 6(2), July 2026 — the 588-run study; 95.4% under-read at 0.5 ms.
• Characterization of Request and Token Energy Costs for LLM Inference Workloads, arXiv:2608.28044 — builds on the same counter for the opposite reason.
• CEN/CLC/TR 18145:2025, Green and Sustainable AI — the European guidance this annex is also offered to.
• AFNOR SPEC 2314, Référentiel général pour l'IA frugale — prescribes estimator tooling for claims of frugality; E1/E2 are what would let such a claim be checked.
• Blauer Engel DE-UZ 215 — software energy criteria requiring measurement on a defined test system; the German UBA's own reporting names energy per classification as a KPI.
• UNE 0086:2025 — energy, carbon, water and performance of AI systems.

---

Working draft. The filing to github.com/Green-Software-Foundation/sci will carry a JSON-Schema definition for the E-provenance block, the conformance predicate for E2, and the reproducible harnesses behind §d.