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::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]>
230 lines
15 KiB
Markdown
230 lines
15 KiB
Markdown
# 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).
|