Datacenters · AI labs · any company running heavy compute

Prove what AI compute actually used.

AEX is a simple loop for operators: measure a workload’s energy, check it against a fair baseline, and keep a sealed record you can show finance, customers, or a utility — without turning into a carbon marketplace.

—

Registry records live API

—

kWh on issued records live API

…

Registry API

No run yet engines ready

GPU in use

—

Facility overhead (PUE)

—

Saved vs baseline

—

Efficiency score

—

Meters stay empty until you run. Registry tiles above are only from the live API — never invented.

The process (keep it this simple)

Same loop for a single rack or a multi-MW hall.

1

Point at a workload

Which job, which GPUs or servers, which facility. Name it so energy can’t float free of the work.

2

Attach energy + useful output

Power (or kWh), duration, and what “done right” means — requests, tokens, images, training milestones. Pick the meter boundary you can stand behind.

3

Compare to a baseline

Same useful work. AEX checks whether savings are real efficiency — not less work, weaker quality, or a weaker boundary.

4

Seal & register

Hash the evidence, issue a record (or retire one). Share the hash or ID with auditors, buyers, or internal finance.

Use cases

Datacenter / colo

Tenant & rack accountability

Show energy per AI job at rack or row, idle waste, and peak shape — for ops cost and customer conversations.

AI / ML company

$/token and training cost

Intensity per accepted output, before/after an optimization, with a sealed before/after pair you can re-open later.

Enterprise with compute

Defensible AI energy claims

One record: what ran, boundary, baseline, ownership. Not a slide estimate. Optional flex scenario for peak programs.

Setup path

Start thin. Add metering depth as you earn trust.

Today · no install

Use this console

Open Try it.
Load example inputs or paste your job’s power, hours, useful work, PUE.
Run → review KPIs → Seal → Issue to registry.
Copy the evidence hash for your own notes or buyer pack.

Integrate · your stack

Wire real systems later

Jobs: scheduler / K8s / Slurm job id + model metadata.
Power: GPU sensors, PDU, or facility meter (say which boundary).
Output: tokens, requests, images — quality/SLA filters you already use.
API: POST /api/issue with a sealed package; GET /api/certificates to list.

Not an ESG dashboard

Not a carbon marketplace

Not GPU monitoring alone

Not blockchain-first

Deep methods, flex, pilot economics, and roadmap live under .

Operator guide

How to use AEX

Written for datacenter ops, AI platform teams, and any company that runs serious compute. No marketplace jargon required.

What you need

Minimum

To try now

Browser only. Example inputs or rough numbers from your last training/inference window: GPU count, average watts, hours, how much useful work finished, facility PUE if you know it.

Solid pilot

To trust the number

Job IDs from your scheduler, power from PDU or DCGM/vendor tools, and a clear useful-work definition (e.g. latency-OK requests). Same boundary every week.

Production

To integrate

Automated export of telemetry + job metadata into AEX evidence packages, registry issue on a schedule, and an owner for baselines (ops or energy lead).

Day-one walkthrough (15 minutes)

1

Open Try it

Use “Load example inputs” once so you see a full PASS path — labeled as an example, not your site.

2

Swap in your numbers

Replace GPU count, power, hours, useful work, PUE, and org/facility names. Keep the same boundary you’ll use next month.

you

3

Run engines

Read total kWh, intensity, saved vs baseline, and verify decision. If REJECT — fix useful work or baseline; don’t force a soft claim.

engine

4

Seal → Issue

Seal creates a hash. Issue writes to the live registry. Copy the evidence hash into your ticket, deck, or customer note.

registry

5

Optional: Flex & pilot economics

In Try it tabs / Depth: estimate curtailment kW for utility talks; scenario $/yr for an internal business case. Those are calculators, not invoices.

optional

What operators actually need (field fit)

Built against how datacenters and AI fleets already work: PUE as facility÷IT, workload-level intensity, interval demand for DR talks, and GHG Scope 2 estimates that stay estimates — not offsets.

IT

IT load vs facility overhead

PUE-style split. Device/rack meters for tenants; facility meter when you claim full hall energy.

AEX

JOB

Energy tied to a job

Scheduler / K8s / Slurm id + model + hardware — not orphan rack watts.

AEX

OUT

Useful work intensity

kWh or Wh per accepted tokens/requests/images with quality/SLA filters — not GPU-hours alone.

AEX

SRC

Tools you already run

