Quote verification — the getRates loop

Stage Abacus names getRates as the stage's test. This page is the loop itself: how the payload is built, what the response does and does not prove, and how to tell a product that prices wrongly from a platform that was never asked.

Provenance and status. From the PC 9951 run on the Ablera dev database, 31.08.2026, probing the live gateway (Product Configurator § SRC, full text in the extract). Gateway details are the kind of thing that changes: if one stops working, re-probe rather than conclude the capability is gone.

1. Two access paths, and they fail independently

F Reaching the rating engine and reaching the database are separate configurations. The gateway needs PC_GATEWAY_URL plus OIDC client credentials (or a token); the database needs neither — the scoped Oracle connector carries its own. A workspace with no gateway configuration fails every gateway call, read-only ones included, while SQL reads are unaffected.

P That is a distinct honest state and the module reports it as one: "numeric verification unavailable" is not "the product is broken". The stage stops and asks for the endpoint rather than working around it — and the proof ladder of Configuration Module § 7.4 caps at structural until it is available.

F Routes are discovered, never hardcoded: the live registry is SRD_SYS."EndPoints" joined to "EndpointSections". A command missing from that listing is genuinely not registered on that environment; a command assumed to exist may simply be named differently.

2. The inner loop

F getRates computes a quote without changing policy business data. Its connector declares operational logging/cache effects and rate/session limits; it may be repeated within those limits, which makes it the inner loop of every verification: change configuration → quote → read the breakdown → change again. A successful response is the full computed breakdown for one resolved version — one BP row per rated cover, one row per LD and TAX code, and a WP roll-up per cover. Under a SUM rule, WP equals BP plus the LD rows; if it does not, something real has been found.

F ⚠ getRates ignores selectedCovers. It prices every cover the product has and returns BP and WP rows for each — the same five BP rows came back whether one cover or two were named. A quote's totals are the whole catalogue, not the case that was asked for. Which covers a policy carries is decided by the caller, never by the engine.

P So verification is always per cover, which is stricter anyway, and a total is never the assertion. This is the same fact Stage Abacus § SUM-5 records as rates_catalog_note — stated here as the rule the skill obeys, because a per-cover assertion is also what catches the applyAlways cancellation of Rating Files § 5.

P The loop also asserts the resolved version_id: an older DEPLOYED version matching product, template and effective date can be priced silently instead of the version just compiled on the working environment (D113).

3. Building the payload

F The engine needs every factor the grids reference, not just those belonging to the covers named. Deriving the set is a query, never an act of memory: SRD_ANLT.PPA_FACTORS for the product's declared factors, and SRD_ANLT.PPA_FACTOR_VALUES for a legal value of each — that second table has no product column; it is a global code → values catalogue. Then override the handful carrying the actual case: the insured values, the duration, the payment frequency.

F Always send the whole duration triple — days, months and years together. The real caller injects all three unconditionally and short-rate handling fails without days; 365 / 12 are the annual values.

4. Reading the failures literally

F The responses are not equally helpful, and knowing which is which is what stops a configuration problem being reported as a platform fault:

F ⚠ A 200 with an empty rates[] is a hard failure and the platform does not treat it as one: the caller logs a warning and produces a silently zero premium. Usual causes, in order: no DEPLOYED version whose effective date is on or before the quote date; a template code the product does not have (the engine falls back silently to another one); a cover code the product does not have.

5. A zero premium has two opposite causes

F Before diagnosing any pricing problem, establish whether the engine ran at all. The rating engine writes one log row per pricing call — ABC_POLPR_LOG on the analytics side. No matching rows is evidence of no recorded invocation only after log coverage, environment and retention are established, so the fault is upstream: no covers attached, no offer resolved, a date outside validity, a cover selection that never reached the caller. Reading rates, grids or factors in that state wastes the cycle.

P It is one query and it decides which half of the system to look at, so it is the first step of the investigation, not a later one — for Stage Abacus and equally for a Support case that arrives as "the premium is zero" (Stage Investigation).

6. The three levels, and what each proves

F Verification has three levels and they prove different things: structural — the rows exist, which proves nothing about behaviour; numeric — a quote returns a premium and it reconciles against the source document, which is where most real defects surface (a rate out by a factor, a discount applied twice, a cap that never binds); operational — the product works for a person: visible to the right role, covers selectable, dependent dropdowns populated, an offer produced. Only the UI shows the third.

P Level 2 is cheap and automatable — run it constantly; level 3 is slow — run it before declaring done; and say which level was reached. "Structurally verified, priced correctly, not yet exercised in the UI" is an honest and useful result. This is the proof ladder stated in the vocabulary of the test that produces it.

F What a quote cannot tell you: whether the operator can reach the product, whether the covers are selectable in the right combinations, whether a required factor has an empty dropdown blocking the quote, or whether the offer packages make sense. Those are configuration questions the rating engine never sees — and the empty dependent dropdown of Stage IPAL § PF-8 is exactly one of them. F The engine also never sees PRICING_FACTOR_RANGE_FROM/_TO; it prices whatever value it is handed, so a product can price perfectly and be unsellable.

Challenges

• C How many worked examples make an acceptance — one reconciling quote or a factor matrix — is DEC-6 of the reconciliation, still open, and is fixed by the first slice.

Related: Stage Abacus · Rating Files · Stage IPAL · Configuration Module