AI pricing engine for complex catalogs
The pricing engine
In most vertical businesses the price isn't a number — it's a computation: catalog, options, manufacturer multipliers, freight, margin policy, and the exceptions your best estimator carries in their head. A pricing engine makes that computation explicit, testable, and fast.
01
What it is
The rules layer that turns a configured request into a price: encoded rule-sets, versioned price books, margin policies, discount authority, and explicit routes for the exceptions. Distinct from the quoting engine: quoting is the workflow and document around the number; the pricing engine is the number.
One design decision matters more than the rest: the runtime is deterministic. AI helps extract and maintain the rules — pulling multipliers out of price sheets and logic out of heads — but the engine computes prices you can reproduce and explain line by line. Nobody should ship a business on improvised prices, and we won't build one that does.
02
When it's the right wedge — and when it isn't
It's the right first build when:
- Pricing takes expertise, not lookup — only certain people can price the complex jobs.
- Price books change often, and each manufacturer update is an error-prone re-keying project.
- Discount decisions are inconsistent because the policy is tribal.
- Margin leaks you can't see, because pricing has no telemetry.
It's the wrong wedge for a single stable price list — the spreadsheet wins, honestly. It's also not a vehicle for dynamic-pricing fantasies: if your industry doesn't accept surge pricing, encoding the pricing you actually do beats inventing a strategy your customers will punish. And if the real problem is cost-data quality, fix the inputs first — garbage costs in means confident garbage prices out.
03
How it's built
The four layers:
- Entities — price book, rule-set, version, multiplier, exception, margin policy. Every price traceable to the rules that produced it.
- Workflow — update ingestion → rule diff → review → publish, so a new manufacturer sheet becomes a reviewed change instead of a re-keying weekend.
- Agents — rule extraction from price sheets, PDFs, and estimator interviews, with humans confirming the encoded logic against known-good jobs.
- Surface — a pricing console for the people who own the rules, and clean integration into whatever produces the quote.
Versioning runs deep here: any past quote must be explainable against the price book as it stood that day. Built on the Sprinter Platform's entity primitives, with the extraction agents in the standard harness.
04
Evidence boundary
Cab‑O‑Matic supplies capability evidence for the vertical data behind this pattern: cabinet pricing and configuration built around complex manufacturer catalogs. The evidence is the engineering itself; we attach no deployment, scale, usage, or outcome figures to it.
05
What a v1 proves in weeks
One price book or one product line, encoded and reconciled against your estimator's prices on real historical jobs. The v1 proves reproducibility — same input, same price, explainable line by line — and that the update path works when the manufacturer ships a new sheet.
The reconciliation itself is where the value shows up early: when engine and estimator disagree, sometimes the engine is wrong and the rules get fixed, and sometimes the estimator was leaking margin for years. Both are worth knowing, and the v1 is how you find out on a few dozen jobs instead of a few thousand.
FAQ
Questions this pattern has to answer.
Does the AI set the prices?
No. Agents help extract and maintain the rules; the runtime that computes prices is deterministic and auditable. Same input, same price, every time — with an explanation attached.
How do manufacturer updates get in?
As a workflow: new sheet arrives, extraction agents diff it against the current rules, a human reviews the diff, and the new version publishes with history intact. What used to be a re-keying weekend becomes a reviewed change.
Can it handle customer-specific and contract pricing?
Yes — as explicit rule layers (contract pricing, tiers, negotiated multipliers), not as ad-hoc overrides that vanish when the person who made them leaves. The layering is part of the entity design.
What if our estimators disagree with the engine's prices?
That reconciliation is the point of the v1. Disagreements are data: they either expose a rule we encoded wrong or a leak the business had normalized. Either way the engine doesn't go live on a line until the record supports it.
Next step
Score the wedge before you build.
Bring the workflow, owner, data, and proof line. The review turns that into a build, fix-first, or don’t-build call.