WAI Extension: Energy Measurement

Mirrored from the canonical text at commit 117bad22 (2026-10-01).

Status: Draft. Specifies how a joule figure is acquired, so that the joules_micro field the receipt profiles carry means the same thing in two independent implementations. It defines an acquisition class and its signed encoding (§2, §2.7–§2.8), an acquisition protocol with a liveness rule for the power reader (§3, §3.1), a quality rule (§4), and a reporting contract (§6) whose values are published in a signed report that names the receipt it describes and leaves that receipt’s bytes unchanged. A receipt that carries none of these additions keeps exactly the bytes it had. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

1. Why an acquisition protocol

jwp-receipts.md defines joules_micro as “microjoules consumed producing this object”. That fixes the unit and the scope of attribution. It does not fix how a number gets into the field, and without that the field is a number-shaped hole: one implementation can write a counter reading, another an arithmetic model, a third a constant, and every one of them is conformant. The figures are then incomparable, and — worse — indistinguishable, because nothing in the receipt says which kind it is.

This extension closes that. It requires two things of any receipt it governs that carries energy: that the figure declare how it was acquired, and that the measurement declare whether it was good enough to publish.

The contribution is not the number. It is the number plus its acquisition class, and the discipline of withholding both when the measurement fails.

Scope. This extension governs every receipt profile WAI defines that carries an energy figure, and the producers and verifiers of those receipts. They include the receipts §2 lists, which carry joules_micro or, in the energy binding, microjoules; the MoQ WAI_RECEIPT property (moq-streaming-format §5); and the JWP group and object receipts (jwp-receipts §2.4), which carry joules_total and joules_micro. The list is not closed: a profile WAI defines is governed as soon as it carries a figure.

It does not govern a receipt profile that WAI ingests and whose members that profile fixes. An OER/2 receipt (oer-receipts) is one. It carries a non-zero energy.joules_total with no member for the class, and cannot gain one: a member not listed for its path makes the receipt non-canonical (§3 there). What an OER receipt carries instead is an evidential grade, provenance.how, and oer-receipts §2 states which grade each class supports. No rule of this extension binds an OER receipt, or its producers and verifiers as such: not the class of §2, and not the publication gate of §4 or the reporting contract of §6 either. OER/2’s own rules govern it, and an OER receipt with a non-zero figure and no class breaks no rule here.

One rule reaches past the governed receipts. §2’s rule for carrying a WAI figure into a vocabulary with only three class names binds whoever carries it, although the receipt the figure lands in is not governed.

Two receipts WAI defines carry a figure that the group signature does not cover in its legacy form: the JWP group receipt and the JWP object receipt (jwp-receipts §2.4.1 and §2.4.2). The group receipt signs joules_total, the sum of its objects’ figures. The object receipt carries its own joules_micro, which the group signature covers only through the object’s Merkle leaf (jwp-receipts §2.2). Each meets §2 as follows:

• An object’s figure carries its class as an optional label (§2.8), bound into its Merkle leaf with the figure and the object’s origin. Absent, the leaf and every signed byte are the legacy ones and the figure is unlabelled. Present, the leaf covers the figure, its class, the class’s evidence and the origin, and the group signature, which covers the Merkle root, covers them too.
• A group total may carry a class of its own, signed under the labelled group payload (jwp-receipts §2.3) together with its coverage and the parent link. The class is the one the objects’ classes compose to (jwp-receipts §2.4.1), so a holder of the group receipt alone holds a signed class for the total, and a holder of every object checks it (jwp-receipts §3, The group total). A group in the legacy payload carries none; a verifier holding every object reads its total from the objects’ labels as §2.8 reads a total, and otherwise reads it as unlabelled.
• A WAI_RECEIPT property (moq-streaming-format §5) has no signature of its own. Its class is inside a signature only where it equals a signed statement of the same object’s figure and class: the label in the object’s leaf, or an energy claim about the object. A sink reads it as a class only after checking that it does (moq-streaming-format §5).

An energy claim (jwp-receipts §2.4.5) is a receipt of its own, signed by whoever acquired the figure. It restates an object’s joules_micro beside its class and the class’s evidence in §2.7’s JSON fields, and meets §2. A verifier holding the claim and the object receipt rejects the pair if the two figures differ, or, where the object’s leaf is labelled, if the two classes or their evidence differ. It is the way for a party other than the publisher to sign a class for an object’s figure.

The interactive-worlds session receipt is a profile of the group receipt that carries the class as an optional signed label (interactive-worlds §8, and §2.8 here). It is signed under its own domain, wai:world-receipt\x01, not the base group receipt’s, and nothing above changes it.

Whose key signed a figure’s class can be confirmed under jwp-receipts §7: an origin the verifier has anchored lists the key with the authority energy/ followed by the class. That is the origin’s statement of which of its keys states figures of that class, and a key given one class cannot state another. For the hardware classes the confirmation holds only under an anchor the relying party pinned, never one fetched on first use (jwp-receipts §7.5). It is not evidence about the instrument (§2.2), and no confirmation ranks a figure above its class (§2). jwp-receipts §7.5 recommends that a hardware-class figure be signed by a key held by the component that signs the reading, apart from the key that signs delivery, and has a verifier report whether the key also holds delivery.

2. The acquisition class (REQUIRED)

A receipt this extension governs (§1) that carries a non-zero energy figure MUST carry an acquisition class alongside it. The one exception is the unlabelled legacy form that §2.8 keeps for the receipt families that sealed a figure before the class existed, the JWP object receipt and the JWP group receipt’s legacy payload among them. A WAI_RECEIPT property’s class counts only where §1 says it does.

CalibratedInstrument and OnChipCounter are refinements of HwShunt, the hardware rung of the three-name vocabulary (HwShunt / ModelBased / Estimator) the receipt families elsewhere in the ecosystem use. A producer that emits a WAI figure into a vocabulary with only those three names MUST map both refinements to HwShunt; that loses the distinction and asserts nothing false. The vocabulary is extended, not replaced. The evidential grade of an OER receipt (oer-receipts §2) is a separate axis, and that section states which grade each class supports.

