What is GPUVerse? The Intelligence Layer for AI Infrastructure

Deploying a web application in 2026 is a solved problem. You push to a branch, a platform builds a container, and something reasonable runs a few seconds later. Deploying an AI workload is not a solved problem. Choosing where an H100 cluster should live — which of a dozen providers, which region, which GPU generation, which cluster topology, at which price, under which compliance regime — is still a research project that a senior infrastructure engineer runs by hand, in spreadsheets, over days.

GPUVerse exists to close that gap. It is the intelligence layer above every cloud: a system that takes a description of the workload you want to run and returns a deterministic, explainable, deployment-ready recommendation for the infrastructure that should run it. This article explains what GPUVerse is, the specific problems it targets, the ComputeOps category it defines, how the Discover decision engine actually works under the hood, and where the roadmap goes from here.

What GPUVerse is (and what it is not)

GPUVerse is a decision and control plane for AI compute. You describe intent — "serve a 70B-parameter model at low latency in the EU under 8 thousand dollars a month" — and GPUVerse determines the infrastructure. It compares providers, selects a GPU or TPU, chooses a region, sizes the cluster, estimates the monthly cost, generates a deployment architecture, and hands you an explanation you can defend in an architecture review.

The distinction that matters most is what GPUVerse deliberately is not:

• Not a GPU marketplace. It does not list capacity for sale or take a cut of a rental. It has no incentive to steer you toward a particular provider.
• Not a cloud provider. It owns no data centers and racks no hardware. It reasons about the providers that do.
• Not a Kubernetes platform or a scheduler. It decides what to run where; it is not the thing that pins pods to nodes.
• Not a Model-as-a-Service vendor. It does not host models behind an API and bill per token.

That negative space is the whole point. Because GPUVerse never sells the compute it recommends, its recommendations can be genuinely provider-neutral. A marketplace is structurally incentivized to fill its own inventory; an intelligence layer sitting above the market is free to say "the cheapest correct answer for this workload is Vast.ai, but if you need FedRAMP it is Oracle, and here is exactly what that costs you."

GPUVerse sells judgment, not GPUs. The moment a recommender also owns the inventory, its advice stops being trustworthy.

Why GPUVerse exists: the real problems

The AI-infrastructure market grew faster than the tooling to navigate it. Five concrete problems compound on top of each other, and each one alone is enough to consume an engineer's week.

1. GPU scarcity

High-end accelerators are supply-constrained and unevenly distributed. The H100 you want may be available in us-east-1 today and gone tomorrow; a B200 allocation may require a reservation lead time measured in weeks; a spot A100 might be the cheapest thing on the market until it is preempted mid-run. Availability is not a static fact about a provider — it is a moving quantity that varies by hardware generation, region, and billing mode. Any honest recommendation has to treat availability as a first-class, time-sensitive signal, not a footnote.

2. Cloud fragmentation across 10+ providers

There is no single place to run AI. There are hyperscalers (AWS, Google Cloud, Azure, Oracle), neoclouds specialized in GPU compute (CoreWeave, Lambda, Nebius, Crusoe, RunPod), and marketplaces (Vast.ai). Each has its own catalog, its own region naming, its own billing granularity, its own certifications, and its own idea of what "an H100 instance" even means. Comparing them is not a lookup — it is a normalization problem. Before you can rank two options you have to make them comparable, and that alone is most of the work.

3. Opaque, non-comparable pricing

A dollar-per-hour number is nearly meaningless on its own. On-demand versus spot versus reserved pricing differ by multiples. Egress, storage, and licensing hide in the fine print. And the number that actually matters for an AI workload is not dollars per hour but dollars per unit of useful work — dollars per million tokens served, or dollars per training step. Two GPUs at the same hourly price can differ by 2x in real cost efficiency once you account for throughput. Translating raw price sheets into that comparable unit is exactly the arithmetic teams get wrong.

4. Deployment complexity

Even after you have chosen a provider and a GPU, standing up the workload correctly is non-trivial: the right instance shape, the right interconnect (InfiniBand versus PCIe matters enormously for multi-node training), the right quantization, the right serving stack, the right region for data-residency compliance. The knowledge required is broad and shallow-per-provider, which is the worst combination for a human to hold in their head.

5. The infrastructure-planning burden

