Skip to content
Iverson GPU

Objection handling

The questions a skeptical evaluator should ask.

These are the objections we hear, stated as sharply as we know how, answered without hedging. If your version is sharper, we want to hear it.

"The Philly trace is from 2017."

It is — and it is still the largest public multi-tenant GPU trace with per-job timing, which is why it is the benchmark. But the claim we make on it is not "2017 numbers describe your cluster." The claim is paired comparisons: every policy runs the same trace, the same faults, the same seeds, and what we report is the gap between them — plus the knee moving across 15 modeled estates, which is a structural result about workloads, not a vintage one. Revalidation on newer public traces is on the roadmap.

And the part that actually matters to you: week one runs on YOUR cluster, not on any trace. The trace earns the meeting; your snapshot earns the deal.

"It's all simulation."

Correct — for the controller benchmarks. Those are held to the paper's reference implementation within 1e-6 relative tolerance (job counts exact) by 39 pinned parity tests, and reproducible in your own browser at /frontier. We say "simulated" on every one of those numbers because that is what they are.

The Exposure Report is not simulation — it is measurement: computed from your cluster's snapshot, rendered in your browser. The simulator argues the controller works; the report shows what your estate is doing right now.

"Our Grafana already shows this."

Grafana shows you utilization and temperatures — state. It does not price the blast radius of a consolidation before you approve it, name which automation loops fought at 02:00 with a dollar figure attached, or decompose your "free" capacity into the part that is safely usable versus the part that is fragments and lemon nodes. Iverson reads the same signals and answers a different question: not "what is happening" but "what should change, what does it cost, and what does it risk." Complement, not replacement — keep the dashboards.

"CAST AI / ScaleOps already optimize us."

Keep them. They move the efficiency number, and they are good at it. What they do not do is price the risk their own moves create — the consolidation that quietly stacks your critical serving fleet onto one failure domain, or the two optimizers that fight each other nightly because neither knows the other exists. Iverson sits above the loops: it prices each proposed move against a blast-radius floor and referees when automations disagree. Start as the governor over your existing optimizers; over time, the layer that prices every decision tends to become the layer that makes them.

"You model single-feed topologies — my racks are dual-corded."

Declare it, and it is modeled: topology v2 takes feeds: [ups-a, ups-b] on any domain, and a domain with redundant feeds is lost only when all of its feeds are lost. Dual-corded A/B power and N+1 cooling stop being worst-case fiction the moment the map says they exist — and the validator refuses maps with cycles or orphan feeds, because a broken chain would silently understate every blast-radius number.

Until the map says so, we do not guess redundancy into existence: a single-feed topology is labeled worst-credible-case on every closure number it produces. Unmapped redundancy is never silently assumed — in either direction.

"Redundant feeds on paper aren't redundant under load."

Agreed — and the product now says this itself. Declare ratedKw on your feeds and the failure closure checks electricity, not just graph edges: a dual-fed domain that keeps a live feed is still demoted to lost when the surviving feeds' combined rating is below its measured load. Graph redundancy is not electrical redundancy.

Proven on our lab cluster: with feeds rated 8 kW and 4 kW under a 6 kW load, losing the weak feed is survivable — losing the strong one is a real outage that a pure graph model would have called "redundant". And where a surviving feed carries no rating, the report labels the domain electrically unverified instead of silently promoting it to safe. The exact inequality is on /methodology.

"A snapshot is stale the moment you act on it."

True — which is why the report says so instead of hoping you will not notice. Every report carries its snapshot age, stamped from the collector's own timestamp, and consequence surfaces warn loudly past 24 hours — curtailment planning especially, because a shed plan computed from yesterday's estate is a plan for yesterday's estate. Re-collecting is one command and minutes of runtime: the workflow is collect, decide, act — not collect in January, act in March.

What the snapshot model buys in exchange: nothing resident in your cluster and nothing streaming out of it. That trade is stated, not hidden — and it holds until a resident collector earns its way in.

"You're a solo founder."

Yes. Three things make that a risk you can size rather than a leap of faith: a sibling governance product has been live in production for over two years, so this is not a first system; the engineering discipline is in the open — CI, pinned parity tests, golden files you can run yourself; and the product's own blast radius is near zero by construction — the agent is read-only (get/list, no write verbs), so the worst case of the vendor disappearing is a report that stops updating, not a cluster that breaks.

Every claim above is checkable: the sweep at /frontier runs in your browser, the parity and golden tests ship in the repo, and the Exposure Report computes from your own snapshot.