A counter reading is not an estimate. RAPL, NVML and IOReport are sensor values, and OnChipCounter says so (§2.9 states where this departs from other documents in the repository). What separates the two hardware classes from each other is what backs the figure’s uncertainty (§2.2), and what separates both from the rungs below is provenance and scope, not accuracy — see §5.

The classes are ordered by what backs the figure’s uncertainty statement, strongest first: CalibratedInstrument, OnChipCounter, HwShunt (legacy), ModelBased, Estimator. Wherever this extension says “the weaker class applies”, it means this order.

Normative:

• An unmetered figure is not a figure of zero joules. Where a field encodes unmetered as 0 — joules_micro in every receipt profile WAI defines, and the legacy fields that predate this section — that 0 is the unmetered marker: a reader MUST present it as unmetered and MUST NOT present, total, average or compare it as 0 J. A total over parts that include unmetered parts covers only the measured parts (Partial, energy-binding §4) and MUST say so. A field or form defined after this revision marks unmetered explicitly — class tag 0 beside a zero figure, as the labelled JWP leaf and group do (jwp-receipts §2.2, §2.3) — and never by a bare 0 alone. A meter that cannot measure produces no reading at all, never a reading of zero, and a model whose output is zero is not a measurement of zero either.
• An implementation MUST NOT emit a non-zero energy figure without a class in a receipt this extension governs (§1), except in the unlabelled form of §2.8. An unlabelled number cannot be compared to any other number.
• An implementation MUST NOT emit a class with a zero or absent figure. That claims a measurement which did not occur.
• The class MUST be inside the signature, so an intermediary cannot promote a ModelBased figure to a hardware class, or an OnChipCounter figure to a CalibratedInstrument one, in transit. The class’s evidence — the declared uncertainty, the filtering state, the calibration reference — MUST be inside the signature with it (§2.7).
• A verifier MUST treat a receipt violating either coupling as invalid, not merely as unlabelled — with the one exception of a legacy unlabelled figure in a receipt family that carries the class as an optional label (§2.8) — and MUST treat a CalibratedInstrument or OnChipCounter class that lacks its declared uncertainty (§2.3), or a CalibratedInstrument class that lacks its calibration reference (§2.5), the same way.

The reference implementation enforces these rules in verify() rather than documenting them, and returns no rate at all — never 0 — when unmetered, because a zero reads as “this work was free”, which is a stronger and false claim than “nobody measured”. The class and its evidence have one definition (energy_class in wai-rs, mirrored byte for byte by quantum_energy in wai-quantum), and every receipt within this extension’s scope (§1) that the reference implementation seals carries its figure in one of two ways:

• Always present, in the receipts defined with a class from the start: the energy binding and its C2PA companion assertion (energy-binding), the wai.video.int_motion receipt, the wai.video.* OTT receipts, and the energy claim (jwp-receipts §2.4.5).
• As an optional label (§2.8), in the receipt families that sealed a figure before the class existed and whose issued receipts must keep verifying: the world-session, film and reel, haptic, score, 4D-splat, audio-scene, ternary-reconstruction and provenance-step receipts in wai-rs, and every quantum receipt of wai-quantum (circuit, calibration, job, mitigation, decode, compile, rearrange, phasor, and the bill of materials per entry).

wai-rs reads and verifies JWP group and object receipts in both forms of each, computes an object’s leaf in both forms of jwp-receipts §2.2, reads a group total from its objects, and reads a WAI_RECEIPT property against a signed statement of its object (jwp_delivery). Neither crate seals a JWP group receipt for delivery — wai-rs builds them only for its conformance corpus — or writes a WAI_RECEIPT property.

2.1 Relationship to network-layer energy identities

The classes above are WAI’s own vocabulary. An adopted IETF GREEN working-group draft (draft-ietf-green-power-and-energy-yang, revision -04 when this section was written) defines a graded data-source-accuracy identity hierarchy for device and sub-component energy, which is the network layer’s answer to the same question this section asks: how was this number obtained? Its graded measured identities are bounds on the total error of one device reading, of the form |actual − sensor| ≤ sensor × X % or an absolute limit. The declared uncertainty of §2.3 is a different kind of statement about a different quantity, and the rules below keep the two apart.

• An implementation that also reports under a network-layer energy model SHOULD derive its acquisition class from that model’s identity rather than assigning one independently, and MUST state which identity it derived from. Two vocabularies for one property, assigned separately, will disagree.

• A derivation MUST NOT improve the class. Where a network-layer identity maps ambiguously, the weaker WAI class applies. A measured identity, graded or not, says a sensor was read. It does not say that the sensor’s error is traceable to a calibration, so it yields OnChipCounter unless the implementation holds the calibration reference of §2.5.

• An implementation MUST state how far its acquisition class lets the figure be leaned on. A class without that is a label, and grading provenance exists to put a number on it. For the two hardware classes the number is the declared uncertainty of §2.3. ModelBased and Estimator do not yet carry one in any receipt profile; that remains open.

• A graded band MUST NOT be declared as a figure’s uncertainty. The band bounds one reading of the device. A WAI figure is the difference of two bracket means, attributed per object (§3). A pure gain error carries through that difference unchanged and a constant offset cancels, but readings that are each within a band can otherwise differ from the true marginal by far more than the band, relative to the difference. A band MAY inform the counter’s systematic component when the declared uncertainty is evaluated (§2.3); the declaration remains the implementation’s own evaluation of the figure.

• A declared uncertainty MUST NOT be used to select or assert a graded measured identity. No coverage factor makes the step sound, for three reasons:

  1. A graded band is a limit. A declared uncertainty is a standard uncertainty. Expanded at k = 2 it corresponds, for a normal distribution, to a coverage probability of about 95 %, which is not a limit.
  2. An OnChipCounter declaration does not cover the counter’s own systematic error (§2.3), so it is not a statement of total error at all.
  3. The declaration is about a per-object marginal figure, and the identity is about a device or sub-component reading. Treating one as the other is the conflation the next paragraph forbids.

  A graded identity for the device’s reading has to rest on a limit established for that reading, such as a vendor’s stated accuracy for the counter or the maximum permissible error an instrument has been verified against over its range and conditions of use, under that model’s own definitions. Nothing in a WAI receipt supplies that limit.

