Pricing Is a Configuration Problem
A Constraint-Based Approach to Enterprise Quote-Time Pricing
Founder & CEO
Predictika.ai
Email: sanjay@predictika.com
Executive summary
Enterprise price quoting is not, underneath the vocabulary, an arithmetic problem — it is a configuration problem, the same combinatorial-eligibility problem we already solve for physical products, wearing a rate card instead of a bill of materials. That claim needs one immediate qualification, though, because it is easy to overstate: most of a hyperscaler's rate card is not hard at all. Google Cloud publishes flat, simple percentages for its core discount programs, and a spreadsheet handles those perfectly well. What a spreadsheet cannot hold is the smaller, sharper set of places where two or more of those simple rules have to be reasoned about jointly — and Google Cloud's own discount architecture, once you look closely enough to find them, hands us exactly that set without our having to invent an example.
Having stated the conclusion, let us build the case for it properly: what the problem actually is, and just as importantly what it is not; why the real difficulty is narrower and sharper than “GCP pricing is complex” suggests; how our constraint engine already carries the machinery this requires; and why that machinery, not a bigger model, is what an LLM-driven quoting assistant needs sitting underneath it.
The Problem We Are Solving — and the One We Are Not
We define the quote-time pricing problem as follows: given a customer's configuration, contract term, and any negotiated agreement, determine which of the many potentially applicable discounts, rates, and terms apply, in what combination, and compute a price that is both correct and defensible under audit. This is a moment-in-time problem — it is answered once, when a quote is generated or a deal is negotiated.
We should say plainly what this paper is not about, because the distinction is not pedantry: we are deliberately not addressing usage metering and billing — the separate problem of rating actual consumption against a live account over a billing cycle and producing an invoice. That is a well-served, different class of engineering problem (time-series aggregation over metered events), and conflating it with quote-time pricing is a common and costly scoping mistake, one we have seen sink more than one CPQ effort by trying to be two products at once. Everything below concerns the question a sales system, a self-serve pricing calculator, or a quoting agent must answer before a dollar of usage has occurred — which, notably, rules out Google's own automatic Sustained Use Discount as an example for this paper, however tempting: its dollar value depends on what a customer actually ran that month, resolved only when Google looks back at the bill, and so it can never be a term of a quote, only an estimate.
Most of what remains is, honestly, simple. Google Cloud states its core resource-based commitment discount as a flat rule on its own top-level pricing page: roughly 37% off at a one-year term, across every machine family, and 55% at three years for most families, 70% for memory-optimized ones.¹ Committed Cloud SQL usage runs 25%/52%; committed BigQuery usage runs 10%/20%. None of that needs a constraint engine — it needs a rate table, which Google already publishes and which a sales engineer can look up in under a minute.
The real difficulty lives in a smaller set of places where those simple rules stop being independent of each other. Compute Engine's spend-based (“Flex”) commitment covers a published list of machine families that overlaps with, but does not match, the list eligible for the resource-based commitment — five services get one, three get the other, Cloud Run gets Flex only, three families that qualify for Flex get no discount at all in year one. That is not one rulebook, it is two, with an unstated relationship between them that has to be reasoned out. A GPU-attached instance prices its vCPU/memory and its GPU off two independent rate tracks that land on the same line item, never one blended number. Layering a new commitment on top of an existing one requires knowing what the existing one already covers before sizing the new purchase, or the customer is quoted coverage they already own. And sharpest of all: whether a negotiated enterprise discount stacks on top of a standard commitment discount, or replaces the base rate the commitment computes from, is not published anywhere we could find — not because we didn't look hard enough, but because it is genuinely contract-specific. A rate table answers the first kind of question. Only something that can hold several rules in view at once, and knows which ones must reconcile against each other, answers the second.
- Eligibility rules that vary by product/machine family, not a single global discount policy — and that differ between programs covering the same hardware, for reasons that are themselves a fact worth modeling
- Independently-rated components (compute, GPU) that must be priced separately and summed, never blended into one line
- Scoping rules (region, project, billing account) that bound where a given commitment applies
- Independent, non-interacting discount tracks for adjacent products (Cloud SQL, BigQuery, VMware Engine) — one of which isn't even a published rate at all, but a negotiated fact the model has to represent honestly as “ask your account team,” not guess at
- A negotiated overlay (the Enterprise Agreement) that overrides list terms for one customer, whose interaction with the standard commitment stack is not public information anywhere
¹ This analysis is based on Google Cloud's publicly available pricing documentation as of mid-2026, cross-checked across multiple official pages and the underlying Compute Engine API reference. It is offered as an independent, illustrative worked example; it does not reflect a customer, partner, or sponsorship relationship with Google, and no claim is made about Google's own internal pricing systems or roadmap.
Why This Is a Configuration Problem, Not a Calculation Problem
None of the difficulty above is arithmetic — multiplying a rate by a quantity is trivial, and most of a GCP rate card, as just shown, really is that simple. As we argued in the first paper in this series, You May Not Realize It, But Your Business Has a Configuration Problem, the commercially serious version of a configuration problem has four properties, and it is worth checking the sharper cases above against each of them rather than taking our word for it.
- Things are made of things. A quote is built from a rate card, layered with a negotiated Enterprise Agreement, layered again with commitment-specific terms — several levels deep, exactly like a data hall built from rows, racks, and servers.
- Choices cross boundaries that nobody owns. The Compute Engine discount team, the Cloud SQL pricing team, and the VMware Engine pricing team each own their own rules, and a deal that touches all three inherits interactions none of them individually decided.
- Something has to add up. The effective price must reconcile to a single, auditable number — no resource-hour double-discounted, no override silently dropped — the same way a rack's power draw must not exceed its budget.
- Being wrong is not merely suboptimal, it is expensive. An incorrectly stacked discount is not a slightly worse quote; it is a revenue-recognition and audit problem, discovered, as these things usually are, well after the deal has closed.
A discount-eligibility rulebook is a constraint graph over SKUs, terms, and commitments in the same sense that a bill of materials is a constraint graph over components. The vocabulary changes — 'commitment' instead of 'configuration,' 'rate card' instead of 'catalog' — but the reasoning task does not, at exactly the points identified above, and nowhere else.
A second, and in some ways sharper, example comes from the GPU-cloud (“neocloud”) sector, where we have already been building the underlying capacity model. There, enterprise customers commit to fixed GPU capacity for a multi-year term, at a fixed rate, in exchange for a discount off the effective on-demand price — with the discount tier keyed to commitment size, region, GPU generation, and term length. What makes this case instructive is that the pricing eligibility question cannot be evaluated against a discount rulebook alone: it must be checked jointly against a real, time-varying physical capacity constraint, since a commitment that cannot be delivered is not a commitment worth pricing. Pricing here is not a layer bolted onto configuration after the fact; it is inseparable from it.
How Predictika's Constraint Engine Models This Pricing Logic
Predictika's modeling language, LVML, already carries the two properties this problem needs. First, prototype-based object inheritance, in which both parameters and constraints — not parameters alone — flow down an inheritance chain. A rate card hierarchy maps onto this directly: a base list rate card, an Enterprise Agreement instance that inherits it and overrides specific negotiated SKUs, and a deal or quote instance that inherits the Agreement and applies commitment-specific tiers. Eligibility and exclusion rules inherit down the same chain as the rates themselves, so a negotiated override cannot silently violate a global exclusion rule — the engine enforces it, not a reviewer.
Second, deterministic validation. As we set out in Requirements for a Constraint Server Behind an LLM Front End, this matters most exactly where something else — a spreadsheet, a reviewer, or an LLM — would otherwise substitute its own confidence for a real guarantee. A generated quote here is not merely plausible; it is provably consistent with the eligibility and exclusion rules that governed it, which matters as much for audit and revenue-recognition purposes as it does for physical product safety constraints. And because the underlying reasoning server is incremental rather than transaction-bound, a live negotiation — adding a commitment line, changing a term length, testing an alternative configuration — re-derives the applicable price without a full re-solve, which matters once a rate card runs to the SKU counts a hyperscaler catalog implies.
A Natural Fit for LLM-Driven Quoting
Enterprise buyers increasingly expect to get a quote by asking for one in plain language, and cloud CPQ teams are actively building that front end. The failure mode is the same one we documented for physical configuration: a large language model performing a single forward pass can narrate a fluent, confident price — no matter how convincingly it appears to “reason” about the discount stack, it cannot reliably enforce a combinatorial rulebook of the kind described above, because that is a search and consistency-checking problem, not a language-generation problem. This is precisely where the sharper, narrower version of the argument matters: an LLM will look every bit as confident quoting the easy 90% of the rate card as the hard 10%, and nothing about its fluency signals which one it is currently getting wrong. An LLM that is fluent at producing a plausible commitment price is not the same thing as one that has correctly priced a GPU-attached instance's compute and accelerator components off two separate rate tracks, or correctly declined to quote a VMware Engine discount it cannot actually know.
The architecture we would propose is not a new one — it is the same three-layer architecture we already use for configuration copilots, shown in Figure 1 below, with a rate card in place of a bill of materials.
The LLM extracts customer intent and narrates the conversation; the constraint engine decides eligibility and computes the price; the LLM never invents a rate or a discount stack, it only ever reports what the engine returns — including, honestly, the cases where the engine itself has to report that a rate is not publicly known and the quote needs a live sales conversation, rather than inventing a plausible-looking number to fill the gap. This is not a new integration pattern built for pricing — it is the existing configuration pattern, unchanged, pointed at a rate card instead of a catalog.
The Practical Payoff
We are not proposing this from a standing start. The harder half of the neocloud pricing problem — a live, time-varying physical and commitment capacity model — is already built in LVML, with the pricing layer deliberately left open as the next addition rather than a green-field effort. Extending that into a full quote-time pricing layer, and generalizing it to enterprise cloud rate cards more broadly — including an architecture like Google Cloud's own — is an incremental engineering step on a proven foundation, not a new invention. We should be equally direct about what has not yet been done: this is an architectural argument illustrated against Google's public pricing documentation, not a deployed model of it — the next honest step, should there be interest, is building that model and letting it prove the case rather than argue it.
Suggested Further reading
You May Not Realize It, But Your Business Has a Configuration Problem — the first paper in this series
Complex Product Configuration Requires a Constraint-Based Approach — the second paper in this series
Requirements for a Constraint Server Behind an LLM Front End — the third paper in this series
Logic Engines to Guide LLMs for Accurate and Reliable Reasoning — Predictika White Papers (2025)
Guiding AI Agents to Reason Correctly
About Predictika
Predictika builds a patented constraint-based configuration engine for complex products, pairing a declarative modeling language with a logic core whose lineage runs from foundational AI research at Xerox PARC to proven, large scale enterprise configuration at Selectica. The company applies that engine both as a configuration core for complex products and as a deterministic validation layer beneath LLM driven assistants, giving natural language systems the soundness that high-cost-of-error domains require.
About the author
Dr. Sanjay Mittal is the founder and CEO of Predictika and the architect of its constraint-based reasoning engine. He began his career as a research scientist at Xerox PARC (1982–1990), with pioneering work in artificial intelligence and constraint reasoning. He went on to found Selectica, which defined enterprise sales configuration (CPQ) for large organizations, building it from inception to a $5 billion IPO and serving customers such as IBM, Cisco, Dell, GE, Hitachi, Disney, AT&T, and Reliance. Dr. Mittal was the inventor of Selectica's industry leading configuration engine and holds six patents from that work. At Predictika he has carried the constraint-based approach into the era of large language models, with further patents — including U.S. Patents 11,544,475 and 11,914,970 — covering the deterministic validation of LLM driven systems. He holds a B.Tech. from IIT Kanpur and a Ph.D. from Ohio State University.
Copyright © Predictika Inc. 2026