Open Energy Receipt / 1

OER/1 and DRIFT/1

A receipt schema for energy claims, and a benchmark protocol for learning under drift.

Institute for Physical AI @ John Bailey Institute

Charlot Lab ecosystem · released CC0 for comment

Draft for comment. Circulated to the MLCommons Power working group and the EU AI Office methodology process.

EFA-RFC-001: OER/1 and DRIFT/1

An Open Energy Receipt schema and a Learning-Under-Drift benchmark protocol for AI systems

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

1. Motivation

Two vacuums exist where the AI industry most needs standards.

The receipt vacuum. The EU AI Act (Art. 53, Annexes XI–XII) now obliges providers of general-purpose AI models to document “known or estimated energy consumption,” demandable by the AI Office without notice, with penalties up to €15M or 3% of global turnover. Yet the regulation permits estimates, omits the inference phase (which the sources this review used place at roughly 60–90% of lifetime AI energy, inputs: [the two datacentre-energy studies used, each with the fleet mix and the training/inference split it assumes]; an assumption a reader can replace, since the share is a function of model lifetime and query volume and is not a constant), restricts disclosure to authorities, and, searching the AI Act text and Annexes XI–XII, the AI Office's published Model Documentation Form, and the CEN-CENELEC JTC 21 work programme through August 2026, this review did not locate a standardized measurement methodology attached to it, nor a published delivery date for a harmonized standard that would supply one. Meanwhile, in a sample of vendor efficiency claims collected by this review ([n] claims, [source list], collected [date]), the published ratios span 10× to 10,000×, and [n of n] did not state on their face whether the figure came from a simulation, a stand-in device, or an audited measurement; the collection and its coding are published alongside this RFC so a reader can recount. A regulation that mandates a receipt without specifying its form leaves the form open. OER/1 is one candidate form, offered for comment and for adoption, forking or replacement under CC0: small enough to adopt verbatim, strict enough to make a claim auditable, and paradigm-neutral enough to cover a GPU, a thermodynamic sampler, a photonic array, or a settling fabric with the same fields.

The benchmark vacuum. Two recent transitions turned on a scoreboard the incumbent could not top (ImageNet for deep learning; $/kg to orbit for reusable launch); this review offers those two as the pattern it is reasoning from, not as a survey of every transition. The candidate scoreboard for energy-first, learn-at-inference AI is performance under distribution drift, at decision latency, per audited joule: a regime a frozen-weight architecture can enter only by becoming plastic at inference, and one this review did not locate a benchmark for (searched: MLPerf Inference / Training / Tiny / Power suites, MLCommons Power WG minutes, the continual-learning benchmark literature on arXiv including CLEAR, CORe50, Avalanche and the RL continual suites, and OpenReview 2024–2026, through August 2026). DRIFT/1 specifies it. The two specs interlock: DRIFT/1 leaderboard entries are ranked only as high as their OER conformance level allows.

2. Terminology

• Workload: a fully specified computational task with a quality metric (a benchmark episode, a batch of queries, a training step).
• Receipt: a signed record binding a workload’s identity and quality outcome to the energy spent producing it, with provenance.
• Provenance axes: two independent labels on every energy figure, how it was obtained (measured / derived / simulated / projected) and what device it describes (target / stand-in / emulation). A figure measured on an FPGA standing in for an unfabricated ASIC is measured × stand_in, never plain “measured.”
• Drift event: a change to environment dynamics after deployment, drawn from a seeded schedule unknown to the system under test.
• Regret: cumulative shortfall of achieved return versus the best per-segment policy in hindsight.
• Certificate: machine-checkable evidence of behavioral guarantees (e.g., an energy function decreasing monotonically along trajectories; a verified contraction region).
• Sealed / plastic: whether parameters are frozen at deployment, or declared mutable at inference (fast weights, Hebbian writes, online Bayesian updates, on-chip plasticity).

3. OER/1: The Open Energy Receipt

3.1 Design requirements

An OER receipt MUST be: attributable (which physical device, which software stack, which site), quality-paired (joules without a quality metric are meaningless and MUST NOT be issued), provenance-explicit (both axes, always), composable (receipts sum; grades do not silently upgrade), tamper-evident (hashed and signable), and paradigm-neutral (no field presumes kernels, clocks, or weights; a biological substrate is expressible).

3.2 Schema (normative, JSON)