WAI does not adopt the network-layer model, and this section does not restate it. The scopes differ — that model is device- and sub-component-scoped, WAI’s figures are per-object — and conflating them would breach §4’s attribution rules. What is required is that the two do not contradict each other about the same measurement.

2.2 Two kinds of hardware evidence

An on-chip counter and a calibrated external instrument are both hardware readings, and both are real measurements. They are different evidence, and a single class put them at one trust level.

• An on-chip counter is the measured silicon reporting on itself. Its reading is a sensor value. What it cannot offer is an uncertainty traceable to a reference: the figure’s uncertainty is whatever its vendor states or the implementation can evaluate. Some counters also add deliberate noise to their output as a side-channel defence (§2.4), so the same counter is noisier over a short window than a long one.
• A calibrated instrument’s error has been established against a reference and written into a certificate a third party can read. A deployed regime that signs measured energy per transaction shows the same split between signature and trust: in EV charging, signed meter values in the Open Charge Metering Format (OCMF) are accepted under German calibration law because they come from a conformity-assessed, legally verified measuring system — the meter together with the component that signs its values. The signature binds each value to that system so a customer can check it later. It does not make the value accurate; the metrological assessment does. (Legal verification against maximum permissible errors is not the same statement as a calibration certificate’s uncertainty; §2.1 keeps the two apart, and §2.5 asks for the latter.)

A signature settles who said a number. It says nothing about how far the number can be from the energy actually spent. Confirming whose key it is (jwp-receipts §7) settles which origin stands behind the key, and for which class, and nothing about the reading. The declared uncertainty (§2.3) is the statement about that, and the class says how much of it the declaration covers. For CalibratedInstrument it covers the instrument’s error as established by its calibration, together with the measurement’s own scatter. For OnChipCounter it covers only what the implementation could evaluate, which does not include the counter’s own systematic error.

What separates the two classes is whether the uncertainty is traceable, not where the sensor sits. An external meter with no current calibration MUST be reported as OnChipCounter, the weaker class; a sense resistor read by the device’s own firmware and reported through the device’s own counter is OnChipCounter whatever its construction. The class therefore does not record where the sensor sits — at the die or at the wall, with or without supply losses — and a verifier reasoning about scope (§5) cannot learn it from the class.

Neither class is an accuracy grade. A small declared uncertainty on an on-chip counter says the reading was precise. How accurate it was rests on the counter, and the class is what tells a reader that.

2.3 The declared uncertainty (REQUIRED for the hardware classes)

A CalibratedInstrument or OnChipCounter class MUST carry a declared uncertainty of two parts:

• Both parts MUST be non-zero. A relative uncertainty of zero claims a perfect measurement; a window of zero is not an integration. A verifier MUST treat either as an undeclared uncertainty.

• The window is not optional. Counter noise depends on it — filtered counters are several times noisier over 100 ms than over 1 s (§2.4) — so a relative error without its window cannot be compared with anything.

• An implementation converting a fractional uncertainty to relative_ppm MUST round up, so the declaration never states less uncertainty than was evaluated.

• The declaration describes the figure as sealed, and joules_micro is a whole number of microjoules. Whatever the measurement, the integer carries its own resolution, and the declaration MUST include it:

  • A figure rounded from an estimate to the nearest microjoule is within ±0.5 µJ of it. Taken as rectangular over that limit (GUM F.2.2.1), this adds a standard uncertainty u_res = 0.5/√3 µJ (≈ 0.289 µJ).
  • A figure read as the difference of two whole-microjoule register readings is within one step of the energy at each end. Two such offsets differ by a triangular error over (−1, +1) µJ (GUM 4.3.9), which adds u_res = 1/√6 µJ (≈ 0.408 µJ). A register whose hardware unit is coarser than a microjoule hides that unit from the reader, and the declaration MUST cover it separately.

  The term is fixed in microjoules, so relative to the figure it grows as the figure shrinks: a rounded figure of 1 µJ is uncertain by at least 29 % from its rounding alone, one of 10 µJ by 2.9 %, and one of 1,000 µJ by 0.029 %.

• Because of that, every declaration satisfies joules_micro × relative_ppm ≥ 288 676: the absolute standard uncertainty joules_micro × relative_ppm / 10⁶ µJ is at least 0.5/√3 µJ, and 288 676 is the least integer at or above 10⁶ × 0.5/√3. A verifier MUST treat a hardware class whose declaration is below this floor as invalid. The check needs nothing but the receipt, and it is in integers, so every verifier reaches the same verdict. It is a necessary condition, not a sufficient one: a declaration above the floor can still understate what was not evaluated.

What the declaration covers depends on the class:

• CalibratedInstrument: the instrument’s calibrated uncertainty at the range and conditions of use, combined with the measurement’s own uncertainty as evaluated below.
• OnChipCounter: the components the implementation can evaluate — at minimum the measurement’s own uncertainty as evaluated below, and any noise the counter’s vendor states it adds at the declared window. It cannot include an unquantified systematic offset of the counter. An OnChipCounter declaration is therefore not a statement of the figure’s total error and MUST NOT be presented as one. A reader MUST read it as the evaluated part of the figure’s uncertainty, to which the counter’s systematic error adds an amount nobody has stated. The class name is what tells a reader that.

For the bracketed marginal protocol of §3, the per-unit estimate is E = (mean_busy − mean_idle) × window ÷ W, where W is the work the window paid for, estimated from the completion count C as below. The measurement’s own relative uncertainty combines two components, and the declaration adds the rounding of E to the sealed figure F:

u_power = sqrt(s_idle² / n_idle + s_busy² / n_busy) / (mean_busy − mean_idle)
u_count = u(W) / W
u_meas  = sqrt(u_power² + u_count²)                relative to E
F       = round(E)                                 the figure sealed, in µJ
u_rel   = sqrt((E · u_meas)² + (0.5/√3 µJ)²) / F   declared, relative to F

u_meas is relative to the estimate and u_rel to the figure a reader sees. The measurement’s part is carried across in microjoules, so a figure that rounds down declares it relative to the smaller number. At E = 0.563 µJ with u_meas = 1.54 %, F is 1 and u_rel is 28.9 %, not 1.54 %.

