Qira LLC · Brandyn Leonard & Bryan Leonard

The Energy Intelligence Layer for the AI Economy.

AI is becoming energy-constrained infrastructure. AEX treats AI compute not only as an electricity consumer but as a measurable, verifiable, and eventually dispatchable energy resource — beginning with the least contested layer: independent verification of whether claimed savings and flexibility are real.

—

Registry records live API

—

kWh on issued records live API

…

Registry API

Near-term focus Observe + Verify

Useful AI work

—

Energy attributed

—

vs baseline (counterfactual)

—

Verify decision

—

Three questions AEX exists to answer: What useful AI work occurred? How much energy did it require? What value was created by improving or shifting that use? Registry tiles above are live API only.

Core thesis

Markets cannot function without trusted measurement. The AI–energy economy needs an equivalent trust layer. The most valuable product in that layer is not an energy credit — it is trusted, defensible measurement of what actually happened.

1

Observe

Standardized telemetry across GPU clusters, cooling, and schedulers — the relationship between compute and energy, not just facility draw.

2

Verify

Turn telemetry into trusted evidence: baseline counterfactuals, statistical defensibility, audit trails, certificates. Primary near-term wedge — least contested.

3

Then Flex → Registry → Market → Control

Flexibility, settlement records, and orchestration only after methods and buyers are real. Head-on Flex/Control against Emerald, Nvidia, and Google is intentionally not day one.

Six platform layers

Progressively more valuable. Layers 1–2 are the near-term build; 3–6 are the long-term vision where competition is fiercest.

01

Observe

GPU / facility / scheduler telemetry — compute↔energy relationship.

near-term

02

Verify

Baseline engine, statistical gates, evidence seal. Home of proposed NFET-Verify.

primary wedge

03

Flex

Shift flexible workloads to grid/price signals. Contested — Emerald, Nvidia, Google active.

contested

04

Registry

Serialized certificates, ownership, retirement, provenance — depends on Verify credibility.

live slice

05

Market

Bilateral then standardized contracts backed by verified evidence. Emerging (e.g. EPRI DCFlex).

later

06

Control

Autonomous placement across price, congestion, and carbon. Most contested long-term.

later

Why Verify is the wedge

Strategic judgment — not yet tested in market. The field is not empty; Flex/Control already has a multi-year head start.

Emerald · Nvidia · Google

Flex & Control active

Grid-aware workload shifting, flexible AI factories, utility DR pilots. Fighting head-on there means competing with hyperscaler partnerships from a standing start.

EPRI DCFlex · MRV tools

Standards & adjacent MRV

Capacity frameworks and corporate carbon MRV exist, but few close the loop on useful AI work × energy × baseline × independent verification.

AEX entry

Complementary trust layer

Independent, statistically rigorous verification of claimed savings and flexibility — complementary to Flex vendors, not a me-too orchestrator.

The baseline engine

Core IP candidate. Savings require a counterfactual: how much electricity should this workload have used, absent the intervention? That means normalizing hardware, model shape, context, batching, ambient temperature, PUE, retries, geography, and complexity — exactly the class of problem NFET’s statistical machinery was built to attack.

Today · console

Measure → baseline → seal

Open Try it and load example or your numbers.
Attribute energy under an explicit meter boundary.
Compare to a same-useful-work baseline; read verify decision.
Seal evidence; optionally issue to the live registry.

Hypothesis · not validated

NFET-Verify

Network-statistical auditing for energy & flexibility claims: null baselines, z-score ridge detection (z > 1.96), bootstrap CIs, burn-in windows, multiplex coupling (γ) for leakage. Validated so far only on traffic-network research — not on energy telemetry.

Not a day-one Flex/Control product

Not a carbon marketplace

Not claiming NFET is proven on energy

Not blockchain-first settlement

Full stack, NFET pilot criteria, economics, and risks under · operator walkthrough under .

Operator guide · Observe + Verify

How to use AEX

