Measure a job’s energy, compare it to a fair baseline, and get a clear pass / fail decision — then seal evidence and register the result.
· ·
No partner data required for the demo. Real sites use the same flow with your job numbers.
Go to Verify and click Load demo — or enter org, hardware, power, duration, and useful work.
AEX attributes energy, builds a same-work baseline, and returns PASS, CONDITIONAL, or REJECT.
Seal locks a SHA-256 evidence package. Issue writes it to the live registry (optional).
Independent verification first. Markets and automation only after methods and buyers are real.
Telemetry for GPU / facility energy tied to a job and useful work — not orphan rack watts.
Counterfactual baseline, integrity gates, refuse when data cannot support the claim.
Sealed evidence packages and certificates with double-count guards.
| Layer | Role | Status |
|---|---|---|
| Observe | Telemetry & useful work | near-term |
| Verify | Baselines & decisions | primary |
| Registry | Certificates | live slice |
| Flex / Market / Control | Dispatch & contracts | later |
File-backed pilot results. Pre-registered thresholds are not retuned after outcomes. Production AI energy validation is not claimed.
| Study | Outcome | Status |
|---|---|---|
| Synthetic A–E pilot | Precision 1.0 · FP 0% | PROVED |
| BDG2 inject gate (n=40) | MAE 9.5% → 4.9% certified | PROVED |
| Multi-meter leakage | Refuse 8% · detect 50% | PROVED |
| CalTRACK estimator | MAE ~7.0% vs 7.4% | TIE |
| A–E + DiD / calendar-DiD | B/C/D/E FP bars at n=20; A recall open | PARTIAL |
| GPU/PDU wire + partner pack | Demo path works | WIRE |
| Production AI energy validation | Needs partner corpus | NOT PROVED |
Measure energy → compare baseline → seal evidence → register. Nothing hits the registry until Issue.
Run a verification to see PASS, CONDITIONAL, or REJECT.
Drop GPU/PDU CSV, summary JSON, or partner claim packs. External systems can also
POST /api/ingest and open this console with ?ingest=<id>.
POST https://aex-e0j.pages.dev/api/ingest
Content-Type: application/json
{ "source": "api", "form": { "customer": "…", "accelerator_count": 8, … } }
// or { "raw": "<csv text>", "filename": "gpu.csv" }
GET /api/ingest/:id → form + summary
// then open: /#console?ingest=<id>
Device → server → rack → IT → facility → cloud. Only checked components enter e_total.
No measurement yet Run engines to attribute energy to useful work under the selected boundary. Device → server → rack → IT → facility boundaries change what is in-scope.
Baseline energy is scaled to the same accepted useful work. Doing less work cannot mint efficiency credits.
Awaiting measure pass Baseline compares attributed energy against an approved reference intensity or historical total at equal useful work.
AES idle Score is class-specific; do not compare across AES classes without normalization.
| ID | Sev | Result | Check |
|---|---|---|---|
| No checks yet. | |||
No decision Verifier checks boundary fitness, quality floors, rebound flags, and claim strength before seal.
SHA-256 over stable-canonical JSON. Commitment binds package_id + issued_at. Not a blockchain write.
Unsealed Seal after a successful verify pass. Hash commits the full evidence package for registry issue.
Not issued Issue posts the sealed package to the AEX registry (D1). Double-count guards apply on evidence_hash.
Optional tools — not required for day-one verification.
No flex event Simulates curtailable kW given interactive/batch mix, notice window, and SLA risk — not a utility bid.
Operational NFET only — regime classify → flex envelope → delay-aware recommendation → control receipt. Does not prove theoretical NFET. Does not issue AEX certificates by itself. Control is real only if an executor ACKs and measured power changes.
No cycle Optional control sketch for AEX handoff — not certificate issuance.
Issued proof records. Double-count blocked. Measurement instruments — not carbon offsets.
Workloads tracked: —
| ID | Status | Org | Saved kWh | AES | Evidence hash | Issued | Actions |
|---|---|---|---|---|---|---|---|
| Loading registry… | |||||||
No certificates yet.
No selection Click View on a row to load certificate metadata and evidence summary from the registry.
No events loaded Issue and retire actions append to the audit log.
Idle Lookup by evidence_hash. Local seal re-check runs if the hash matches the package sealed in this session.
GET /api/health · /api/stats · /api/certificates POST /api/issue · /api/verify · /api/retire
Versions used by live engines. Speculative market claims are excluded. What you measure is what you may claim — nothing more.
Total workload energy = sum of boundary-included components:
Useful work is quality × latency adjusted. Intensity is class-specific (Wh/1k requests, J/image, kWh/milestone, …). Productive util is clamped ≤ GPU util. Component sum must match e_total. Metering quality is labeled (power_x_time, tdp_x_util_estimate, …).
Methods: historical, control, benchmark, regression. Savings require same useful-work volume — doing less work does not mint efficiency. Confidence scales with boundary strength and method quality. Flags: NO_USEFUL_WORK, NO_SAVINGS, REBOUND_RISK, BOUNDARY_WEAK, REGRESSION.
Not universal. Dimensions: intensity 35%, infrastructure 15%, utilization 20%, model vs baseline 20%, service quality 10%. Do not rank models or facilities across AES classes without an explicit normalization method.
Critical gates reject packages without useful work or positive savings. Major conditions cover device/cloud boundary limits, power vs TDP, duration, and intensity-unit match. Evidence is SHA-256 sealed (not a chain write). Registry issue refuses VERIFY REJECT, zero savings, and malformed hashes. Flex models deliverable kW from mix × notice × duration; utility $ are scenario inputs only.
Scenario calculator only — edit every input. Results are not revenue forecasts. Certificate price defaults to $0 (no assumed market).
Mid-size inference or training operator (50–500 GPUs) with partial rack metering, Kubernetes/Slurm job metadata, and a cost owner who cares about $/token and peak demand — not only ESG slides.
IOU or municipal utility with existing commercial DR / flexible-load programs and large data-center interconnection queue in the same territory as the pilot cluster.
From Concept Overview v1 — stated so external framing cannot overclaim.
The Energy Intelligence Layer for the AI Economy: measurement and verification first, evolving toward optimization and market infrastructure. The “exchange” is aspirational — not the day-one product.
Statistically rigorous verification of claimed savings and flexibility — complementary to Emerald / Nvidia / Google Flex, not a head-on Control product. Cost + peak evidence for operators; verification services for utilities and regulators.
Defensible counterfactuals, useful-work definitions, double-count controls. Hardware telemetry is commoditized; verification libraries and methods are not.
No first customer fully defined yet. Layers 3 and 6 face funded competitors with multi-year head starts. Formal CSP/DR markets imply regulatory overhead not yet scoped. Trust requires an anchor partner (utility, lab, or hyperscaler).
Applied layer C+/B–, traffic-only validation. Synthetic pilot is necessary but not sufficient; real telemetry needs a second pass. No claim linking NFET to LOLM development without documentary support.
If AEX issues unverifiable baselines or soft claims without useful-work gates, it becomes another low-integrity market and serious buyers leave.
Emerald Conductor + Nvidia flexible AI factories; Google internal DR; EPRI DCFlex standards; Watershed/Persefoni-class carbon MRV. Gap: independent AI-energy verification with statistical rigor.
Yes — as measurement & verification infrastructure. No — as a day-one Flex/Control stack or credit exchange. This site implements Observe/Verify/Registry slices with honest non-goals for the rest.