• u_power is the statistical (Type A) standard uncertainty of the marginal draw, with s the sample standard deviation of each bracket. It cannot be evaluated from fewer than two samples in either bracket, or without a positive marginal draw.

• u_count is the completion-count term. C is the number of reconstructions counted as completing inside the window, and N is the number that can be in progress at once — the worker count. The count is exact as a count; it is not exact as a measure of the work the window’s energy paid for, because reconstructions part-done at an edge are invisible to it. What that error can be depends on how the window opened:

  window opened	work W lies in	estimate W	u(W)	u_count
  from rest — every worker held at a start barrier and released as the window opens	[C, C + N)	C + N/2	N / (2√3)	N / (√3 · (2C + N))
  on running workers — the workers’ progress at the opening edge spread over a whole reconstruction	(C − N, C + N)	C	N / √3	N / (√3 · C)

  From rest, no reconstruction begins before the window, so only the closing edge contributes: each worker is part-way through one reconstruction the count cannot see, and the count reads low, never high. On running workers both edges contribute, in opposite directions. In both cases, with only the limit known, the error is taken as rectangular over it (GUM §4.3.7). From rest, that is exact when the workers’ progress at the closing edge moves together and falls anywhere in a reconstruction with equal likelihood — identical payloads released together do move together — and conservative when their progress is spread. On running workers it is conservative in both cases.

  A window that opens the moment the workers are started, without a barrier, is in neither row. When a reconstruction takes much longer than starting the workers, they are all near the start of one at the opening edge, so the count reads low by up to N — by about N/2 on average — and a figure divided by C reads high by about N / (2C): 8 % at ten workers and sixty completions. The symmetric running-window model does not describe it. The reference meters were built this way until this revision; their windows now open from rest.

  The term shrinks only as C grows, so it is large when an expensive payload completes only a handful of times (§3). An implementation MUST state which opening it used; a measurement report states it in its bracket’s opening (§6). An implementation that removes more of this term by construction MUST state how, and MUST still declare whatever part it has not removed.

• The window is timed on a monotonic clock around the busy bracket. An implementation whose clock resolution is not negligible against the window MUST include it.

A figure whose u_rel cannot be evaluated — too few samples, no positive marginal draw, no completions, or an estimate that rounds to zero (§4) — MUST NOT be sealed under a hardware class. W is the divisor of the published per-unit figure; the raw count C is reported beside it (§3).

The declared uncertainty does not absorb the attribution bias of §4. That bias is one-directional — a busy machine always reads low — and no symmetric uncertainty describes it. (The completion-count bias of a window opened without a barrier, above, runs the other way: it reads high.) The §4 ratio remains required alongside the declaration, and a figure that fails §4 is not rescued by a large declared uncertainty.

2.4 Counter filtering state (OnChipCounter)

Some on-chip counters filter their output as a side-channel defence. The technical guidance published with advisory INTEL-SA-00389 (Running Average Power Limit Energy Reporting, CVE-2020-8694, CVE-2020-8695) describes RAPL energy filtering: noise added to the energy reported, typically under 2 % standard deviation in readings at 1 s intervals, growing to 5–15 % at 100 ms, with larger variance possible at thermal design power. Filtered energy is reported when SGX is enabled or system software has enabled filtering (on some implementations the processor sets it during boot to protect SGX), and TDX uses the filtered energy information. Software that can read model-specific registers sees it as IA32_MISC_PACKAGE_CTLS[0] (ENERGY_FILTERING_ENABLE), supported where IA32_ARCH_CAPABILITIES[11] is set; once set, that bit cannot be cleared by software.

So an OnChipCounter class carries the filtering state as one of:

• An implementation MUST report Off only on positive evidence. A reader that cannot see the control state — an unprivileged process, an interface that does not expose it — MUST report Unknown, never infer Off from absence.
• A verifier MUST read Unknown as possibly filtered.
• Where the state is On or Unknown, the declared uncertainty (§2.3) SHOULD include the noise the vendor states for the declared window.
• A CalibratedInstrument class carries no filtering state: an external instrument has no counter filter.

2.5 Calibration reference (CalibratedInstrument)

A CalibratedInstrument class MUST carry calibration_ref: a non-empty identifier that resolves to the calibration certificate covering the instrument as used — a URI, or the issuing laboratory’s certificate number.

The reference makes the calibration claim checkable, not true. A verifier holding it can obtain the certificate and confirm that it covers the instrument, that it was current when the figure was measured, and that the declared uncertainty is consistent with it. The receipt’s signature proves who made the claim. It says nothing about the instrument.

2.6 Legacy HwShunt

Receipts sealed before this revision carry HwShunt. Its meaning is fixed as hardware, sub-class unspecified, no declared uncertainty.

• A verifier MUST accept HwShunt in a receipt that is otherwise valid. The signed encoding of §2.7 leaves every legacy receipt’s signed bytes unchanged, so such a receipt verifies exactly as it did.
• A verifier MUST rank HwShunt below both refined hardware classes. It asserts a hardware reading and nothing about the reading’s uncertainty.
• An implementation MUST NOT emit HwShunt in a new receipt. A producer that cannot say which kind of hardware evidence it has, or cannot declare an uncertainty for it, has not established what the refined classes require. A verifier cannot see when a receipt defined with a class from the start was sealed, so it accepts HwShunt there as above. The reference implementation meets the rule in its own producers, none of which emits HwShunt, and holds its callers to it in part: its meters cannot produce HwShunt, a new energy binding, an optional label (§2.8), the label of a JWP object’s leaf or group, and an energy, measurement or operating-point claim (jwp-receipts §2.4.5, §2.4.8–§2.4.9) refuse it, and the wai-rs variant is deprecated, so code that names it draws a compiler warning. The constructors of the wai.video.int_motion receipt and the wai.video.* OTT receipts accept HwShunt, so that an issued receipt can be recreated byte for byte, and nothing in them refuses it. The warning reaches only code that names the variant. A class parsed from its label (EnergyProvenance::from_label, from_parts) can be HwShunt, as a verifier needs, and a caller that passes such a class to those constructors draws no warning.
• HwShunt carries no evidence fields. A receipt pairing HwShunt with a declared uncertainty, a filtering state or a calibration reference is ambiguous and MUST be rejected.

