The OptiGPU Evidence Standard

The rules

1. R1Observed spend is never called waste on its own.
2. R2Missing evidence never becomes a dollar figure.
3. R3An estimate needs measured evidence and carries a low bound.
4. R4Estimates are ranges, and overlapping lenses never add up.
5. R5Only a later invoice can mark savings as verified.
6. R6Public figures are aggregated, delayed and rounded down.

The interactive demo uses clearly labeled synthetic data. The billing snapshot analyzes only your upload. Neither is presented as customer proof or a savings guarantee. Supported providers: AWS, Google Cloud, Azure and CoreWeave, read-only.

R1 What the billing snapshot proves

Observed spend is never called waste on its own.

The public snapshot reads an uploaded CSV locally in the browser. It identifies positive cost rows, GPU resource families, the covered period, provider scope, and any supplied region, account, resource, owner, workload, utilization, memory, or queue fields.

Observed GPU spend is not labeled as waste. A high-cost family is a review priority, not proof that the cost is avoidable.

observed GPU spend = Σ positive uploaded cost rows
                     matching supported GPU resource patterns

R2 Fail-closed evidence gate

Missing evidence never becomes a dollar figure.

If utilization, scheduler demand, or workload class is missing, the snapshot shows the missing evidence and does not calculate a dollar saving from spend alone.

Other optimization models (rightsizing, commitments, regional moves, inference autoscaling, queue packing, or failure waste) require their own utilization, pricing, compatibility, workload, or operational evidence. They belong in an evidence report or connected workspace when those inputs are available.

missing required evidence → no estimate
unknown stays unknown: never zero, never a marketing rate

R3 When OptiGPU can estimate a saving

An estimate needs measured evidence and carries a low bound.

The browser snapshot models an idle-timeout policy only for notebook, CI, or batch workloads with measured GPU utilization below 20%, measured queue depth equal to zero, and measured paid idle GPU-hours covering every billing row in the supplied period.

The visible action still requires an owner to validate session persistence, checkpoints, running kernels, and restart behavior before implementation.

Dashboard reports, built from an uploaded or connected bill, price each finding from its own measured evidence. The midpoint is the gross saving times a factor for the action, from 0.25 for rightsizing to 0.95 for deallocating an idle resource, and confidence in the evidence sets the range. Each finding page shows its own gross saving, factor and range.

A finding that is not owner-ready yet shows its range, labelled under review, and stays out of every total until an owner validates it.

browser snapshot
  midpoint  = observed lane cost × measured paid idle fraction × 0.60
  low bound = midpoint × 0.75
dashboard report
  midpoint  = gross saving × action factor (0.25 to 0.95)
  low bound = midpoint × 0.85 · 0.65 · 0.35   (high · medium · low confidence)
  high      = midpoint × 1.10 · 1.25 · 1.50, never above the gross saving

R4 Headline range and overlap

Estimates are ranges, and overlapping lenses never add up.

Only findings that pass their evidence gate can contribute to the preliminary headline. Review lenses that cover the same spend are marked non-additive.

The result shows a range rather than implying false precision. Each included finding exposes its observed inputs, assumptions, and formula while deeper row-level evidence remains gated.

headline (low, midpoint, high) = Σ included non-overlapping finding ranges
needs-evidence findings contribute 0 and are not included

R5 From estimate to bill-verified savings

Only a later invoice can mark savings as verified.

An estimate becomes bill-verifiable only after an owner approves an action, the implementation date is recorded, and a completed later billing period can be compared with the completed baseline.

Continuous and Scale provide the recurring provider sync, action tracking, drift monitoring, and later-bill comparison needed for that lifecycle. OptiGPU does not make infrastructure changes.

For a contract-covered production workspace, a bill-verified realization enters the exact internal aggregate under the customer’s standing authorization. Only the privacy-buffered daily milestone can appear publicly.

bill-verified = baseline scope + approved action
              + implementation date + comparable later billing evidence

R6 Daily public customer-savings milestone

Public figures are aggregated, delayed and rounded down.

The homepage milestone is separate from every synthetic sample. It includes only completed customer billing periods from a reviewed production workspace, savings OptiGPU has verified against a later bill, and a recorded customer agreement that gives standing authorisation for aggregate reporting. No per-saving approval is required.

OptiGPU retains the exact signed amount internally in integer cents. The public figure is recalculated at most once per UTC day, rounded down to the preceding $10,000 milestone, and published only after at least three distinct eligible customers have contributed since the previous public update. It appears only when the internal verified total is greater than $100,000.

Corrections and contract revocations append signed adjustments; history is not overwritten. Customer names, individual amounts, billing rows, and evidence remain private. The milestone is described as aggregated, not anonymous.

public milestone = ⌊ exact signed contract-covered total ⌋ to the preceding $10,000
published daily, only after a three-customer contribution batch

Worked example

Illustrative figures, not customer data. A notebook pool costs $10,000 in the uploaded period. Every row has measured paid idle GPU-hours covering 80% of the billed period, plus measured utilization and zero queue depth, so R3 allows an idle-policy estimate.

midpoint  = $10,000 × 0.80 × 0.60 = $4,800
low bound = $4,800 × 0.75        = $3,600

The finding shows $3,600 to $4,800 as an estimate, not a saving. If the same pool had no utilization data, R2 applies: the finding reads “needs utilization evidence” and carries no figure. Once an owner approves the change and a later invoice for a comparable period arrives, R5 decides whether any of it is bill-verified.

Limitations

• CSV analysis depends on the period and columns supplied by the user.
• Currency is kept in the source currency; mixed-currency uploads are rejected.
• Recommendations remain review actions until a human owner validates the change.
• Later billing data can verify a financial change, but does not prove causation without comparable scope and timing.
• A reproducible calculation is not independent assurance. Reports disclose assurance status and block public sharing when required evidence or coverage is incomplete.

Changelog

Reports generated from 1 October 2026 name the version they followed. When a rule changes, the version changes and the entry here says why.

v1.0 — 1 October 2026

First published version, rules R1–R6.