340313d6b3
The questions this branch left open are now decided. A vendor energy counter
(RAPL, NVML, Apple IOReport) is a real reading; what it lacks is an
independent root, which is a gap in provenance, not in accuracy. It earns the
hardware grade only while it is live. The live GPU rail is not reported as a
partial reading of CPU work. And a partial figure must stay partial on the
intercept/1 wire.
The grade. jcp-energy already graded RAPL and NVML `HwShunt`. The IOReport rung
carried a live reading at `ModelBased`, in the modeled slot. It now takes the
same grade: `Meter::provenance()` says `HwShunt` and a live span is
`Energy::measured`. The declined paths keep their own grades: the time×power
model is `ModelBased`, the constant estimator `Estimator`.
Raising the grade raises the stakes of what `measure()` accepts, so it is
gated per span as well. It took any rise of the summed SoC total as the span's
energy, and that total rises through the GPU rail, which is machine-wide. On
this M5 Max, in this commit's own test runs, the counter counted 32 mJ and then
9.1 J between two reads while an independent oracle saw the CPU rail hold and
one other rail move. A rail that was live at selection can still hold across
one span: a span shorter than its update interval, or a rail that stops
publishing after the probe. The counter now reports the CPU rails' share beside
its total, from the same delta sample. `measure()` grades a span `HwShunt` only
when the CPU rail itself advanced. The figure is still the SoC total's rise,
which, like a RAPL package counter, over-debits the work rather than leaving
part of it out. A span whose CPU rail held, or whose read failed, is the
time×power figure at `ModelBased`. A model figure is never `HwShunt`. The grading
is one pure function, `ioreport_span`, so every branch runs on scripted reads on
any platform. The oracle test that checks the counter's total value for value,
against its own all-channel subscription, now checks the CPU share the same way.
The GPU rail is not reported as a partial reading. It is machine-wide (display
compositing moves it), so booking it to a task misattributes energy the task
did not spend, and a partial figure would under-debit the budget because the
CPU's share would go unmetered. The rung is declined to the whole-task estimate.
That rationale now sits in the rung's docs and in SPEC §5.1.
SPEC. §5 says `HwShunt` covers vendor counters as well as shunts, and carries
the liveness MUST in the shared wording. Its dashes are typeset and `Partial`
is code-formatted; the text is otherwise as decided. §5.1 adds the IOReport
rung. A new §5.2 defines coverage and its wire encodings, carried only when
`Partial`. One is jcp/2's `energy_coverage`, which jcp-receipt already emitted
but the SPEC never listed, so §8's core field list gains it. The other is
intercept/1's `coverage`.
intercept/1. jcp-intercept dropped coverage, so a `Partial` figure handed to it
was sealed as the whole step's energy. It now adds `"coverage": "Partial"` only
when the figure is partial. `verify` recovers it in a new
`InterceptReceipt::coverage`, and refuses any other value, an explicit "Whole"
included, because a sealer never produces one. A whole figure seals the same
bytes as before. The two envelopes a Redact-then-CallLimit chain sealed at
3fd35db5 were captured by building that commit in a scratch crate before the
change, and are pinned hex for hex. A whole `HwShunt` figure's object is
compared, key for key and in canonical bytes, against the pre-coverage object.
No conformance vector changes, and none contains an intercept/1 receipt.
Prose. Provenance::HwShunt's doc names vendor counters and the liveness rule.
The README's jcp-energy bullet lists the IOReport rung. Its jcp-gateway bullet
no longer says "metered on real hardware ... energy actually spent". jcp-efficiency's
MAPPING §4 now says "real readings of the vendor's own energy counter" instead of
"power-sensor readings", and that a counter counts only while live. It also no
longer calls RAPL "a model, not a meter".
Tests. jcp-energy has 54 lib tests (51 before) plus its integration test.
jcp-intercept has 12 (8 before). jcp-schema has 30, jcp-conformance its unit
test and 5 pack tests, all passing. `jcp-conformance` prints "all checks
passed", and jcp-cli builds and runs. clippy --no-deps is clean on jcp-energy
and jcp-intercept. jcp-schema's one warning, in flow.rs, is pre-existing.
Falsified, each by a temporary edit restored with git checkout:
- A live span built with `Energy::modeled` fails
`a_span_the_ioreport_cpu_rail_advanced_over_is_a_hardware_reading` and
`the_ioreport_rung_stamps_the_hardware_grade`.
- `Meter::provenance()` for IOReport set back to `ModelBased` fails
`the_ioreport_rung_stamps_the_hardware_grade`.
- Gating the span on the SoC total instead of the CPU rail fails
`a_span_the_ioreport_cpu_rail_held_over_is_the_models_figure` with
"the GPU rail rose, the CPU rail held ... provenance: HwShunt".
- A CPU share that counts every rail fails the hardware oracle test: "CPU share
rose 18127 µJ ... CPU energy rails rose 0 µJ". That one needs a non-CPU rail
to move during the window, and the GPU rail did.
- Sealing coverage even when Whole fails the byte-identity tests (and every
test that verifies a whole receipt).
- Dropping coverage when Partial fails `a_partial_figure_seals_coverage_partial`.
- Letting verify read an explicit "Whole" fails
`verify_refuses_a_coverage_other_than_partial`.
Not done here:
- jcp-gateway still seals `Energy::measured` for whatever sandbox-meter returns,
estimates included. The sandbox-meter liveness branch fixes that, so the
README's gateway line states the rule rather than this branch's gateway.
- The NVML rung reports GPU energy as a whole-task `HwShunt` figure. Under the
new MUST, a figure for work its counter does not cover (the CPU's share) is
`Partial`. That needs its own decision, and nothing here is built with
`--features nvml`.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
14 KiB
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/1extends 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_ujacross 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_ujis 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-smiis 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:
- Provenance is already honest —
efficiency/1never claimsHwShuntit cannot back; the label states the counter's trust level. That is the correct design today, and the precondition for attestation tomorrow. - 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/1envelope. - 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 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/1receipt +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'sreport_data; honestIntegrityAttestedvsPhysicallyRootedtrust ladder; software-grounded path exercisable anywhere). efficiency/1↔ attestation binding — shipped (energy_attestationcontent-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;PhysicallyRootedreachable + tested). - AMD KDS X.509 adapter — shipped in
sandbox-tee::amd_kds(amd-kdsfeature): 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).