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 with the outcome anchor the rates omit (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.

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	Honest provenance (HwShunt/ModelBased/Estimator) — SCI leaves E's trust unstated
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 power-sensor readings, not fabricated estimates — but their derivation and error bounds are undisclosed, nothing binds the number to the sensor, and the reading reaches a verifier through the platform's own (untrusted) software. 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) attests a reading, commits it into an efficiency/1 receipt, re-verifies both from scratch, and derives IntegrityAttested.

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 model, not a meter — 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 non-physical counter 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).