open-standards/jcp/jcp-rs/crates/jcp-efficiency/MAPPING.md

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 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): 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).