{
  "oer_version": "1.0",
  "receipt_id": "uuid",
  "issued_at": "RFC3339 timestamp",
  "issuer": { "org": "string", "contact": "uri" },

  "workload": {
    "name": "string",
    "spec_uri": "uri",
    "input_hash": "sha256",
    "output_hash": "sha256",
    "quality": { "metric": "string", "value": 0.0, "higher_is_better": true }
  },

  "execution": {
    "substrate": {
      "family": "gpu | cpu | fpga_settling | tsu_pbit | ising_annealer | neuromorphic_snn | photonic | cim_pim | reversible | biological | hybrid | other",
      "device_model": "string",
      "device_count": 1,
      "firmware": "string"
    },
    "stack": [ { "layer": "framework|compiler|runtime|kernel_lib|os", "name": "string", "version": "string" } ],
    "site": { "grid_region": "string", "pue_applied": 1.0, "span": ["start", "end"] }
  },

  "energy": {
    "joules_total": 0.0,
    "breakdown": { "compute_j": null, "movement_j": null, "idle_alloc_j": null },
    "method": "wall_plug_metered | rail_metered | frequency_sweep_slope | hw_counter_estimated | model_estimated",
    "meter": { "instrument": "string", "calibration_date": "date", "uncertainty_j": 0.0 },
    "sampling_hz": 0
  },

  "provenance": {
    "how": "measured | derived | simulated | projected",
    "device": "target | stand_in | emulation",
    "note": "string: REQUIRED when device != target"
  },

  "latency": { "wall_s": 0.0, "time_to_first_valid_s": null, "p99_decision_s": null },

  "certificate": {
    "type": "none | energy_monotone | contraction_region | formal_proof",
    "coverage": null,
    "evidence_uri": null
  },

  "attestation": { "receipt_hash": "sha256", "signature": "base64", "pubkey": "base64", "witness": null },
  "extensions": {}
}

3.3 Composition

A parent receipt MAY aggregate child receipts (extensions.children: [receipt_id…]). Its energy.joules_total MUST equal the sum of children plus declared overhead. Its provenance and conformance level MUST equal the minimum grade among children (min-grade propagation). Mixed-provenance aggregates MUST list the fraction of joules at each grade.

3.4 Conformance levels

EU AI Act crosswalk (informative). Annex XI “known or estimated energy consumption” ↔︎ energy.* + provenance.how (known = measured/derived at L1+; estimated = L0). “Computational resources used” ↔︎ execution.substrate + execution.stack. The Act’s inference-phase omission ↔︎ per-answer receipts under this spec close it voluntarily. The Model Documentation Form’s energy field can carry an OER receipt URI unchanged.

3.5 Anti-gaming rules

Issuers MUST NOT: exclude idle/allocated-but-unused energy for reserved hardware (report in idle_alloc_j); report best-of-N runs without N receipts or an aggregate covering all N; quote a stand-in figure without the device axis and note; issue receipts for a quality outcome below the workload spec’s declared floor; or apply PUE < 1.0. Comparisons across receipts of different conformance levels MUST state both levels.

4. DRIFT/1: The Learning-Under-Drift Benchmark

4.1 Task classes (v0.1)

Reference environments, drift-schedule generators, and oracle solvers are published with committee-held seed pools; public seeds for development, sealed seeds for the leaderboard.

4.2 Protocol

1. Entrant declares the pre-deployment budget (training compute, data) and whether the system is sealed or plastic at deployment; and, if plastic, the mechanism (fast weights, Bayesian update, on-chip plasticity, etc.).
2. At t=0 the system is deployed. No human intervention, no external retraining calls, no network egress. All adaptation computation occurs inside the metered boundary: adaptation energy appears in the receipt or the run is void.
3. Drift events occur at times/magnitudes drawn from the sealed schedule.
4. Every episode, including failures, is receipted. Leaderboard entries require OER-L2 minimum; L3 entries rank above L2 at equal scores; L0/L1 and any device: stand_in entries appear only in a separate projected tier, never interleaved.

4.3 Scoreboard

Primary result is the tuple ⟨R, L, J⟩, always reported in full (no single-scalar collapse):

• R: cumulative regret vs. the per-segment oracle, normalized by the frozen baseline’s regret (lower is better);
• L: decision latency, p50 and p99 (seconds);
• J: receipted joules per episode, with adaptation energy itemized where separable.

Derived (optional): Adaptation Efficiency AE = (Regret_frozen − Regret_entrant) / J_entrant (regret bought back per joule).

4.4 Mandatory baselines

Every leaderboard release ships with maintained reference results: (a) a frozen strong baseline (TD-MPC2-class model-based RL, trained on the pre-drift distribution, weights sealed); (b) a naive online fine-tune baseline (gradient steps on the stream, same wall-clock budget); (c) each entrant’s own plasticity-off ablation. An entrant that cannot beat its own ablation on R has not demonstrated learning under drift, whatever its J.

4.5 Reporting

