open-standards/jcp/jcp-rs/crates/jcp-efficiency/MAPPING.md
Transaction Science 9b57b96816
All checks were successful
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 55s
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 17s
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 1m12s
standards workspaces build + test / jouleclaw-rs (-nodebug, jouleclaw/jouleclaw-rs, -p jouleclaw-energy --features rapl,nvml, jouleclaw-rs, linux-arm64, -C target-feature=+fp16) (pull_request) Successful in 3m18s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 4m14s
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m37s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 7m41s
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m10s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 2m50s
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, sandbox-rs, linux) (pull_request) Successful in 2m16s
standards workspaces build + test / joule-ui-rs (joule-ui/joule-ui-rs, joule-ui-rs, linux) (pull_request) Successful in 8m12s
efficiency/1: a partial energy figure is sealed as partial and never headlines as a task total
`Efficiency::wire()` sealed `energy_uj` and `provenance` and nothing about
coverage. So a GPU-only reading (a hardware counter that reads the
accelerator and not the CPU work that drove it) reached a verifier as the
whole unit's energy. The receipt also sealed a `uj_per_accepted_token` over
that reading, which presented it as what the work cost per token. jcp SPEC
§5.2 already said a `Partial` figure MUST NOT be presented as a task total,
and listed the receipts that carry coverage. efficiency/1 was not among them.

`aggregate()` then summed energy across receipts with no coverage and no
provenance, and its per-unit figure came out as clean as a whole one. §5.3
says aggregation takes the floor of both and is never a step at which a
grade improves.

Now:
- The receipt carries `energy_coverage: "Partial"` when the figure is
  partial, and omits it when the figure is whole. A whole receipt, and every
  receipt sealed before the field existed, keeps its bytes.
- A partial receipt seals no `uj_per_accepted_token`. A partial figure
  divided by tokens is not what the work cost per token, nor a bound on it,
  since a partial figure can fall short of the work or exceed it.
- `read_payload`, split out of `verify` so the payload rules can be replayed
  without a signature, refuses:
  - a partial receipt carrying the headline;
  - any `energy_coverage` but "Partial" ("Whole" included; absence is Whole);
  - a provenance label that is not one of the three.
- `Totals` carries `provenance_floor` and `coverage`. A total over any partial
  receipt is partial, gives no per-unit energy, and reports value per joule
  as its worst value (0.0).

SPEC §5.2 now lists efficiency/1 with these rules. A published pack,
`conformance/v1/efficiency.json` (from `gen_efficiency_vectors`), carries the
readings and refusals and the totals sets must sum to. `tests/efficiency_pack.rs`
replays it from disk.

Tests: 3 new unit tests and 4 pack replays. All 9 mutations of the new rules
are killed. The pack alone catches the headline, coverage-floor and
provenance-floor mutations.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-20 13:58:36 -04:00