2.7 Signed encoding

Receipts that sign a binary payload encode the class as one tag byte, followed by the class’s evidence:

Tags 0–3 are followed by nothing, exactly as before the hardware class was refined; that is what keeps legacy receipts verifying without re-signing.

Receipts carried as JSON carry the same evidence as named fields beside the class label, and omit them for the classes that carry none, so a legacy body is byte-identical to one written before this revision. The names are fixed:

The snake_case carriers are the rendered wai.video.int_motion receipt, every receipt carrying an optional label (§2.8), and the body of an energy claim (jwp-receipts §2.4.5); in a labelled bill of materials the fields sit inside each labelled entry. A claim has no optional members and no legacy form, so an energy claim writes the fields a class does not carry as null rather than omitting them, and writes an OnChipCounter’s filtering state even when it is Unknown. Every snake_case field is energy_-prefixed so that it cannot collide with a field a receipt already renders — a quantum job receipt’s calibration_ref names the calibration receipt the job ran under, not a certificate. A reader MUST refuse evidence fields that appear without a class label, and MUST NOT drop a malformed label and read the receipt as unlabelled.

2.8 Optional labels on receipts that predate the class

A receipt family that sealed joules_micro before this extension existed has issued receipts that must keep verifying. Such a family carries the class as an optional label:

• Absent. The signing payload, the receipt’s identity hash and its JSON are exactly the legacy ones. The figure is unlabelled: a verifier MUST accept the receipt if it is otherwise valid, and MUST NOT read the figure as any class. An unlabelled figure is not comparable with any labelled one; it is not upgraded to one, and in particular not to HwShunt.
• Present. The signing domain’s final version byte, 0x01 in every such family (e.g. wai:world-receipt\x01), becomes 0x02, and the class’s signed encoding (§2.7) follows the joules_micro field it labels, before the fields that followed the figure in the legacy payload. The version byte keeps every labelled payload distinct from every unlabelled one, so a label can be neither added to nor stripped from a signed receipt; the encoding is self-delimiting, so the fields after it keep their legacy framing. A receipt whose identity hash covers its signing payload covers the label with it.
• A label MUST NOT be HwShunt — none of these receipts ever carried it — and MUST NOT sit beside a zero figure. A verifier MUST treat either, or a refined class without its evidence, as invalid.
• New receipts. A producer SHOULD label every non-zero figure it seals in such a family. The unlabelled form exists for receipts issued before the label did, and an unlabelled figure tells a reader nothing about how it was obtained. This is a recommendation, not a conformance requirement. No verifier can check it: a figure sealed unlabelled today has exactly the bytes of one sealed before the label existed, and a verifier accepts both (above). That does not set it apart from §2.6’s rule on HwShunt, which no verifier can check in a receipt defined with a class from the start either. What sets it apart is that the reference implementation neither meets it in all its own producers nor holds its callers to it. Two of its producers seal new non-zero figures without a label (end of this section). In these families no constructor takes the class. build() and seal() in wai-rs, and seal() and the helpers that call it in wai-quantum, seal the figure unlabelled, and a label is added afterwards, by re-signing (below). A provenance step is labelled before its receipt is built instead: ProvStep::new makes the step unlabelled, and ProvStep::with_energy_class labels it. None of these refuses a non-zero figure without a label, and none of the unlabelled paths is deprecated. A library can hold its callers to this rule by the means §2.6 describes for HwShunt. It would need a constructor that takes the class and refuses a non-zero figure without one, and it would keep the unlabelled path only for recreating issued receipts, deprecated, so that code sealing a new unlabelled figure draws a compiler warning. The reference implementation has not done this.

Where a receipt carries several figures, each is labelled where it sits:

• A provenance receipt labels each step. A labelled step’s leaf hash uses the 0x02 step domain with the class after the step’s figure; an unlabelled step keeps its legacy leaf. A receipt with any labelled step signs under the 0x02 receipt domain and writes, after every step’s figure, that step’s optional class — 0 for an unlabelled step.
• A quantum bill of materials labels each entry the same way: under the 0x02 domain, every entry’s figure is followed by its optional class, 0 when unlabelled. An entry’s class restates its stage receipt’s class, and a verifier binding the bill to its stage receipts checks that they agree.
• A JWP group receipt labels each object in that object’s Merkle leaf (jwp-receipts §2.2). A labelled object’s leaf uses the 0x02 leaf domain, with the figure, its class and the object’s origin after the content hash; an unlabelled object keeps its legacy leaf. Its group may sign the total’s own class under the 0x02 group-signing domain (§1).

A provenance or quantum bill total carries no class of its own, and neither does a JWP group total in the legacy payload. A sum over figures of different classes is only as strong as its weakest part, and an unmetered part is not a zero. A reader that holds every part reads such a total as follows:

• if every part’s figure is the unmetered marker, the total is unmetered;
• otherwise, if any non-zero figure is unlabelled, the total is unlabelled;
• otherwise the total reads at the weakest class among the non-zero figures, in §2’s order, as a class name only. A total read this way carries no declared uncertainty and MUST NOT be presented as carrying one. It covers the whole of the work when no part is unmetered, and only the measured parts otherwise (energy-binding §4’s Whole and Partial).

A reader that does not hold every part reads such a total as unlabelled. A JWP group total in the labelled payload carries its own class instead, composed by jwp-receipts §2.4.1’s rule, which adds a declared uncertainty for a hardware class: the parts’ figure-weighted declarations, rounded up, over the longest window — linear in the parts, so it assumes their errors fully correlated.

In the reference implementation, each wai-rs family has an energy_provenance field and with_energy_class(), which re-signs with the receipt’s own key; provenance steps have ProvStep::with_energy_class(). wai-quantum, a published crate, adds the label without changing any existing type: quantum_energy::Labelled<R> wraps a sealed receipt and re-signs it over the labelled payload, and quantum_energy::LabelledQbom labels a bill per entry. A labelled quantum receipt fails the inner receipt’s own verify() — its signature covers the labelled payload — so a reader that does not know about labels refuses it rather than silently dropping the class. A verifier that accepts both forms parses with quantum_energy::MaybeLabelled, which takes the form from the JSON and refuses a malformed label rather than reading the receipt as unlabelled. The reference wai-quantum verify CLI and the HTTP handler’s POST /verify accept both forms this way. A job receipt names its calibration by the identity of the form the calibration is in, and MaybeLabelled::verify_against_calibration checks the link for either form of each. Tests pin one unlabelled receipt of every family to the bytes it had before the label existed.