Add all of the above together and the result is that a capability every AI team needs — sound infrastructure decisions — depends on scarce, expensive senior engineers doing repetitive comparison work by hand. That work is slow, it is inconsistent between engineers, and it is rarely written down in a form anyone can audit later. When the decision is wrong, the bill or the latency SLA tells you months afterward.

ComputeOps: the category

GPUVerse defines a category for this work: ComputeOps. The analogy is deliberate. DevOps gave application teams a discipline and a toolchain for shipping software reliably. FinOps gave organizations a discipline for governing cloud spend. ComputeOps is the equivalent discipline for AI compute — the practice of continuously deciding, deploying, observing, and optimizing where AI workloads run, across every provider, as a first-class engineering function rather than an ad-hoc scramble.

Under that banner, GPUVerse's identity is the AI Infrastructure Engineer: not a dashboard you operate, but a system that does the infrastructure-engineering reasoning for you and shows its work. The long-term vision is the AI Compute Control Plane — making the act of deploying an AI workload as simple as deploying a web application. Today the product delivers the first and hardest piece of that vision: the decision.

The providers and accelerators GPUVerse reasons over

GPUVerse maintains a canonical, continuously refreshed catalog of 10 providers and 54 GPU/TPU instance types. The catalog is the substrate every recommendation is computed against, so its accuracy and normalization are load-bearing.

The 10 providers

The three categories behave differently and the engine models that. Hyperscalers publish stable public region codes (AWS us-east-1, GCP us-central1, Azure eastus, OCI us-ashburn-1) and carry the deepest compliance certifications. Neoclouds and marketplaces often omit fixed regions entirely — for RunPod, Vast.ai, and Lambda, location varies by host or listing, so the catalog intentionally records no region set rather than inventing one. That asymmetry is not a data gap; it is a faithful representation of how those providers actually sell capacity, and the engine treats residency accordingly.

The accelerator catalog

The 54 instance types span six hardware families, from prosumer Ada Lovelace cards up to datacenter Blackwell superchips and Google's TPUs:

Each instance carries structured metadata: architecture, generation, memory type (HBM2e / HBM3 / HBM3e / GDDR6 / GDDR6X / GDDR7), memory bandwidth, FP16 tensor throughput in TFLOPS, and the workload types it suits (inference, training, fine-tuning, rendering). Eight-GPU SXM systems — HGX, ND, a3, p5 — are summed into cluster line items so that multi-node deployments can be reasoned about as a unit rather than a pile of single cards.

Keeping the catalog honest

A decision engine is only as good as the facts it reasons over, and those facts decay fast. GPU prices move weekly, spot markets move by the minute, availability shifts with demand cycles, and providers refresh hardware generations on their own schedules. A stale catalog does not fail loudly — it quietly recommends a price that no longer exists.

So catalog freshness is treated as a product, not a cron job. A gated ingestion pipeline crawls provider documentation and pricing, normalizes it into the canonical shape the engine expects, and refreshes the catalog on a cadence tuned to how quickly each fact changes. On-demand pricing has a tighter freshness budget than provider metadata; spot pricing tighter still; certifications the loosest. When a fact goes stale beyond its budget, the engine can lower confidence or withhold a candidate rather than quote a number it no longer trusts. Alongside ingestion, a pgvector-backed Knowledge Platform provides grounded, retrieval-augmented answers about that documentation — with citations, a confidence score, and a refusal below threshold — so the conversational Advisor can cite a real source rather than improvise one. And a read-only Analytics layer rolls up recommendations, plans, projects, and workloads per organization, so a team can see how its infrastructure decisions have trended over time. None of these write into the decision path; they inform and surround it.

How Discover works

Discover is the first shipped GPUVerse product and the heart of the system: an explainable infrastructure decision engine. You give it a WorkloadInput; it returns a RecommendationReport. Everything else — the planner, the conversational advisor, projects, analytics — composes on top of this core.

The most important architectural decision in Discover is that there is no LLM in the ranking loop. The engine is a deterministic pipeline: a constraint filter, followed by a weighted multi-dimensional evaluation, followed by a stable ranking. The same input always produces the same output, and every output is immutable and append-only. We will come back to why that matters, but keep it in mind as we walk the pipeline.

The input: describing a workload