230 lines
15 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# The Efficiency Spec — standards mapping & frontier
`jcp-efficiency` does not invent a metric vocabulary. It **ingests** the per-unit
calculation standard the field is converging on and supplies the one thing that
standard, and every deployed disclosure regime, lacks: a **signed,
honest-provenance, verifiable receipt** carrying an outcome-anchored figure.
This document maps `efficiency/1` onto (1) the GSF **SCI-for-AI** calculation
standard, (2) the **EU AI Act** Annex XI obligation, and (3) the aggregate
data-centre / entity regimes — then scopes the open frontier (attested energy
counters) the whole landscape leaves empty.
## 0. Why a receipt, not another rate
The dark-factory economics turn on four figures — joules/accepted-token,
tokens/second, value/token, and the tokens/joules/dollars spent **per completed,
verified unit of work**. The incumbents publish, at best, a *rate* (cost per
token). A rate cannot tell you whether the spend bought a result, which is why a
large share of agentic projects are cancelled for cost/unclear-value. `efficiency/1`
seals all four **against an outcome anchor** (`completed` + a verdict): a
measurement that did not complete is spend that bought nothing, and `aggregate()`
charges every attempt — including the failures — against the results actually
delivered.
**The anchor is not ours alone, and the record should say so.** Goal-denominated
energy accounting is a live line of work. *Energy per Successful Goal* (EpG) —
"total workflow energy across all attempts, including failures and retries,
divided by successfully completed goals" — is defined in Panigrahy, Tyagi, Abkin,
Houngninou and Mahapatra, *Energy per Successful Goal: Goal-Level Energy
Accounting for Agentic AI Systems* (arXiv:2605.22883, v2 2026-10-12), with a
measurement framework that attributes RAPL and ARM hardware counters to workflow
energy. That denominator is the one `uj_per_completed_unit()` computes, waste
included. Like SCI-for-AI in §1, it is a *calculation and reporting* convention:
the paper describes measurement, attribution and a reproducibility protocol, and
no part of it signs or attests the resulting figure. So what `efficiency/1` adds
is not the anchor but the artifact — a signed, honest-provenance, verifiable
receipt that carries it, which is what the §1 table itemises. (arXiv
non-exclusive licence: cited and briefly quoted, not reproduced.)
## 1. GSF SCI-for-AI → `efficiency/1` (ingest, not compete)
**SCI-for-AI** is a ratified Green Software Foundation specification (Nov 2025),
with ISO submission targeted for 2026. It is the most granular instrument in the
landscape: the Software Carbon Intensity rate `SCI = (E·I + M) / R`, with the
functional unit `R` chosen **per token, per inference, per FLOP, per
training-token, or per parameter**. It is a *calculation and disclosure*
methodology — a `grep` of the spec text for `verif`, `attest`, `assur`, `audit`
returns zero, and the GSF trust model is *provenance-by-reputation*, not signed
receipts.
`efficiency/1` adopts SCI-for-AI's framing and adds the missing layer:
| SCI-for-AI concept | `efficiency/1` field / method | What TX adds |
|---|---|---|
| `E` — energy of the functional unit | `energy_uj` + `provenance` + `energy_coverage` | **Honest provenance** (`HwShunt`/`ModelBased`/`Estimator`) — SCI leaves `E`'s trust unstated — and **coverage**: a `Partial` figure (a GPU counter alone) is sealed as such and gives no per-token rate, since it is not `E` |
| `R` — functional unit (per token / inference) | `tokens_out` (accepted) → `uj_per_accepted_token()` | The unit is **sealed**, not asserted |
| `SCI` rate | `uj_per_accepted_token`, `tokens_per_sec()`, `uusd_per_accepted_token()` | Rates **recompute from sealed integers** — reproducible, tamper-evident |
| — (no outcome concept in SCI) | `completed` + `verdict`, `aggregate()` | The **outcome anchor** + waste accounting SCI has no notion of |
| `M` — embodied/marginal | (out of scope v1; roll into `energy_uj` upstream) | — |
| disclosure | the sealed COSE_Sign1 envelope | **Cryptographic verification** SCI explicitly lacks |
**Net:** SCI-for-AI is *what to compute*; `efficiency/1` is *the verifiable receipt
that carries it*. A conformant flow computes an SCI figure per functional unit and
seals it as an `efficiency/1` — ISO-track-aligned, and verifiable by anyone.
## 2. EU AI Act Annex XI → `efficiency/1` (compliance bridge)
The AI Act (Reg. (EU) 2024/1689), Art. 53 + **Annex XI §1(2)(e)**, binds GPAI
providers (obligations from 2 Aug 2025; fines from 2 Aug 2026) to document the
**"known or estimated energy consumption of the model."** Two structural gaps the
Act itself carries — both of which `efficiency/1` closes:
- **The exemption.** The Act (and the GPAI Code of Practice) excuse a provider
that *"lacks critical information from a compute or hardware infrastructure"* it
does not control. TX's on-device metering dissolves this: you measure and seal
the energy yourself, at honest provenance — you do not depend on the cloud
provider's cooperation, so the exemption never triggers.
- **Training-only, and not public.** Annex XI covers *training* energy, held in
regulator-facing technical documentation, and the downstream Annex XII flow
carries **no energy field at all**. `efficiency/1` extends the same honest
accounting to **inference** (the larger lifetime energy the Act omits) and makes
it a portable, verifiable artifact a downstream party can actually check.
Mapping: an `efficiency/1` chain over a model's serving fleet supplies the Annex XI
energy figure as a *measured, signed* number rather than an estimate — and the
`provenance` label states exactly how it was obtained, which is precisely the
"comparable and verifiable methodology" the Act defers to a future delegated act
(Art. 53(5)).
## 3. Aggregate regimes → `aggregate()` (roll-up)
Per-unit receipts roll up to the figures the facility- and entity-level regimes
demand, with provenance an auditor can check:
- **EU EED (Reg. 2024/1364), China GB 40879-2021 / 东数西算, Japan, Singapore** —
facility PUE/energy: sum `energy_uj` across a facility's receipts; the ratio to
IT energy is PUE, now traceable to signed per-unit sources instead of a
self-reported aggregate.
- **CSRD/ESRS E1-5, California SB 253, AU ASRS, UK SECR** — entity Scope-2 AI
energy: `aggregate().completed_uj + wasted_uj` is the auditable AI-compute line,
with the waste share (`waste_fraction()`) made explicit rather than hidden.
The same substrate feeds every regime. The GAO's own critique of the status quo —
*"companies are generally not reporting … a lack of standardized reporting"* — is
the opening: a signed, tamper-evident receipt is the trust layer none of these
self-reported regimes has.
## 4. The frontier — attested energy counters (unclaimed by everyone)
A signed receipt is only as honest as the *provenance* of the counter it signs, and
here the entire field — TX included — sits on an **unsolved problem, one of
provenance and tamper-evidence rather than accuracy**:
- **Vendor counters are opaque and platform-relayed, not independently rooted**:
RAPL/NVML/IOReport are *real* readings of the vendor's own energy counter, not
fabricated estimates — which is why JCP grades a live one `HwShunt` (SPEC §5) — but
how the vendor derives the count (a sensor, a model, or both) and its error bounds
are undisclosed, nothing binds the number to its source, and the reading reaches a
verifier through the platform's own (untrusted) software. And a counter is a reading
only while it is live: one that is present but frozen, or republished in lumps (as
Apple's CPU energy rails are to an unprivileged reader on macOS 27.0.1), reads
nothing of the work and must not yield a hardware-graded figure.
RAPL has separately been an unprivileged-readable power side-channel
(PLATYPUS), and its accuracy against an external meter is itself contested
(arXiv:2505.09375).
- **NVML / `nvidia-smi`** is a real on-board sensor, but its coarse sampling misses
short kernels (arXiv:2407.16893).
- **Redfish** telemetry is coarse and **not cryptographically signed**.
- **Confidential computing** (NVIDIA/Intel/EQTY) attests *execution integrity*,
**not energy** — a frequent and important confusion.
So no trustworthy *physical* root exists to sign, for anyone. Two research points
gesture at the gap (Cambridge zk-SNARK over *aggregate* smart-meter inputs,
arXiv:2506.16347; a Penn-State/Stony-Brook *per-job* TPM/TEE vision, arXiv:2307.11993,
unbuilt) — neither binds a **measured per-task** energy quantity into a signed,
third-party-verifiable receipt with **attested counter provenance**.
This is the real R&D lane, and TX holds the closest existing substrate:
1. **Provenance is already honest** — `efficiency/1` never claims `HwShunt` it
cannot back; the label states the counter's trust level. That is the correct
design *today*, and the precondition for attestation tomorrow.
2. **The Sandbox standard (S0–S7)** + the **S5 microVM proven on real bare-metal
RAPL** already runs metered work in an attestable isolation domain. The step is
to extend confidential-compute-style attestation from the *integrity* of the
execution to the *provenance of the energy counter* — an attested, tamper-evident
reading — and bind it into the `efficiency/1` envelope.
3. The result is the first receipt whose energy figure carries an **attested
physical root**: the standard, product, or regulation for which is empty as of
mid-2026.
**First kernel shipped** — `sandbox-tee::energy` (the S6 attestation crate) now
binds an `EnergyStatement` (counter class, microjoules, window, freshness nonce)
into a TEE report's `report_data` and derives an **honest trust ladder**:
`IntegrityAttested` (a verified report over a platform-self-reported counter — an
honest *relay*, not a reading rooted independently of the platform) vs
`PhysicallyRooted` (a verified, hardware-grounded report over a reading rooted in a
dedicated signed shunt — unreachable in software by construction) vs `Unattested`.
The distinction is provenance, not accuracy: the vendor counter is a real reading;
what it lacks is an independent root. The level is derived from the evidence, never
asserted: a TEE over a self-reported counter can never reach `PhysicallyRooted`.
Exercisable anywhere via the software-grounded `LocalSnpProvider`.
**Bound into the receipt** — an `efficiency/1` measurement now carries an optional
`energy_attestation`: a **content-id commitment** to those raw attestation-report
bytes ([`Efficiency::with_energy_attestation`]), sealed into the signed preimage.
This deliberately keeps the lightweight receipt crate free of any attestation
dependency: the receipt *commits*, and the attestation layer *adjudicates trust*.
The composed verification a relying party runs: (1) verify the receipt; (2) resolve
the attestation and check its content id equals the commitment; (3) verify the
attestation via `sandbox-tee::energy` to derive the honest trust level; (4) confirm
the attested energy equals `energy_uj`. The receipt never asserts a level it cannot
prove. The whole loop is a runnable demo:
`sandbox-tee/examples/attested_efficiency.rs` (`cargo run -p sandbox-tee --example
attested_efficiency`) runs a small task, attests the figure this host's meter
gave it under the counter class that obtained it, commits it into an
`efficiency/1` receipt at the same grade, re-verifies both from scratch, and
derives `IntegrityAttested`. Where a vendor counter read the task's CPU work
(the kernel's per-process count on macOS, a RAPL package on Linux) the
statement names that counter and the receipt seals `HwShunt`; where none did,
the figure is the meter's estimate, attested as `Estimator` and sealed
`Estimator` — the report binds the figure as it was obtained and does not make
an estimate a reading.
**What `PhysicallyRooted` actually requires (an honest clarification).** It is *not*
reached by standing up a cloud confidential VM. A cloud SEV-SNP/TDX instance gives a
hardware-grounded *report*, but its energy counter is still RAPL — a vendor counter
the platform relays, not a reading signed at its source — so the derived level is
`IntegrityAttested`, not `PhysicallyRooted`. That is the whole "confidential
computing attests integrity, not energy" thesis, enforced at the type level: the
ladder refuses to promote a counter not signed at its source, no matter how genuine
the TEE. `PhysicallyRooted` needs *both* a hardware-grounded report *and* a
**physical counter whose reading is signed at the source** — a current shunt with a
secure element — co-located with confidential compute. That is a custom-hardware
build, not an instance type. Its software-reachable precursor — deriving
`Grounding::Hardware` from a **signature chain to a trusted root** instead of a
verifier-supplied parameter — is now **shipped** as `sandbox-tee::chain`
(`derive_grounding` + `verify_attested_energy_rooted`): grounding is proven from
evidence or it is software, and with a physical counter the ladder now *reaches*
`PhysicallyRooted` (tested against a synthetic root). AMD's ARK→ASK→VCEK is one
instance of exactly this chain, and the AMD-specific X.509 adapter is now also <!-- allow-vanity: X.509 is the ITU-T certificate standard's name, not a count of adapters -->
**shipped** as `sandbox-tee::amd_kds` (the off-by-default `amd-kds` feature):
`verify_kds_chain` parses the real ARK/ASK/VCEK X.509 certs, verifies the
RSA-4096 **RSASSA-PSS/SHA-384** signatures ASK←ARK and VCEK←ASK against a
caller-pinned ARK, and returns the VCEK's P-384 key; `verify_attested_energy_amd`
then checks the report against it and derives `Hardware`. It is tested end-to-end
against a self-generated AMD-structured chain (RSA-PSS CA certs + a P-384 leaf) —
which proves the cryptographic constructions, not a specific chip. What now
genuinely remains is **not code**: pinning AMD's real published ARK (a static,
public deployment artifact) and the physical signing shunt co-located with
confidential compute (custom hardware).
## Status
- `efficiency/1` receipt + `aggregate()` — shipped (`src/lib.rs`).
- SCI-for-AI functional-unit alignment — this document; a conformant emitter computes
SCI per unit and seals it.
- Attested-counter kernel — **shipped** in `sandbox-tee::energy` (statement bound
into a TEE report's `report_data`; honest `IntegrityAttested` vs
`PhysicallyRooted` trust ladder; software-grounded path exercisable anywhere).
- `efficiency/1` ↔ attestation binding — **shipped** (`energy_attestation`
content-id commitment; receipt crate stays dependency-free of the attestation
layer).
- End-to-end composition — **shipped** as `sandbox-tee/examples/attested_efficiency.rs`.
- Evidence-derived grounding — **shipped** in `sandbox-tee::chain` (grounding from a
signature chain to a trusted root, not asserted; `PhysicallyRooted` reachable + tested).
- AMD KDS X.509 adapter — **shipped** in `sandbox-tee::amd_kds` (`amd-kds` feature): <!-- allow-vanity: X.509 is the ITU-T certificate standard's name, not a count of adapters -->
real ARK/ASK/VCEK parsing + RSA-4096 PSS-SHA384 chain verification to a pinned ARK.
- Remaining (**not code**): pinning AMD's published ARK (a deploy artifact) and a
signing physical shunt co-located with confidential compute (hardware).