What the reference implementation seals in these families:

• The reference meters that seal into them (wai_meter, wai_world_meter, wai_quantum_meter, wai_prov) label every non-zero figure they seal, write a measurement report (§6) for it by default, and seal a figure they could not measure with the unmetered marker, unlabelled.
• Two producers seal a new non-zero figure without a label, and so fall short of the SHOULD above. world_model::frame_receipt is handed its caller’s figures without their class; a caller that knows the class builds the steps itself with ProvStep::with_energy_class. The in-browser demos of wai-web seal illustrative figures, fixed in code or passed in by the page.
• A generator that recreates a committed conformance corpus byte for byte seals that corpus’s figures unlabelled; wai_quantum_ops_vectors gen seals non-zero ones. Every committed corpus predates the label, so these generators recreate issued receipts, which is what the unlabelled form is for.
• The constructors and sealing helpers above are not counted. Each returns its receipt, or its provenance step, to a caller that can still label it.

2.9 IOReport, and where this departs from other documents

IOReport — the SoC energy interface the reference meters read through a non-privileged reader — is classed OnChipCounter. Its readings are the measured silicon’s own report of its energy, and this extension classes a figure by that provenance. The interface’s channels sit in a group named “Energy Model”, and it is a private interface whose derivation is not publicly documented. That makes the counter’s systematic error unstated, which an OnChipCounter declaration already excludes (§2.3). It does not make the figure a model this implementation computed (ModelBased) or a constant (Estimator).

Other documents in this repository class IOReport differently. This extension does not change them; where a figure passes between the two, the weaker class applies (§2):

The documents that class IOReport as hardware agree with this section at the three-name level: sandbox/README.md, proof/README.md, joule-code/spec/receipt.md (HwShunt), and the eoc-meter crate (“measured-grade”). jcp/jcp-rs/crates/jcp-efficiency/MAPPING.md states the same position in prose: vendor counters are real sensor readings, whose derivation and error bounds are undisclosed.

3. The reference protocol: bracketed marginal measurement

On-die energy counters report the draw of a whole package or SoC, not of one process. A decode cannot be isolated on such an interface, so the reference protocol measures the marginal draw the work adds to an otherwise-idle machine:

1. Idle bracket. Sample power for a fixed count with no work running. Record the mean and the standard deviation.
2. Saturating burst. Run the reconstruction continuously on N threads, counting completions. Many threads are used deliberately: a single-threaded burst on a modern SoC often fails to lift total draw clear of idle drift. The threads SHOULD be held at a start barrier and released as the window opens, so the window opens from rest (§2.3).
3. Busy bracket. Sample power again for a fixed count while the burst runs, recording the wall-clock window it spans and the standard deviation.
4. Attribute. energy = max(0, mean_busy − mean_idle) × window, then divide by the work the window paid for — C + N/2 from rest, C on running workers (§2.3).

Per-unit energy is total marginal energy ÷ the work it paid for, so the thread count enters the figure only through the part-done reconstructions at the window’s edges, which the count cannot see. It enters the figure’s uncertainty the same way (§2.3, u_count). Completions MUST be counted per reconstruction, not per fixed-size batch: a cheap payload runs millions of times and an expensive one a handful, and a coarse batch collapses the count. For the same reason an expensive payload SHOULD be burst over a window long enough that its completions far outnumber the threads. With a handful of completions the count term alone is large: ten threads and sixty completions give about 9.6 %.

An implementation MUST report the idle mean and standard deviation, the busy mean and standard deviation (sample standard deviations, as §2.3 uses), the sample counts, the window, the completion count, the thread count and how the window opened alongside any figure it publishes. Those numbers are what make a figure auditable, and they are what its declared uncertainty (§2.3) is computed from; the figure alone is not auditable. Where the figure is sealed in a receipt, they are published as §6 says.

3.1 A live power reader

A power reader can return values for a rail that is not being refreshed. A frozen rail reads as zero in every sample, or as the last value the reader holds; a rail refreshed in batches reads the same value except where one batch lands, and one refresh can be published in two steps in adjacent samples. Bracketed, either gives an idle bracket whose samples are all equal and a busy bracket with a lump or a step in it: a flat idle, a positive marginal, and a ratio (§4) that reads as clean — from no measurement of the work at all.

So a figure is sealed under a hardware class only from brackets in which the reader’s rail was live. A rail is live in a bracket only if:

• it advanced in two consecutive intervals;
• it advanced in at least five intervals, and in at least four of every five of the bracket’s intervals; and
• the bracket spans at least 300 ms.

An interval is one sample of a power reader, in which the rail advanced if the sample is strictly above zero and differs from the sample before it (the first sample of a bracket has none before it, and advanced if it is above zero); or one pair of successive reads of an energy counter, in which it advanced if the second read exceeds the first, across the counter’s wrap. A reader that holds its last value repeats it, and a repeated value is not an advance, whatever the value. Both brackets must be live. One advance is not a live rail, and neither is one refresh published in two steps. An implementation reading a counter at the ends of a span alone has one interval, which is never enough: it reads the counter during the span as well.

A figure from a bracket that is not live MUST NOT be sealed under a hardware class. The producer seals it with the unmetered marker, or under a weaker class it can justify. A measurement report carries each bracket’s liveness facts — its live intervals and its longest run of them (§6.2) — so a verifier checks the first two conditions from the report; the span is the producer’s to check.

A bracket whose samples are all equal is not evidence of a quiet machine, and never of a live rail: its samples advanced once at most. Its standard deviation is zero, and under a hardware class a reader refuses a bracket whose sd_uw is 0 whatever liveness facts it carries.

4. Attribution quality (REQUIRED)

The marginal method is only meaningful when the burst lifts power clearly above the machine’s own idle fluctuation. When it does not, the method does not degrade gracefully — it returns a confidently-formatted number that is far too low, because an inflated idle baseline is subtracted from a busy mean that never rose.