A WorkloadInput captures both what you are running and what you care about: workload type (inference, training, fine-tuning, RAG, or batch), the model and its size, the scale, latency priority, region preference, budget ceiling, compliance requirements, the optimization goal, plus finer knobs — framework, quantization, sequence and context length, concurrency, whether spot capacity is acceptable, and whether the deployment is multi-node. The richness matters: the more the engine knows, the tighter and more confident the recommendation.

Phase one: hard-constraint filtering

Before anything is scored, a pre-filter removes every candidate that violates a hard constraint. If you require HIPAA, providers without a HIPAA certification are gone — not penalized, gone. If you require 80 GB of VRAM, anything smaller never reaches the scoring stage. If you pinned a region, candidates elsewhere are eliminated.

This filter-then-rank separation is not a stylistic choice; conflating the two is one of the most common recommender bugs. Filtering is boolean and removes candidates outright. Ranking is graded and merely orders what survived. GPUVerse enforces a strict two-phase architecture so that a soft preference can never silently override a hard requirement.

Phase two: the six-dimension scoring model

Every candidate that survives filtering is a (provider, GPU configuration, region) tuple, and each is scored independently across six dimensions:

Each dimension produces a normalized score in the interval from 0 to 1. For a measurable quantity like cost efficiency, the engine uses min-max normalization across the surviving candidate set:

where $v_i(c)$ is the raw value of dimension $i$ for candidate $c$, and the min and max range over all surviving candidates $j$. The dimensions are then combined into a single overall score by a weighted sum:

The weight vector $w$ is what makes the recommendation yours. If your stated optimization goal is cost, cost carries more weight; if you flagged low latency as critical, performance and availability rise. The weights are derived from your explicit inputs, not guessed, and they are reported back to you so you can see exactly how the trade-off was struck.

The cost dimension deserves a note, because it is where naive comparisons fail. The engine does not rank on dollars per hour. It ranks on dollars per unit of useful work. For an inference workload, the comparable unit is cost per million tokens:

where $p_{\text{hour}}$ is the effective hourly price (after spot discount, plus amortized egress and storage) and $T$ is sustained throughput in tokens per second. A GPU that costs 40 percent more per hour but serves twice the throughput is cheaper on the axis that matters — and the engine sees that where a price sheet does not.

A worked example: two H100 options

To make the arithmetic concrete, take two candidates that survive filtering for a 70B-parameter inference workload. Option A is a cheaper marketplace listing; Option B is a pricier neocloud instance with a stronger serving stack and interconnect.

Plugging Option B into the cost-per-token formula:

Option B is 34 percent more expensive per hour, yet roughly 26 percent cheaper per million tokens because it sustains 83 percent more throughput. A naive dollars-per-hour comparison would pick A and quietly overpay for the life of the deployment. The engine picks B on the cost dimension — and then still weighs A's lower absolute hourly cost, B's better availability or interconnect, and every other dimension before producing a final ranking. The point of the worked example is not that neoclouds always win; it is that the unit of comparison is the thing teams get wrong by hand, and the engine gets right by construction.

Phase three: stable ranking and diversity

Scored candidates are sorted into a stable ranking. A diversity term then prevents the result set from collapsing into five near-identical variants of the top option: candidates too similar to a higher-ranked one on the feature vector (GPU model, provider, price tier, region) are penalized, so the alternatives you see are genuinely different choices, not A/B clones of the winner.

Discover surfaces the top recommendation plus three deliberately distinct alternatives, each framed around a different priority:

• Lowest cost — the cheapest correct answer.
• Best performance — maximum throughput or lowest latency, cost secondary.
• Enterprise-ready — the strongest compliance and reliability posture.

The output: an explainable RecommendationReport

The RecommendationReport is not a single line. It contains the recommended provider, GPU or TPU, and region; the estimated monthly cost with an itemized breakdown; predicted performance and availability; a confidence score; structured reasoning; acknowledged trade-offs; a generated architecture diagram; a deployment checklist; and the three alternatives above.

The explanation is the product. Every recommendation answers, in plain terms, "why this over the next best option?" — and it does so with structured explanations assembled from computed facts, not free-text prose. A representative explanation reads:

RECOMMENDED: CoreWeave — H100 SXM x 8, us-east
Primary reason: 31% lower cost-per-TFLOPS than the next best match
Trade-off: ~2-week reservation lead time vs. 3 days on Lambda
Cost estimate: $14.72/hr (GPU $12.40, egress ~$0.80, storage $1.52)
Confidence: Medium — grounded in current catalog pricing and SLA history