DCGM / vendor GPU power, rack PDU, UPS/utility meter, BMS cooling, inference logs.

AEX

DR

Flex profile for utility talks

Pre / during / post kW, notice, duration, SLA risk. Scenario first; OpenADR automation later.

sim

CO2

Optional location-based kgCO2e

kWh × grid factor only. Market-based Scope 2 needs contracts. Never auto-credits.

opt

NO

Not a carbon marketplace

Records are measurement instruments. Soft tradable credits are out of scope until methods exist.

out

Integrate with your environment

Data you already have

Compute: K8s, Slurm, Ray, cloud job logs
Power: NVIDIA DCGM, AMD tools, PDU / rack meters, BMS
Facility: PUE (facility÷IT), cooling zone, utility interval data
Product: request logs, token counters, latency/eval pass rates

How AEX consumes it

Map each job → workload identity (who, where, hardware, model).
Sum energy in the boundary you disclose (device → facility).
Attach useful work with quality/SLA filters.
Run baseline + verify; only then POST /api/issue.
Colo tenants: stay on device/rack/IT unless the landlord shares facility meters.

After a console run — readiness from your inputs

Run Try it once; this panel fills with a 0–100 readiness score vs real operator checklist items.

Registry API (live)

GET  /api/health
GET  /api/stats
GET  /api/certificates
POST /api/issue     { "evidence": { …sealed package… } }
POST /api/verify    { "evidence_hash": "…" }
POST /api/retire    { "id" | "evidence_hash", "retired_by" }

Base (this deployment): https://aex-e0j.pages.dev/api/
UI: https://imagineqira.com/aex/

Roles (who does what)

Ops / facility

Meters & boundaries

Owns PUE, rack maps, and which meter is source of truth. Signs off that the boundary on a record is real.

ML / platform

Jobs & useful work

Defines what “accepted” work means and feeds job metadata. Runs console or automation after each release/optimization.

Finance / GTM

Records & claims

Uses issued hashes for cost stories and external claims. Never quotes savings without a registry ID.

Complex underneath

Full capability

Surface product is measure → verify → record. Below is the complete stack, methods, pilot model, and critical analysis. Nothing was removed — it is organized so you only open it when you need it.

Every claim answers seven questions

Engines enforce these; they are not marketing copy.

01

What useful AI work happened?

Quality- and SLA-adjusted units — not raw GPU hours.

live

02

How much energy did it use?

Attributed under an explicit meter boundary.

live

03

What would the baseline have used?

Historical, control, benchmark, or regression counterfactual.

live

04

Is the gap real efficiency?

Useful-work gates block “savings” from doing less work.

live

05

Can it be verified?

Rule checks + SHA-256 evidence packages.

live

06

Grid / money / emissions side effects?

Modeled separately — never assumed interchangeable.

scenario

07

Who owns the claim?

Issue, double-count guards, retire in registry.

live

Platform layers

MVP ships the left of the pipeline. Market and control come only after methods and buyers are real.

01

Observe

GPU power, util, PUE, job metadata, time series.

live

02

Identity

Workload identity: hardware ↔ time ↔ energy ↔ output.

live

03

Measure

Boundary-aware attribution + intensity per useful work.

live

04

Verify

Baselines, anti-fraud gates, AES scores, evidence seal.

live

05

Optimize

Scheduling / precision / placement recommendations.

later

06

Flex

Demand flexibility: deliverable kW, SLA risk, event shape.

sim

07

Registry

Issue, list, verify, retire with double-count guard.

live

08

Market

Bilateral then secondary — after methods + buyers mature.

later

09

Intelligence

Portfolio analytics, anomalies, counterfactual libraries.

later

10

Control

Closed-loop orchestration with utility signals.

later

NFET (honest scope)

Theoretical NFET is research on productive regimes in noisy, delayed, multiplex systems — not a finished law of emergence. Operational NFET is a control loop (observe → classify → act → verify) that may be useful before the theory is settled. An ops controller that works does not prove the theory.

AEX

Measure · verify · register · settle

MRV and commercial infrastructure for energy and flexibility performance.

live

NFET

Regime · envelope · delay-aware recommend

Ops v0 in Try it → tab 5. Recommendations only until an executor ACKs and meters move.

ops v0

QEV

Evidence integrity

Portable sealed artifacts; AEX already SHA-256 seals measurement packages.

product family