Practical path for datacenter ops, AI platform teams, and energy leads. This is the near-term wedge from the concept overview — not Flex/Control productization.

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.

Concept overview · Version 1 · July 2026

Architecture, NFET-Verify, and honest risks

AEX: the Energy Intelligence Layer for the AI Economy. Mission — become trusted measurement, optimization, and settlement infrastructure connecting AI with the energy system, starting with verification.

The three questions

The industry lacks a trusted system that answers all three. AEX is designed around them.

01

What useful AI work occurred?

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

Observe

02

How much energy did it require?

Attributed under an explicit meter boundary.

Observe

03

What economic value from improving or shifting that use?

Only after a defensible baseline and verification — never a bare point estimate.

Verify

Six layers (canonical)

From the concept overview. Near-term = Observe + Verify. Flex/Control face Emerald, Nvidia, Google.

1

Observe

Standardized telemetry across clusters, cooling, schedulers — compute↔energy, not electricity alone.

near-term

2

Verify

Trusted evidence: baselines, statistical defensibility, certificates. Least contested — primary focus. NFET-Verify lives here.

primary

3

Flex

Identify flexible workloads; respond to grid/price signals.

contested

4

Registry

Serialized certificates, ownership, retirement, provenance.

depends on Verify

5

Market

Bilateral then standardized contracts backed by verified evidence.

emerging

6

Control

Long-term autonomous placement on price, congestion, carbon.

most contested

Validation status (injected + real meters)

File-backed runs under the Python pilot repo. FAIL is reported as-is — thresholds are pre-registered.

0

Synthetic A–E pilot

Full demo re-run: precision 1.0 · FP 0% · accuracy 100% vs naive ~0.21.

PROVED

1a

BDG2 + known 12% inject

n=40: certified MAE 4.9% (from 9.5%); gate catch 58%; CI ~60–67% — not 95%.

PROVED (gate)

1b

BDG2 × scenarios A–E

E PROVED (0% FP, 93% detect). Full battery NOT proved (A recall 73%, B 47%, D 27%).

partial

1c

vs CalTRACK

MAE 7.0% vs 7.4% — tie. Not “beats CalTRACK.”

tie

2

Multi-meter leakage

12 pairs: refuse 8%, detect 50% — PROVED.

PROVED

4

GPU/PDU wire + demo verify

Exporter path PROVED (demo end-to-end). Production AI energy validation NOT proved.

wire proved

Safe external language today: measurement + verify gates + sealed records on disclosed boundaries. Not “NFET-Verify validated on production AI energy.”

NFET-Verify — honest status

HONEST STATUS. NFET’s applied layer is proof-of-concept (C+/B–), validated on a 207-node traffic network (METR-LA), not on energy or workload telemetry. The structural fit below is a well-reasoned hypothesis — not a validated result. Do not represent NFET-Verify as a proven capability until the pilot passes and a real-telemetry pass follows.

Network-Statistical Auditing for Energy & Flexibility Claims. Maps NFET machinery onto AEX Verify: null baselines, z-score ridge detection (z > 1.96), bootstrap CIs, burn-in windows, multiplex interlayer coupling (γ) for leakage.

NB

Null baselines

κ=0, neighbor shuffle, degree-preserving permutation → rigorous counterfactuals vs historical-average gaming.

hypothesis

Z

Z-score ridge (z > 1.96)

Significance threshold on certificates — not a bare % point estimate.

hypothesis

CI

Bootstrap confidence intervals

Savings as ranges with defensible uncertainty.

hypothesis

γ

Multiplex coupling

Catch leakage — energy shifted off-boundary, not reduced. Hardest single-layer failure mode.

key test

Validation pilot (pre-registered)

Synthetic ground truth first. Scored yes/no against criteria stated in advance — same discipline as LOLM Proof Pack reporting.

A

Genuine savings

Known real reduction (e.g. ~12%) with realistic noise. Must flag as significant; CI contains true effect.

must catch

B

Confounded

Drop from weather/hardware/retries — not intervention. Must not flag as real savings.