Because the explanation is built from the same computed values that drove the ranking, it cannot drift away from the decision. There is no separate narration step that might describe a different answer than the one the engine actually chose.

The report shape, at the API boundary, looks roughly like this:

{
  "recommendation": {
    "provider": "CoreWeave",
    "accelerator": { "model": "H100 SXM", "count": 8, "vramGb": 640 },
    "region": "us-east",
    "monthlyCostUsd": 10598,
    "scores": {
      "cost": 0.91,
      "performance": 0.95,
      "availability": 0.72,
      "reliability": 0.87,
      "compliance": 1.0,
      "residency": 1.0
    },
    "confidence": "medium"
  },
  "alternatives": [
    { "kind": "lowest_cost",     "provider": "Vast.ai" },
    { "kind": "best_performance","provider": "CoreWeave", "accelerator": "GB200" },
    { "kind": "enterprise_ready","provider": "AWS" }
  ],
  "explanation": { "primaryReason": "...", "tradeoffs": ["..."] },
  "architecture": { "diagram": "...", "checklist": ["..."] }
}

And the call itself is a single authenticated, organization-scoped request:

curl -X POST https://api.gpuverse.ai/api/v1/recommendations \
  -H "Content-Type: application/json" \
  --cookie "$GPUVERSE_SESSION" \
  -d '{
    "workloadType": "inference",
    "model": "llama-3-70b",
    "latencyPriority": "high",
    "region": "eu",
    "budgetMonthlyUsd": 8000,
    "compliance": ["ISO27001"],
    "optimizationGoal": "cost"
  }'

Architecture generation and the Planner

A recommendation that stops at "use these GPUs" is only half an answer. Discover feeds directly into the Planner, a shipped product that consumes a recommendation and produces an InfrastructurePlan — a deployment-ready architecture with the topology, the region layout, and the checklist needed to actually stand the workload up. The planner reuses the same engine rather than re-deriving anything, so the plan and the recommendation never disagree. A saved, versioned plan is the artifact you export and, eventually, deploy.

Why deterministic, and why no LLM in the loop

It would be easy to bolt a large language model onto the ranking step. GPUVerse deliberately does not, and the reasons are engineering reasons, not ideological ones:

• Reproducibility. Infrastructure decisions move real money and get audited. The same workload must produce the same recommendation today, next week, and in a compliance review a year from now. A deterministic pipeline gives you that; a sampled model does not.
• Explainability you can trust. When the ranking is a weighted sum over computed scores, the explanation is a fact about the computation, not a plausible-sounding story generated after the fact. There are no hallucinated justifications because there is no generative step in the decision.
• No fabricated capabilities. The engine can only ever recommend a provider, GPU, region, or price that exists in the canonical catalog. It cannot invent a data center or misquote a cost.

This is also where the language model does live: not in the decision, but around it. The Advisor is a conversational layer over Discover. It uses deterministic intent detection to understand what you are asking, and its replies are grounded in subsystem outputs — engine and planner results, and citations from the retrieval-augmented Knowledge Platform — rather than free improvisation. It will never fabricate a provider capability or a cost, because it is only ever summarizing computed answers. The model handles the conversation; the engine makes the call.

Edge cases and honest failure

The hardest part of a recommender is not the happy path — it is behaving well when the world does not cooperate. A system that always returns a confident top pick is lying some of the time. GPUVerse is built to fail honestly, and the failure modes are designed, not accidental:

• No provider qualifies. When hard constraints are jointly unsatisfiable — say, 99.99 percent uptime and the lowest possible cost and a region where no qualifying provider operates — the engine does not silently substitute a requirement. It returns the closest matches and states exactly which constraint was relaxed and by how much, so the human can decide which promise to loosen.
• Impossible budget. If the cheapest correct configuration exceeds the stated ceiling, the engine says so and shows the gap, rather than recommending undersized hardware that will miss the latency target and generate a support ticket in a week.
• Compliance conflict. If a required certification eliminates every provider in a required region, that is surfaced as a conflict to resolve, not smoothed over.
• Sparse or stale data. When the catalog lacks fresh enough pricing or availability for a candidate to be scored confidently, the engine falls back to a transparent hardware-and-price ranking and flags confidence as low, rather than projecting false precision onto a guess.