Full adversarial analysis: docs/NFET-AEX-INTEGRATION.md in the repo. Safe claim today: AEX measures; NFET-ops proposes constrained flex; certificates only from measured AEX verify.

Live now vs later

Working in this deployment

Energy attribution (6 boundaries)
Baseline + confidence
Class-specific AES scores
SHA-256 evidence packages
Verification decisions
Flexibility simulator
Pilot economics calculator
D1 registry API (issue / verify / retire)

Not claimed yet

Public token trading
Open secondary marketplace
Exchange license
One universal AI score
Hardware lifecycle credits
Global utility coverage
Perfect carbon accounting
Automatic tradable offsets from savings

Try it · operator console

Measure → verify → seal → register

1 Load example or enter your job · 2 Run · 3 Seal · 4 Issue. Nothing hits the registry until step 4.

01Measureidle

02Baselineidle

03Verifyidle

04Sealidle

05Issueidle

No run yet — load preset or set inputs, then Run engines —

Total energy

—

kWh attributed

Useful work

—

accepted units

Intensity

—

energy / work

Baseline energy

—

same work basis

Saved vs baseline

—

kWh delta

Intensity Δ

—

% improvement

AES score

—

class-specific

Verify

—

PASS / COND / REJECT

IN Workload identity

Customer / org Facility Region / grid zone Cluster Hardware Accelerators Model family Model version Precision AES class Measurement boundary

TEL Telemetry window

Duration (hours) Avg GPU power (W) GPU TDP (W) GPU utilization (0–1) Productive tensor util PUE Useful work (raw count) Quality pass rate Latency compliance Grid kgCO2e/kWh (opt) $ / kWh

BND Boundary scope select boundary

Device → server → rack → IT → facility → cloud. Only checked components enter e_total.

Accelerators

CPU

Memory

Storage

Network

Shared IT

Cooling

Power loss

OUT Measurement output

Total—

IT subtotal—

Intensity—

Metering—

Integrity—

Component kWh bars appear after Run engines.

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.

CFG Baseline configuration

Method Reference intensity (optional) Baseline total kWh (optional)

Baseline energy is scaled to the same accepted useful work. Doing less work cannot mint efficiency credits.

Δ Actual vs baseline

Run engines to compare actual energy to baseline on equal useful work.

OUT Baseline result

Awaiting measure pass
Baseline compares attributed energy against an approved reference intensity or historical total at equal useful work.

AES Dimensions class-specific

Run engines to populate AES dimension bars.

AES idle
Score is class-specific; do not compare across AES classes without normalization.

VRF Verification decision idle

Run engines to populate critical / major / info checks.

ID	Sev	Result	Check
No checks yet.

No decision
Verifier checks boundary fitness, quality floors, rebound flags, and claim strength before seal.

Registry

Issued proof records. Double-count blocked. Measurement instruments — not carbon offsets for sale.

Issued

—

Conditional

—

Retired

—

Active saved kWh

—

Workloads

—

ID	Status	Org	Saved kWh	AES	Evidence hash	Issued	Actions
Loading registry…

DET Certificate detail

No selection
Click View on a row to load certificate metadata and evidence summary from the registry.

AUD Recent audit events

No events loaded
Issue and retire actions append to the audit log.

VRF Verify evidence hash

Evidence hash

Idle
Lookup by evidence_hash. Local seal re-check runs if the hash matches the package sealed in this session.

API

GET  /api/health
GET  /api/stats
GET  /api/certificates[?status=&org_id=&evidence_hash=&limit=&offset=]
GET  /api/certificates/:idOrHash
GET  /api/audit[?entity_id=&limit=]
POST /api/issue          { "evidence": { ...sealed package } }
POST /api/verify         { "evidence_hash": "..." }
POST /api/retire         { "id"|"evidence_hash", "retired_by" }
POST /api/migrate        ensure D1 schema

Methodology (disclosed)

Versions used by live engines. Speculative market claims are excluded. What you measure is what you may claim — nothing more.

AEX-MEASURE-1.0

Energy attribution

Total workload energy = sum of boundary-included components:

Accelerators, CPU, memory, storage, network
Shared IT allocation
Cooling & power-loss via PUE split (75/25) when facility overhead is in-boundary

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, …).

AEX-BASE-1.0

Baselines

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.

AEX-AES-1.0

AI Efficiency Score

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.

AEX-VERIFY-1.1 · EVIDENCE-1.1

Verification & evidence

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.