Minimum 5 sealed seeds per task; mean and worst-seed reported; all receipts, configs, and logs published; seeds revealed after the leaderboard round closes. Certificate coverage (for D-A/D-B actuation) reported alongside; an entry MAY claim the certified flag only with certificate.type != none at stated coverage and 100% empirical convergence from the certified region.

5. Integration hooks (informative)

Receipts attach at existing boundaries with no new runtime required: an ONNX Runtime execution-provider callback; StableHLO/IREE module metadata; a Triton launch-hook wrapper; NIR (Neuromorphic Intermediate Representation) graph metadata for spiking targets; Lava process monitors; the MLPerf-Power PTDaemon harness for L2 wall-plug capture; and language-level emission from energy-typed stacks (e.g., Ferric runtimes). Portability layers that lower one model onto many substrates are the natural mass issuers of OER receipts: a universal stack plus a universal receipt turns every deployment into a comparable datapoint.

6. Governance

Versioning is semantic; breaking schema changes bump the major version. Change proposals via public PR; a standing group of ≥3 unaffiliated reviewers; vendor entries to DRIFT/1 do not confer governance rights. This document may be adopted in whole or part by any body without attribution (CC0). Reference implementations required before v1.0: JSON-Schema validator, PTDaemon-compatible capture harness, D-A/D-B/D-C environments + oracles, and two worked receipts on dissimilar substrates (one GPU, one non-von-Neumann).

7. Worked example (informative)

A settling-fabric micro-workload, graded:

{
  "oer_version": "1.0",
  "receipt_id": "3f9c…",
  "issued_at": "2026-08-02T18:00:00Z",
  "issuer": { "org": "example-lab", "contact": "mailto:receipts@example.org" },
  "workload": {
    "name": "hopfield-recall-64x64",
    "spec_uri": "https://example.org/specs/recall-64",
    "input_hash": "sha256:ab…", "output_hash": "sha256:cd…",
    "quality": { "metric": "pattern_recall", "value": 1.0, "higher_is_better": true }
  },
  "execution": {
    "substrate": { "family": "fpga_settling", "device_model": "Virtex-UltraScale+ (AWS F2)", "device_count": 1, "firmware": "bitstream-7c2e" },
    "stack": [ { "layer": "runtime", "name": "ternary-fabric", "version": "0.4.1" } ],
    "site": { "grid_region": "us-east-1", "pue_applied": 1.2, "span": ["…","…"] }
  },
  "energy": {
    "joules_total": 2.12e-12,
    "breakdown": { "compute_j": 2.12e-12, "movement_j": null, "idle_alloc_j": 0 },
    "method": "frequency_sweep_slope",
    "meter": { "instrument": "board telemetry + slope regression R2=0.9999", "calibration_date": "2026-07-01", "uncertainty_j": 8e-15 },
    "sampling_hz": 1000
  },
  "provenance": { "how": "measured", "device": "stand_in", "note": "FPGA stand-in for unfabricated ASIC; per-recall figure derived from measured per-accumulate slope" },
  "latency": { "wall_s": 5.3e-7, "time_to_first_valid_s": null, "p99_decision_s": null },
  "certificate": { "type": "energy_monotone", "coverage": 1.0, "evidence_uri": "https://example.org/ledger/settle-monotone" },
  "attestation": { "receipt_hash": "sha256:…", "signature": "…", "pubkey": "…", "witness": null },
  "extensions": {}
}

Conformance: OER-L1, provenance measured × stand_in; publishable, not leaderboard-eligible; exactly what the two-axis label exists to enforce. Every figure in this example is synthetic and illustrative: no device was measured to produce the 2.12e-12 J total, the 8e-15 J uncertainty or the R2 = 0.9999 regression above. They are placeholders showing field shape, and a receipt actually carrying them would itself be provenance simulated × emulation.

Status of this document

What is this? A draft specification for an energy receipt and a drift benchmark, written for a documented methodology gap, with wall-plug measurement aligned to established power-measurement practice.

What would make it load-bearing? Two independent implementations producing receipts for the same workload on the same hardware and agreeing on the fields this document makes normative. That is the test the editors intend to publish against.

What is the most useful thing a reader can do? Implement it and report where it was ambiguous. A specification improves faster from an implementer's confusion than from agreement.

Why does it matter? Because once two parties who have never met can compare energy numbers, every efficiency claim in the field becomes checkable, and the argument turns into engineering.

Acknowledgments

Validation-ledger norms after the EFA program; wall-plug methodology aligned with MLCommons Power / SPEC PTDaemon; drift-task shapes after the EFA nano suite and TD-MPC2 baselines; written for the methodology vacuum documented around EU AI Act Art. 53. Drafted with AI assistance (Claude, Anthropic) at the direction of the EFA program; all normative choices remain the editors’ responsibility.