This is not a theoretical concern. Measuring one fixed clip with one binary, minutes apart on the same machine:

A 21× error, in the flattering direction, with nothing in the output to distinguish the two.

So an implementation MUST compute the ratio of the marginal draw to the idle standard deviation and report it. A measurement report reports it by carrying the values it follows from, and every reader derives the same verdict from them (§6.2):

The publication bar is 10, not 3, and that is an empirical result rather than a round number. A later reading of the same clip at a ratio of 3.8 — inside what an earlier draft of this rule called “usable” — reported 2,469 µJ against the 10,565 µJ above: a 4.3× disagreement from a reading the rule had passed. A ratio in the 3–10 band is sound for comparing two workloads measured back-to-back on one machine, because the bias applies to both. It is not sound for an absolute figure.

The bias has a direction. A busy machine inflates the idle baseline, which is then subtracted from a busy mean that never rose as far, so a poor bracket always reads low. An implementation reporting energy therefore errs toward flattering itself, which is precisely why the check must be automatic rather than left to the operator’s judgement.

• An implementation MUST NOT seal a figure under a hardware class (CalibratedInstrument, OnChipCounter) when the reader’s rail was not live (§3.1), when the ratio is below 1, or when the per-unit figure rounds to zero. None is a measurement of low energy; each is a failure to measure, and the receipt MUST be emitted unmetered instead.
• An implementation MUST NOT publish an absolute figure taken below a ratio of 10, and SHOULD warn whenever it produces one.
• A reader MUST NOT present a figure as publishable unless the verdict its measurement report gives is clean (§6.2). A reader holding no report for a figure cannot tell whether the figure met this bar, and MUST NOT say that it did.

Emitting an unmetered receipt is the correct outcome of a failed measurement, not an error state. A tool that says “I did not measure this” is more useful than one that says “this decode cost 267 µJ” when the true figure is forty times higher.

5. What the figure is, and is not

• It is machine-specific. The same codestream on different silicon legitimately measures differently. Energy is a property of an execution, not of an artifact.
• It is a marginal figure over an idle baseline, so it excludes the fixed cost of having a machine powered on, and attributes shared platform overhead to the work only insofar as the work raised it.
• It is scoped to what the interface reports — a package or an SoC, not a process. Provenance and scope are the honest limitations, not sensor accuracy.
• It depends on the build. A debug build of the reference decoder measured 4.9× a release build of the same code. An implementation MUST state the build profile alongside any published figure; a measurement report states it in build (§6).
• It is not verifiable by re-execution. A third party re-running the decode reproduces the result and the work, never the joules.

That last point is the reason the receipt profiles are shaped as they are. Where a class’s reconstruction is byte-exact and proven across architectures, a verifier holding the artifact re-derives the output and the work unit. It cannot re-measure the energy, and it cannot re-measure anything that describes how the energy was obtained: the acquisition class and its evidence (§2.2–§2.5), the bracket values of §3 and their liveness facts (§3.1), the ratio they give (§4), the build profile, and the coverage and method a receipt states beside the figure. Those are the measurer’s statements, as the figure is, and a signature makes them attributable, not true.

Some of them can still be checked without re-measuring anything: a declaration against the resolution floor (§2.3), which needs nothing but the receipt; a calibration reference against the certificate it names (§2.5); and a measurement report’s values against the figure and the declared uncertainty they must give, and against the liveness rule (§6.2). Values that pass those checks are consistent, not correct: a measurer who invents every value consistently passes every one of them. Pairing a meter with a reproducible outcome narrows what rests on the measurer to the measurement and its description. So an implementation SHOULD report energy against a work unit that a verifier can recompute from the artifact, and MUST NOT report it against a work unit only the producer can compute.

6. Reporting contract

A published figure MUST be accompanied by: the acquisition class (§2), with its declared uncertainty and window (§2.3) and its filtering state (§2.4) or calibration reference (§2.5); the build profile (§5); the recomputable work unit the rate is expressed against; and, for a figure obtained under the protocol of §3, the idle mean and standard deviation, the busy mean and standard deviation, the sample counts, each bracket’s liveness facts (§3.1), the window, the completion count, the thread count and how the window opened. The attribution-quality ratio (§4) follows from those values (§6.2).

Where a figure is sealed in a receipt with a class, its producer MUST publish these, except the work unit, which the receipt carries, as a measurement claim about the figure (jwp-receipts §2.4.8). The claim names the figure by its figure profile (§6.1), restates it with its class, and leaves the receipt that seals it unchanged. Only the key that signed the figure may sign the claim, so a figure that no Ed25519 key signs — an energy binding’s (§6.1) — has no measurement claim; carrying a binding’s report in its C2PA manifest is outside this revision. A report printed beside a receipt but not signed does not meet this section. No verifier can tell a figure whose report was withheld from one that never had one, so this rule binds producers, and what a verifier checks is a report it holds (§6.2).

Producers that fall short of this section, recorded rather than exempted: the generators that recreate a committed corpus with its unlabelled legacy figures (§2.8); world_model::frame_receipt, which is handed its caller’s figures without their class or their bracket; and the in-browser demos of wai-web, which seal illustrative figures. A figure sealed with no class cannot meet this section, because a measurement claim restates a class.

A figure published without these is not wrong so much as unusable: nothing about it can be checked, reproduced, or compared.

6.1 Figure profiles

A report about a figure (jwp-receipts §2.4.8–§2.4.9) names it by a figure profile, an index, and the identity of the receipt that carries the figure. A profile is named by the domain its receipt’s identity is computed under, without the domain’s final version byte. It fixes the claim’s subject_type, how the identity is computed, which figure an index selects, where the figure’s class is, and which key signed it.

A receipt hash here is BLAKE3(identity domain ‖ signing payload ‖ signature), as each family defines it. One content hash can be delivered in more than one group, so a moq-jwp:object report also names the group, and the same object in another group is another figure. A claim naming a profile not in this table is refused (jwp-receipts §3.1, figure_unknown_profile). A receipt family that seals a figure after this revision adds its row.

6.2 The measurement report

A measurement report (jwp-receipts §2.4.8) carries a figure’s §3 values as integers:

• each bracket’s sample count n; its mean, in microwatts, rounded to the nearest with a half rounding up; its sample standard deviation (divisor n − 1, as §2.3 uses), in microwatts, rounded up, so a sealed dispersion never states less than was evaluated; and its liveness facts (§3.1): the samples in which the reader’s rail advanced, and the longest run of consecutive ones;
• the window T, the busy bracket’s, in microseconds rounded to the nearest: the window_us of the figure’s declared uncertainty (§2.3);
• the completion count C, the thread count N, and how the window opened.

A producer MUST compute the figure it seals, and the least uncertainty it declares, from those integers as below and not from the samples they summarise, so that every verifier reproduces both exactly.

Let M be the busy mean less the idle mean, and let the work the window paid for (§2.3) be Wn / Wd: Wn = 2C + N and Wd = 2 for a window opened from rest, Wn = C and Wd = 1 on running workers. The per-unit estimate is E = M·T·Wd / (10⁶·Wn) µJ, and the figure is E rounded to the nearest microjoule, a half rounding up:

F = ⌊(2·M·T·Wd + 10⁶·Wn) / (2·10⁶·Wn)⌋

With n_i, s_i the idle bracket’s count and standard deviation and n_b, s_b the busy bracket’s, §2.3’s u_rel over those integers, multiplied out, is the least integer p for which:

p² · K ≥ P,   where
K = 12 · n_i · n_b · Wn⁴ · F²
P = 12 · Wn² · T² · Wd² · (s_i² · n_b + s_b² · n_i)
  +  4 · n_i · n_b · M² · T² · Wd² · N²
  + 10¹² · n_i · n_b · Wn⁴

The three terms of P are u_power, u_count and the 0.5/√3 µJ of rounding, each carried across in microjoules (u_count is N / (√3 · Wn) from rest and on running workers alike). The least p always meets the resolution floor of §2.3, F · p ≥ 288 676. Both computations are exact integer arithmetic. With every value at most 2⁵³ − 1 (jwp-receipts §2.4.3), no product exceeds 2⁵¹² and no floating-point operation is involved, so every verifier reaches the same F and p.

A figure sealed under OnChipCounter or CalibratedInstrument MUST come from brackets whose rail was live (§3.1), and MUST declare a relative_ppm of at least p over window_us = T. It declares more wherever its declaration covers more than the bracket does: an instrument’s calibration (§2.3), the noise a filtered counter’s vendor states (§2.4), or a clock resolution that is not negligible (§2.3). A figure whose p exceeds 2³² − 1 cannot be declared (§2.7) and MUST NOT be sealed under a hardware class.

The attribution-quality ratio (§4) is M / s_i. Every reader derives the same verdict from the report’s values: clean when M ≥ 10 · s_i, usable for relative comparison when M ≥ 3 · s_i, noisy when M ≥ s_i, and unusable otherwise. The verdict is about the bracket’s arithmetic; under a hardware class a report is accepted only where the liveness facts also show the rail live and neither bracket’s sd_uw is zero, so a flat idle bracket from a frozen rail, or from a reader holding a stale value, is refused, not read as clean.

What a verifier checks with a report is arithmetic: that the figure is the one its values give, that the declared uncertainty is at least what they support, and, under a hardware class, that the rail was live and the ratio is at least 1 (jwp-receipts §2.4.8). It does not check the values, which cannot be re-measured (§5).

7. Worked example

wai.video.int_motion, real-footage vector, 8 frames of 96×96 RGB, release build, IOReport via a non-privileged reader:

work                : 221,184 subpixel-ops (8 x 96 x 96 x 3, recomputable)
cpu power  idle     : 24.95 W  (sd 0.23 W, 10 samples)
cpu power  busy     : 25.84 W  (14 samples)
marginal (busy-idle): 0.89 W
decodes             : 1,525 over 4.23 s
marginal / idle sd  : 3.8x  (usable for relative comparison — NOT publishable)
-> per decode        : 2,468.8 uJ
-> per kilo-subpixel : 11.16 uJ
acquisition class   : HwShunt

The run above predates the refinement of §2.2–§2.6, and its receipt says HwShunt. The reference meter now emits OnChipCounter for the same interface, with filtering state Unknown (a non-privileged IOReport reader has no documented way to read a filtering state, if the interface has one) and the §2.3 uncertainty: the statistics of both brackets combined with the completion-count term and the 0.5/√3 µJ that rounding the figure to whole microjoules adds. It also opens its window from rest and divides by C + N/2; the run above opened on freshly started workers and divided by C, so its per-decode figure also carries the high-reading count bias of §2.3. None of this can be reconstructed for that run: neither the busy bracket’s standard deviation nor the thread count was recorded, and substituting either would be the invention this section refuses. The reference meter now also publishes these values, with the build profile, in a measurement report (§6). The run above printed them to its console, and its report cannot be written after the fact.

This example is deliberately a failing one. It is a complete, honestly reported bracket that this extension nonetheless forbids publishing as an absolute figure, because 3.8 is below the bar of §4 — and the earlier reading of the same clip on a quieter machine differed by 4.3×. It is shown rather than a clean bracket because a clean bracket is not currently reproducible on the authoring machine, and substituting an invented one would be the exact failure this document exists to prevent. An implementation quoting a figure for this vector MUST first obtain a bracket at ≥ 10.

The receipt seals the codestream hash, the per-frame decoded-pixel hashes, the work figure, the energy and its class under one signature. A verifier re-derives the codestream hash, the frame hashes and the work figure from the codestream alone. The energy, its class and the class’s evidence rest on the signer (§5); a report about the figure lets a verifier check that they are consistent with the bracket, and no more (§6.2).

8. Reproducing a figure

An implementation claiming conformance SHOULD publish, with any figure: the vector decoded, the build profile and toolchain, the reader used for the power interface, the bracket parameters of §3, and the declared uncertainty with the evidence of §2.3–§2.5. A figure whose bracket is not published cannot be reproduced, and an unreproducible energy number is an assertion, not a measurement — which is the failure this extension exists to prevent. A measurement report (§6) publishes, signed, the build profile, the toolchain and target, the power reader and the bracket with its liveness facts, in cleartext: the measuring machine’s power levels and build environment are visible to whoever holds the report.