must refuse

C

Baseline gaming

Cherry-picked “before” window. Must not flag as real savings.

must refuse

D

Pure noise

Chance false positive for naive methods. Must not flag.

must refuse

E

Leakage

Energy shifted outside boundary. Differentiating test vs single-layer/naive baselines.

hardest

Deliverable is NFET vs naive baseline on precision and recall — not NFET in isolation. Console “NFET ops” tab is an operational control sketch; it does not certify NFET-Verify on energy data.

Economic model (near-term order)

1–2 primary

Platform + verification services

Subscriptions for monitoring/optimization, and verification for utilities, operators, and regulators — where NFET-Verify would differentiate if validated.

3–6 later

Flex share · registry · forecast · market fees

Flexibility revenue share, registry services, forecasting, then marketplace fees — intentionally last, not the starting business.

Live console vs concept claims

Working in this deployment

Observe-style attribution (boundaries, useful work)
Baseline + rule-based verify + seal
SHA-256 evidence packages
D1 registry (issue / verify / retire)
Flex & pilot economics as scenario calculators
NFET ops tab as control sketch (not energy validation)

Not claimed externally

NFET-Verify validated on energy telemetry
Day-one Flex/Control vs Emerald / Nvidia / Google
Public carbon trading or automatic offsets
Exchange license or secondary market
One universal AI efficiency score
Guaranteed utility payments

Observe + Verify · operator console

Measure → baseline → verify → seal → register

Near-term AEX loop (concept layers 1–2 + registry slice). 1 Load example or enter your job · 2 Run · 3 Seal · 4 Issue. Nothing hits the registry until step 4. NFET-Verify statistical pilot is separate from this console path.

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.

Open questions and honest risks

From Concept Overview v1 — stated so external framing cannot overclaim.

Company restatement

What AEX actually is

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.

Strongest wedge

Independent Verify

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.

Moat candidate

Baseline engine + evidence graph

Defensible counterfactuals, useful-work definitions, double-count controls. Hardware telemetry is commoditized; verification libraries and methods are not.

Platform risks

Go-to-market & competition

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

NFET-Verify risks

Unvalidated on energy

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.

Failure mode

Soft credits / greenwash

If AEX issues unverifiable baselines or soft claims without useful-work gates, it becomes another low-integrity market and serious buyers leave.

Competition map

Who is already here

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.

Build verdict

Should AEX be built?

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.

Recommended next steps (from overview)

1

Synthetic pilot generator

Five scenarios A–E; run NFET pipeline against pre-registered criteria before external NFET-Verify framing.

required

2

Verify wedge customer

Utility or DC operator pilot on real telemetry — independent of the NFET question.

GTM

3

Second validation pass

If synthetic passes: real workload-energy telemetry before outreach that names NFET-Verify as capability.

gated

4

Track competitors

EPRI DCFlex + Emerald public baseline/verification practice — the gap AEX aims to fill.

ongoing

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 — treated as $0 until proven.
NFET methods transfer from traffic networks to energy multiplex systems (unproven).

The Energy Intelligence Layer for the AI Economy.

Core thesis

Observe

Verify

Then Flex → Registry → Market → Control

Six platform layers

Why Verify is the wedge

Flex & Control active

Standards & adjacent MRV

Complementary trust layer

The baseline engine

Measure → baseline → seal

NFET-Verify

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

Architecture, NFET-Verify, and honest risks

The three questions

Six layers (canonical)

Validation status (injected + real meters)

NFET-Verify — honest status

Validation pilot (pre-registered)

Economic model (near-term order)

Platform + verification services

Flex share · registry · forecast · market fees

Live console vs concept claims

Working in this deployment

Not claimed externally

Measure → baseline → 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

Open questions and honest risks

What AEX actually is

Independent Verify

Baseline engine + evidence graph

Go-to-market & competition

Unvalidated on energy

Soft credits / greenwash

Who is already here

Should AEX be built?

Recommended next steps (from overview)

Assumptions that require validation