A measured energy reduction is not automatically a tradable asset. Assets require unit definition, recognized methodology, ownership, real buyers, double-count rules, and legal recognition.

Pilot economics

Scenario calculator only — edit every input. Results are not revenue forecasts. Certificate price defaults to $0 (no assumed market).

Accelerators TDP (W) Avg utilization PUE $/kWh Demand $/kW-mo Intensity improvement Idle reduction Platform fee $ Success share Cert $/kWh (default 0)

Ideal first customer

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.

Ideal first utility partner

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.

Critical analysis

Harsh where weak. From the master brief — for operators who want the full argument.

Company restatement

What AEX actually is

A measurement and verification system that turns AI-compute efficiency and load flexibility into auditable records and bilateral economic outcomes. The “exchange” is aspirational infrastructure, not the day-one product.

Strongest wedge

Cost + peak demand first

Sell workload-level energy cost, idle waste, and demand-charge reduction with sealed evidence. Grid payments and certificates are upside layers — never the sole revenue story.

Moat

Methodology + evidence graph

Defensible baselines, useful-work definitions, double-count controls, and multi-party trust. Hardware telemetry alone is commoditized; verification libraries are not.

Failure mode

Most likely kill shot

Unverifiable baselines + greenwash buyers. If AEX issues soft credits without useful-work gates, it becomes another low-integrity market and serious buyers leave.

Regulatory

What depends on law

Secondary trading, environmental claim language, utility tariff participation, and anything marketed as an offset. MVP measurement SaaS avoids exchange licensing.

Competition

Adjacent categories

DCIM, cloud carbon tools, GPU observability, carbon accounting platforms, DR aggregators. None fully close: useful AI work × energy × baseline × settlement.

Business model

How money works now

Platform subscription + success share on verified operational savings and (when real) flexibility revenue. Optional certificate facilitation later — priced only when buyers exist.

Build verdict

Should AEX be built?

Yes — as measurement infrastructure. No — as a day-one credit exchange. This deployment implements the former with honest non-goals for the latter.

Three-year roadmap (honest)

Y1

Meter, attribute, verify, save

3–5 pilot clusters · rack/server metering · sealed records · DR simulation with one utility conversation.

now

Y2

Flex + bilateral settlement

Event verification · capacity nominations · enterprise reporting packs · independent audit partner.

Standardized instruments

Only if methodologies recognized and repeat buyers exist — then limited market infrastructure.

gated

Assumptions that require validation

Operators will share fine-grained job + power data with a third party.
Useful-work definitions can be standardized per class without gaming.
Utilities will accept AI load as a DR resource with AEX-grade metering.
Any secondary instrument price is non-zero — currently treated as $0 until proven.
Cloud-provider energy estimates can be cross-checked often enough to matter.

Prove what AI compute actually used.

The process (keep it this simple)

Point at a workload

Attach energy + useful output

Compare to a baseline

Seal & register

Use cases

Tenant & rack accountability

$/token and training cost

Defensible AI energy claims

Setup path

Use this console

Wire real systems later

How to use AEX

What you need

To try now

To trust the number

To integrate

Day-one walkthrough (15 minutes)

What operators actually need (field fit)

Integrate with your environment

Data you already have

How AEX consumes it

After a console run — readiness from your inputs

Registry API (live)

Roles (who does what)

Meters & boundaries

Jobs & useful work

Records & claims

Full capability

Every claim answers seven questions

Platform layers

NFET (honest scope)

Live now vs later

Working in this deployment

Not claimed yet

Measure → verify → seal → register

IN Workload identity

TEL Telemetry window

BND Boundary scope select boundary

OUT Measurement output

CFG Baseline configuration

Δ Actual vs baseline

OUT Baseline result

AES Dimensions class-specific

VRF Verification decision idle

PKG Evidence package unsealed

FLX Demand flexibility simulator

NFET Operational control cycle

Registry

Certificates

DET Certificate detail

AUD Recent audit events

VRF Verify evidence hash

API

Methodology (disclosed)

Energy attribution

Baselines

AI Efficiency Score

Verification & evidence

Pilot economics

Ideal first customer

Ideal first utility partner

Critical analysis

What AEX actually is

Cost + peak demand first

Methodology + evidence graph

Most likely kill shot

What depends on law

Adjacent categories

How money works now

Should AEX be built?

Three-year roadmap (honest)

Assumptions that require validation