258fd918ec
edge-conformance/edge_verify.py verifies the corpus from the extension's text alone: it reads receipts and writes stills itself, re-executes every replicate hop, requires every mutated copy of the corpus to fail and the corpus to catch it with each of its own checks dropped. Two controls are added so that every one of its checks is caught (a JPEG output naming no encoder, a grid stated over more inputs than its cells). The registry lists wai.edge.derivation and the document kind wai-derivation; jwp-receipts §4.2 and §7.5 register what an edge may do and its authority edge/derive; derived-tracks and energy-measurement say where the receipt and the group receipts now come from. Co-Authored-By: Claude Opus 5.5 <[email protected]>
1089 lines
67 KiB
Markdown
1089 lines
67 KiB
Markdown
# WAI Extension: Energy Measurement
|
||
|
||
> 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`](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](moq-streaming-format.md) §5); and the JWP group and
|
||
object receipts ([jwp-receipts](jwp-receipts.md) §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](oer-receipts.md)) 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](oer-receipts.md) §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](jwp-receipts.md) §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](moq-streaming-format.md)
|
||
§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](jwp-receipts.md) §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](jwp-receipts.md) §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.
|
||
|
||
| class | meaning | requires |
|
||
|---|---|---|
|
||
| `CalibratedInstrument` | Read from an instrument external to the measured device — a shunt, a power analyser, a metering socket — that holds a current calibration covering the range and conditions it was used in. | a present, non-zero measurement; a declared uncertainty (§2.3); a calibration reference (§2.5) |
|
||
| `OnChipCounter` | Read from an energy counter the measured silicon keeps about itself — RAPL, NVML, SMC, IOReport (§2.9) — or from any other instrument whose uncertainty is not traceable to a current calibration (§2.2). | a present, non-zero measurement; a declared uncertainty (§2.3); the counter's filtering state (§2.4) |
|
||
| `ModelBased` | Computed from a model calibrated on the host it describes (e.g. wall time × an active power measured on that host). A real number, honestly labelled as derived. A constant nobody calibrated there — a nominal TDP, a typical draw — is `Estimator`, however it is multiplied. | — |
|
||
| `Estimator` | A coarse constant or load estimator. | — |
|
||
| `HwShunt` *(legacy)* | Read from a hardware energy interface, sub-class unspecified, no uncertainty declared. Accepted in receipts sealed before the hardware class was refined; never emitted (§2.6). | a present, non-zero measurement |
|
||
|
||
`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](oer-receipts.md) §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](energy-binding.md)), the `wai.video.int_motion` receipt,
|
||
the `wai.video.*` OTT receipts, and the `energy` claim
|
||
([jwp-receipts](jwp-receipts.md) §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 writes a
|
||
`WAI_RECEIPT` property, and `wai-quantum` seals no JWP group receipt; `wai-rs`
|
||
builds them for its conformance corpus and for the objects its reference
|
||
deriving edge publishes ([deriving-edge](deriving-edge.md) §6), whose object
|
||
receipts it labels, the unmetered marker included.
|
||
|
||
### 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](jwp-receipts.md) §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:
|
||
|
||
| field | meaning |
|
||
|---|---|
|
||
| `relative_ppm` | The **standard** relative uncertainty of the figure (coverage factor k = 1, in the sense of the GUM, JCGM 100:2008), in integer parts per million of the figure. An expanded uncertainty `U` stated at coverage factor `k` — the usual form on a calibration certificate — is declared as `U / k`. |
|
||
| `window_us` | The integration window the figure was accumulated over, in integer microseconds. For the protocol of §3, the busy bracket's window. |
|
||
|
||
- 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:
|
||
|
||
| state | meaning |
|
||
|---|---|
|
||
| `On` | The reader determined that filtering was active. |
|
||
| `Off` | The reader positively determined that no filtering was active. |
|
||
| `Unknown` | The reader could not determine the state. |
|
||
|
||
- 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](jwp-receipts.md) §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:
|
||
|
||
| tag | class | followed by |
|
||
|---|---|---|
|
||
| `0` | no class: the unmetered marker beside a zero figure; in a receipt family of §2.8, the slot of an unlabelled legacy figure beside a non-zero one | — |
|
||
| `1` | `HwShunt` (legacy) | — |
|
||
| `2` | `ModelBased` | — |
|
||
| `3` | `Estimator` | — |
|
||
| `4` | `OnChipCounter` | `relative_ppm` u32 BE · `window_us` u64 BE · filtering u8 (`0` Unknown, `1` Off, `2` On) |
|
||
| `5` | `CalibratedInstrument` | `relative_ppm` u32 BE · `window_us` u64 BE · reference length u32 BE · `calibration_ref` UTF-8 |
|
||
|
||
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:
|
||
|
||
| field | snake_case carriers | C2PA companion assertion (camelCase) |
|
||
|---|---|---|
|
||
| class label | `energy_provenance` | `acquisition` |
|
||
| declared uncertainty | `energy_uncertainty` `{relative_ppm, window_us}` | `uncertainty` `{relativePpm, windowUs}` |
|
||
| filtering state | `energy_counter_filtering` | `counterFiltering` |
|
||
| calibration reference | `energy_calibration_ref` | `calibrationRef` |
|
||
|
||
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](jwp-receipts.md) §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](jwp-receipts.md) §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](energy-binding.md) §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):
|
||
|
||
| document | classes IOReport as |
|
||
|---|---|
|
||
| `jouleclaw/SPEC.md` (provenance table; realistic floors) | `ModelBased` — "vendor-provided estimate", "model-based, not measured" |
|
||
| `jouleclaw/jouleclaw-rs/crates/jouleclaw-energy/src/lib.rs` (the `ModelBased` variant's examples) and `src/apple_ioreport.rs` | `ModelBased` — a vendor model derived from frequency, voltage and utilisation |
|
||
| `jouleclaw/jouleclaw-rs/crates/jouleclaw-energy/MEASURED_ENERGY.md`, `conformance/README.md` | `ModelBased` |
|
||
| `jouleclaw/jouleclaw-rs/crates/jouleclaw-jcr1/conformance/README.md`, `vectors.json` | `ModelBased` |
|
||
| `jouleclaw/jouleclaw-rs/crates/jouleclaw-compliance/src/passport.rs` (`MeasurementMethod::IoReport`) | `Estimator`, pending an in-process reader |
|
||
| `jcp/jcp-rs/crates/jcp-energy/src/lib.rs` (`Meter::IoReport`) | `ModelBased` — a real on-die reading, carried at model grade |
|
||
| `joule-code/examples/l3-jouleclaw/src/bin/run.rs` (and its README, which describes the host as `Estimator` until IOReport is wired) | `ModelBased` |
|
||
|
||
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:
|
||
|
||
| condition | idle | busy | marginal | reported |
|
||
|---|---|---|---|---|
|
||
| quiet | 20.45 W | 54.89 W | 34.45 W | **10,565 µJ/decode** |
|
||
| *(the quiet row predates this rule, so its ratio was not recorded)* | | | | |
|
||
| build running | ~23.9 W | 24.26 W | 0.36 W | **497 µJ/decode** |
|
||
|
||
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):
|
||
|
||
| ratio | verdict |
|
||
|---|---|
|
||
| ≥ 10 | clean — publishable |
|
||
| ≥ 3 | usable for relative comparison — **not** publishable |
|
||
| ≥ 1 | **noisy — do not publish** |
|
||
| < 1 | **unusable — the machine was not idle** |
|
||
|
||
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](jwp-receipts.md) §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](jwp-receipts.md) §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.
|
||
|
||
| figure profile | receipt | `subject_type` and identity | figure; its class | index | signed by |
|
||
|---|---|---|---|---|---|
|
||
| `moq-jwp:object` | JWP object receipt (jwp-receipts §2.4.2), accepted under its group (§3) | `object`: its §2.1 content hash; the claim's `group` is the group receipt's link hash | `joules_micro`; the label in its leaf (jwp-receipts §2.2) | its leaf index | the group receipt's `signer_pubkey` |
|
||
| `moq-jwp:claim-link` | `energy` claim (jwp-receipts §2.4.5), or `reconstruct-session` claim whose `energy` is not `null` (§2.4.12) | `receipt`: its `link_hash` | `joules_micro`; its class (for a session, `energy.joules_micro` and the class `energy` writes) | `null` | its `signer_pubkey` |
|
||
| `wai:energy-binding-id` | energy binding ([energy-binding](energy-binding.md) §2) | `receipt`: `BLAKE3("wai:energy-binding-id\x01" ‖ JCS(body))` (energy-binding §4) | `microjoules`; `acquisition` | `null` | no Ed25519 key |
|
||
| `wai:video-receipt-id`, `wai:video-manifest-receipt-id`, `wai:video-ssai-receipt-id`, `wai:video-keys-receipt-id`, `wai:video-package-receipt-id`, `wai:video-channel-receipt-id` | the `wai.video.int_motion` receipt and the `wai.video.*` OTT receipts | `receipt`: its receipt hash | `joules_micro`; its class | `null` | its `signer_pubkey` |
|
||
| `wai:world-receipt-id`, `wai:film-receipt-id`, `wai:haptic-receipt-id`, `wai:score-receipt-id`, `wai:splat4d-receipt-id`, `wai:audio-receipt-id`, `wai:ternary-receipt-id` | the world-session, film and reel, haptic, score, 4D-splat, audio-scene and ternary-reconstruction receipts | `receipt`: its receipt hash, over the payload in the form it was signed (§2.8) | `joules_micro`; its optional label | `null` | its `signer_pubkey` |
|
||
| `wai:asset-receipt-id` | provenance receipt | `receipt`: its receipt hash | step `i`'s `joules_micro`; that step's optional label | step, from 0 | its `signer_pubkey` |
|
||
| `wai:quantum-receipt-id`, `wai:quantum-calibration-id`, `wai:quantum-job-id`, `wai:quantum-mitigate-id`, `wai:quantum-decode-id`, `wai:quantum-compile-id`, `wai:quantum-rearrange-id`, `wai:quantum-fabric-id`, `wai:phasor-receipt-id` | the quantum receipts | `receipt`: its receipt hash in the form it was sealed, labelled or not | `joules_micro`; its optional label | `null` | its `signer_pubkey` |
|
||
| `wai:quantum-qbom-id` | quantum bill of materials | `receipt`: its receipt hash | entry `i`'s `joules_micro`; that entry's optional label | entry, from 0 | its `signer_pubkey` |
|
||
|
||
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](jwp-receipts.md) §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.
|