In every one of these cases the confidence score is the pressure valve. It is not decoration — it is the engine telling you how much signal stood behind the answer, and what would raise it. A medium-confidence recommendation with an explicit trade-off is more useful, and far more honest, than a high-confidence answer that quietly relaxed a constraint you cared about.

A realistic end-to-end workflow

Consider a team that needs to serve a 70-billion-parameter model to European users at low latency, on a budget of 8 thousand dollars a month, under ISO 27001. Here is how the pieces fit together.

1. Describe intent. The engineer states the workload in the Advisor in plain language. Deterministic intent detection turns it into a structured WorkloadInput; no ambiguity is silently invented — if something critical is missing, the Advisor asks.
2. Filter. The engine eliminates every candidate lacking ISO 27001 or EU data residency. Nebius, with explicit EU residency and InfiniBand clusters, survives; so do the EU regions of the hyperscalers. Marketplaces without a residency guarantee drop out for this compliance-bound workload.
3. Score and rank. Survivors are scored across the six dimensions, weighted toward cost (the stated goal) and performance (the latency priority). The engine computes cost per million tokens for each, not dollars per hour, so a higher-throughput H100 configuration can win despite a higher sticker price.
4. Explain. The top recommendation arrives with its primary reason, its trade-offs (perhaps a reservation lead time), an itemized monthly cost that fits under the ceiling, and a confidence score. Alongside it: the lowest-cost, the best-performance, and the enterprise-ready alternatives.
5. Plan. The engineer accepts, and the Planner turns the recommendation into a deployment-ready InfrastructurePlan with topology and a checklist.
6. Save. The plan is referenced from a long-lived Project — a workspace that holds references to immutable artifacts, never copies or mutates them — so the decision, its reasoning, and its version are preserved and auditable.

What took a senior engineer days of spreadsheet comparison takes seconds, and the output is not a throwaway spreadsheet but a versioned, explainable, reproducible artifact.

The roadmap: Discover to Provision to Optimize

Discover answers what to run and where. The full arc of the AI Infrastructure Engineer is three stages, and GPUVerse is deliberately shipping them in order of trust — you have to trust the decision before you let the system act on it.

• Discover — shipped. The decision engine, the planner, the advisor, the knowledge platform, provider ingestion, projects, and analytics are live. This is the intelligence layer.
• Provision — planned. One-click deployment against the recommended provider, turning a saved plan into running infrastructure, with generated Terraform and Helm artifacts. This is where a recommendation stops being a document and becomes a deployment.
• Optimize — planned. Continuous re-tuning: as prices, availability, and your workload shift, the system re-evaluates and adjusts, moving toward multi-region active-active and, ultimately, autonomous infrastructure operation.

Underneath, the platform is already built for this trajectory: a Fastify and TypeScript backend on Node.js 22, Prisma 7 over PostgreSQL 17 with pgvector for retrieval, Redis and BullMQ for queues, Better Auth for multi-tenant organizations with OAuth, 2FA, and passkeys, and OpenTelemetry throughout. The frontend is Next.js 16 and React 19. Enterprise identity — SSO, SAML, SCIM — is the piece currently in progress, because the customers who most need staged, auditable infrastructure decisions are the ones with the strictest identity requirements.

The principles that hold it together

Every design choice above traces back to a small set of product principles. They are worth stating plainly, because they explain why GPUVerse looks the way it does rather than like the marketplaces and dashboards around it.

• Infrastructure should disappear. The user's job is to describe intent. The system's job is to handle providers, GPUs, regions, and topology. When a team is reasoning about instance shapes, the tool has failed at its purpose.
• Automation beats configuration. The default should be a correct decision made for you, not a hundred knobs you have to set correctly yourself. Configuration is a fallback for the cases where your domain knowledge exceeds the engine's signal, not the primary interface.
• Trust before automation. The system does not earn the right to deploy or re-tune infrastructure until it has proven, repeatedly and auditably, that its decisions are correct. This is why Discover ships before Provision and Optimize, not the other way around.
• Explain every recommendation. A decision you cannot interrogate is a decision you cannot defend in a review or an audit. Every recommendation carries its reasoning, its trade-offs, and its confidence — as structured, grounded facts, never as after-the-fact narration.
• Never lock users into one provider. Provider neutrality is structural, not a promise. Because GPUVerse sells no compute, it has no inventory to steer you toward, and the recommendation is free to name whichever provider is actually correct for your workload — including the one you are not already using.

These are not slogans bolted on after the fact. Each one shows up as a concrete constraint in the architecture: the deterministic engine exists because of "explain every recommendation"; the staged roadmap exists because of "trust before automation"; the refusal to sell compute exists because of "never lock users in."

The future vision

The end state is the AI Compute Control Plane: a system that continuously decides, deploys, observes, and optimizes AI infrastructure across every provider, so that a developer describes what they want to run and the infrastructure simply appears — correct, compliant, cost-optimal, and observable — without anyone thinking about GPUs at all.

That is a large ambition, and GPUVerse is intentionally conservative about the path to it. The order is fixed: decision intelligence first, then deployment, then operations and optimization, then autonomy. Each stage is only unlocked once the prior one has earned trust in production. The reason Discover ships first is not that it is easiest — it is that it is the foundation of trust. A system that cannot explain why an H100 cluster on CoreWeave beats a B200 cluster on AWS for your workload has no business being trusted to deploy it, let alone to re-tune it autonomously.

The category name captures the thesis. DevOps made shipping software a discipline instead of a scramble. ComputeOps intends to do the same for AI compute — and the intelligence layer above every cloud is where it starts.

FAQ

Is GPUVerse a GPU marketplace or a cloud provider?

No. GPUVerse does not sell compute, own data centers, or rack hardware. It is an intelligence layer that recommends where and how to run AI workloads across the 10 providers that do sell compute. That separation is deliberate: because GPUVerse has no inventory to fill, its recommendations can be genuinely provider-neutral.

How many providers and GPUs does GPUVerse compare?

The canonical catalog covers 10 providers — RunPod, Vast.ai, CoreWeave, Lambda, Nebius, Crusoe, AWS, Google Cloud, Azure, and Oracle Cloud — and 54 GPU and TPU instance types spanning RTX 40/50, L-series, A-series, A100, H100/H200, B200/GB200, and Google TPU v4/v5e/v6e.

Does GPUVerse use an LLM to choose infrastructure?

Not in the decision. The ranking is a deterministic pipeline: hard-constraint filtering, then weighted scoring across six dimensions, then stable ranking. The same input always produces the same immutable output. A language model powers the conversational Advisor around the engine, but its replies are grounded in the engine's computed outputs and cited knowledge — it never fabricates providers, capabilities, or costs.

What are the six scoring dimensions?

Cost, performance, availability, reliability, compliance, and residency. Each candidate is normalized to a score between 0 and 1 on each dimension, and the dimensions are combined by a weighted sum whose weights are derived from your stated priorities and reported back to you.

What does a recommendation actually include?

A recommended provider, GPU or TPU, and region; an itemized monthly cost estimate; predicted performance and availability; a confidence score; structured reasoning and acknowledged trade-offs; a generated architecture diagram and deployment checklist; and three alternatives framed around lowest cost, best performance, and enterprise readiness.

Can GPUVerse deploy the infrastructure it recommends?

Not yet. Discover — the decision engine, planner, advisor, knowledge platform, and analytics — is shipped. Provision (one-click deployment with Terraform and Helm artifacts) and Optimize (continuous re-tuning) are on the roadmap. The staging is intentional: decisions must earn trust before the system acts on them.

How does GPUVerse handle compliance and data residency?

Both are treated as hard constraints, not preferences. If you require HIPAA, FedRAMP, SOC 2, ISO 27001, or PCI-DSS, providers lacking that certification are eliminated before scoring. If you require a specific data-residency jurisdiction, candidates that cannot guarantee it are filtered out. The engine will return fewer options — or explain why none qualify — before it violates a stated requirement.

Who is GPUVerse for?

Any team that runs AI workloads and has to decide where — from a startup choosing its first inference host to an enterprise platform team standing up multi-node training under strict compliance. It is built for the engineer who would otherwise be doing this comparison by hand in a spreadsheet.

GPUVerse is the AI Infrastructure Engineer: the intelligence layer above every cloud. It starts by answering the hardest and most consequential question in AI infrastructure — where and how should this run? — deterministically, explainably, and across every provider. That is Discover, and it is live today. Provision and Optimize follow, in that order, because the discipline of ComputeOps is built on trust earned one correct, auditable decision at a time.