Stage S2 — Abacus

Purpose

P Multiple templates: CF-05 in Case journeys supplies explicit template work items through the configuration-change contract. Run bounded instances of the existing stage profile, each pinned to template/selector/effective-version/target and a validated leaf specification. Join results by the declared key set; each requires rating proof, intended caller selection, negative/default caller checks and actual target version. Compilation success alone is insufficient. Cache invalidation remains a declared connector effect.

The insurer's tariff documents describe how the premium should be computed; this stage understands those tariffs and creates the product's ratings — then proves the understanding by pricing. Input: the tariff document(s) (through the normalized specification). Test: the getRates skill until the engine's answers match the documents. Output: working rating configuration on the environment plus the configuration summary — human-readable text and the structured list of factors, covers, loadings, discounts, and taxes — which is exactly what the IPAL stage consumes next.

Inputs → Outputs

In: the whitelabel specification's tariff section (from S1), with expected premium examples computed from the documents. Out: deployed rating versions on the working environment (compiled and DEPLOYED on the working environment only, in no deployment set — D113); the configuration summary (text + factors/covers/loadings/discounts/taxes tables with their bases, dimensions, orders, and combination rules); the stage's deployment script set.

What runs this stage

Every stage also uses the module's shared profiles — configuration.root (the only one that reaches the human), configuration.verifier (isolated, no author context) and configuration.deployer — and the platform's write_executor and write_auditor, which are what actually touch a target (Gating).

The protocol here

• Plan: which products/versions/templates will exist, which factors the grids key on, what each loading applies to — confirmed with the human before writing (the plan is refutable: it names the expected premium per worked example).
• Apply: author in the maintained source (PPA_* metadata + rating files, never generated output), compile and deploy — the engine reads only DEPLOYED versions F: [ABACUS schema]. P The test asserts the version_id it priced: an older DEPLOYED version matching product, template and effective date is otherwise priced instead, silently (D113). The mechanics — where a rate lives, the four calls, the grid grammar and the five ways a grid compiles cleanly and prices wrongly — are Rating Files; ⚠ a rate file is shared by name, so two products can point at one file and editing it changes both, and the compile's cache reset does not reach every replica.
• Test — the getRates skill: build the factor payload from what the product declares (queried, never remembered), call the engine (computes and stores nothing — the safe inner loop), assert per cover: base premium, every loading/tax row, the WP roll-up — against the documents' expected examples F: [getRates recipe].
• Iterate: differences are shown per cover with the arithmetic; the human corrects readings or accepts; a rule a grid cannot hold (cross-cover minimums, derived factors, compounding rewrites) is a filter — code → gate Hd to the Development module (id source), never approximated into a grid [F: the PC 9951 run]. ⚠ P That escalation is for a factor which must be computed. A factor which is merely a grouping of an existing factor's values — nine vehicle types falling into four tariff groups — is a level set on the underlying axis, not code, and escalating it is a needless change request (Rating Files § 3); the tariff analyst reports which of the two shapes it read.
• Scripts/deploy: the stage's script set can deploy alone — a tariff change on an existing product is an abacus-only deployment set.

The configuration summary — what this stage signs out

S2 Abacus makes the product price. S3 IPAL makes it exist as a catalogue an operator can sell. Between them sits the configuration summary, defined in § SUM-1…SUM-6 below: the artefact that lets the S2 and S3 authors work in parallel without guessing at each other.

The shape of the problem, established from code [F, verified 01.09.2026]: the IPAL↔ABACUS seam is one-way. sync_products.py:25 pulls IPAL → PPA, and PasSrdSyncService/App/AutoMapper/ServiceProfile.cs fixes exactly what crosses — factors filtered SaleStage == "POL" (:43), cover name set to cover code (:58), datatypes rewritten (:18-19). IPAL is master and nothing returns.

So this summary is precisely the complement: what S2 learned or decided that the sync will never carry back, and that S3 cannot re-derive from the whitelabel specification.

P ⚠ And it is read by a skill, not by a person or an agent typing rows. The abacus seed skill projects it into IPAL catalogue proposals at the boundary; hand entry is not a fallback, and a skill that fails is repaired and re-run rather than worked around — Stage IPAL § The S2 → S3 handover states the payload and the rule.

The honest negative result: names, cover definitions, risks, events, documents, annex types, objects and offers are not in this contract. S3 reads them from the specification. A smaller correct contract beats an invented one.

SUM-1 Context and identity

SUM-2 Covers as rated

SUM-3 Loadings, discounts, taxes as rated

SUM-4 Factors the rating actually keys on

SUM-5 What the engine demands, and what nothing holds

SUM-6 Rules

P Three fields may legitimately contradict the whitelabel specification, and where they do, this summary wins for S3's writes: grid_axes[].value_labels, rating_factors[].value_codes, rated_ld[].ld_code. Each is a rename S2 was forced into by an engine constraint, and each carries the original in its provenance so the divergence is visible at H2 rather than discovered at quote time.

P Every field carries its source the same way the specification does. A summary field with no source is the same defect as a specification field with no source.

P The summary schema is a T0 contract (Components § 2); until it exists, the summary is the 31-field list above, carried in the tariff sign-out and validated as that list at the S2→S3 boundary (D113).

P This is v0, drafted from code rather than from a run. The S2 and S3 authors amend it on the first real slice — and every amendment is an amendment to the Configuration Module.

Facts to hold F

• The template code is the only offer↔rating bridge, and an unknown code falls back silently to another tariff — verify which template resolved, not which was configured.
• Missing rates are never faked. P A cover the specification names but the tariff does not price stays unpriced — no invented rate 0, no blocked version — and the tariff analyst adds a pre-emptive note (a specification line and a customer-preview line) that it is unpriced, because customers sometimes intend the opposite; it becomes an unresolved[] item only when the specification is ambiguous about the cover (D122).
• Failure decode: 400 missing features lists exactly what to add; 500 internal: 'X' is usually a missing factor, not a platform fault; 200 with empty rates[] is a hard failure (silent zero premium); zero premium → check the engine's log rows in ABC_POLPR_LOG first, because never invoked and priced zero lead to opposite investigations (Quote Verification § 5 carries the whole decode, the payload build and the three levels).
• A reconciling total is not evidence: a loading authored to apply unconditionally never errors, and four such loadings cancelled to exactly the right premium on a product wrong in four places — so the worked examples separate the loadings and the acceptance asserts each contribution row (Rating Files § 5).
• ⚠ getRates ignores selectedCovers and prices the whole catalogue, so a total is never the assertion — reconcile per cover (Quote Verification § 2).
• ⚠ A rate file is a lower bound on a value set, never the set. A grid carries only the values that differentiate a rate, so a value list can never be reconstructed from one: two bands in a file are compatible with a dozen values an operator must be able to pick. The value list comes from the specification, and where the specification is silent it is an unresolved[] line — never an inference from the grid.
• The seed is a head start, not a synchronisation. Projecting the rating into catalogue proposals fills a skeleton — codes, names, datatypes, the loading list — and writes none of the parts that make a product reachable: the value lists an operator picks from, limits and deductibles, perils and claim events, packaging, field rules, annex types, print, labels, numbering, routes and roles, and the whole screen layer. P It therefore runs once, at creation — a second run would overwrite the columns the catalogue alone owns — and it reports its own coverage for this product before anyone leans on it, because coverage varies by product far more than any average suggests. Every proposal it cannot decide (a cover's commercial type above all) arrives tagged as a decision, never as a value.
• Two dates: the tariff's in-force date belongs on the rating version — on the covers it makes them not-yet-in-force while rating looks perfect.
• Factors that feed rating are configured SALE_STAGE = 'POL' — the IPAL→ABACUS catalogue sync hard-filters SaleStage == "POL", so a QT-only factor never becomes a PPA_FACTORS row and no grid can key on it [F: PasSrdSyncService/App/AutoMapper/ServiceProfile.cs:43, verified 01.09.2026].
• ⚠ Three different fields are called "QT", and the 31.08.2026 decision retires exactly one [F: verified 01.09.2026]: PR_PRICING_FACTORS.SALE_STAGE (QT/POL — the one retired, read by the wizard and by offer resolution) · the getRates request saleStage (QT/APL, built from POLICY.POLICY_TYPE, and which the engine never reads — zero occurrences in src/Analytics/) · PPA_FACTORS.QT_REQUIRED + the request's isQuote, which is the engine's real quote mode. Retiring the first says nothing about the other two.

P SALE_STAGE is always POL — the rule and the remark for agents about the QT residue in today's estate are in Stage IPAL (decision 31.08.2026, reaffirmed 02.09.2026). S2's interest is the invariant above: a rating axis exists as a POL row, which the rule guarantees.

Real material — what live cases asked of this stage

Eight configuration cases were walked against this design (Configuration Module § 8 carries each case in full). What each one demanded here:

CS-1 · 9951 «Каско Максимум» replayed through v2 — The PC agent built 9951 on Ablera dev from a 13-sheet template (Продукт · Тарифни групи · Клаузи · Покрития · Зависимости · Оферти · Правила за премия · ЗС/лимити · Подписвачески въпросник 91 rows · Зависимости между въпроси 65 rows · Такси · Ref) and a 10-page tariff PDF (raздели I–VIII).

Plan (H2): one PPA_PRODUCTS row (PRODUCT_ID = PRODUCT_CODE convention), four templates as the offers name them, one version each with effective_date 01.08.2026, ld_rule SUM, tax 2.5 % as TAX, grids keyed on CLAUSE × VEHICLE_AGE per (deductible, vehicle group). Assertion per step: „PPA_PRODUCT_COVERS holds 8 rows for version V", „genRuleTable compiles version V", „getRates for worked example W1 returns CM_FIRE_NAT BP = 1 234.00 EUR". Apply through the write executor; the known engine traps live in configuration/abacus (BP_BASE literal 'NULL' for V covers, ldRule dropped on create). getRates assertions per cover; 200 with empty rates[] is failure. Configuration summary: skeleton_source = s2_bootstrap (S2 had to create the PR_BASIC_PRODUCTS skeleton so the sync would run — the S2⇄S3 loop-back of Configuration Module § 1), template_resolution per offer, rated_covers[] with bp_rate_dim (P for the four clause covers, V for assist/mech/seats, P-of-BP for replace), bp_base_factors (IV; SEATS), grid_axes — and here the first legitimate contradiction: the deductible axis 0/200/400 is numeric-only LIST and had to become D000/D200/D400 (§ SUM-2/§ SUM-6). not_held_by_rating[]: „CM_REPLACE = 14 % of the clause base premium" — BP_BASE accepts exactly one BP(<cover>) term, and a clause is up to four covers → destination Hd:Development (a filter) or a re-reading with the human. worked_examples[] from the PDF's раздел VIII examples. H3 when the operator accepts the arithmetic.

CS-2 · 2026 EUR tariff on 4710 ГО and 4704 Каско — abacus-only — Bulstrad publishes the 01.01.2026 EUR tariffs (two PDFs in knowledge/sources/).

[gap F] the schema has one tariff.template; 4704 has 71. The plan must create 71 new versions (one per template) with effective_date 01.01.2026, each DEPLOYED, each compiled — or a subset the human names. Nothing in Stage Abacus discusses multi-template products; the configuration summary's template_resolution.per_object_or_offer (§ SUM-1) describes resolution, not authoring fan-out. getRates assertions per template × worked example (the knowledge file's Honda CR-V case: 8 000 × 6.13 % = 490.40 EUR). Two dates trap: the in-force date goes on the version, never on PR_BASIC_COVERS.VALID_FROM — and abacus-only means S3 is not even instantiated, so nobody could copy it wrongly. [ok]. Minimum premium 122.71 EUR and sufficient premium 255.65/306.78 EUR: these are CORRECT_PREM_SERV operations and PPA_PRODUCT_COVERS.PREMIUM_MIN (not compiled). If the values changed, the enforceable home is PR_OPERATIONS — S3's table. Configuration Module § 7.5: „no writes outside its own targets"; § 3: deployment set „revisable later". [gap G closed by Configuration Module § 3] revising the set mid-case is a plan revision confirmed at H2 by the root; stages added later run their own H3, and the smoke tests are those of the final set. Failure and Recovery § 5 exemption test would let a single PR_OPERATIONS value change skip simulation only if a teardown already exists.

CS-3 · HelpDesk 00097807 — 3607 „трудова злополука": new clause, loading, minimum premium — Bulstrad (Зорница Йорданова, 16.03.2026 onward) asks for: (1) +50 % loading when ≤5 insured persons, counted across individually entered persons and list counts; (2) minimum premium 30 EUR per policy, message at proposal level, „без опция да се конвертира в полица"; (3) a new optional clause „Временна загуба на работоспособност от избрана ЗС", limit free up to 3 000 EUR, rate 0.15 % — changed mid-thread by the board to 5 000 EUR and 0.1 %; later (4) all groups on one policy must carry identical covers; (5) the ЗС of the new clause must be identical across groups; (6) the short-term tariff split into ticket 102052; (7) override of the minimum only for named users (Зорница, Валя, Захариев) — later withdrawn to „message + proposal stays proposal, only we may convert".

Loading „≤5 persons" keys on a derived count across groups and individuals — the same defect the thread hit („умножава вече калкулираната премия още веднъж по броя лица"). A grid cannot count; Stage Abacus § Iterate: „derived factors … is a filter — code → gate Hd". not_held_by_rating[] entry with destination Hd:Development. Minimum premium 30 EUR: not_held_by_rating → S3:PR_OPERATIONS. New clause rate 0.1 % of a chosen sum: a flat P cover on its own IV — the IV is per-cover (IV_COV), and Stage IPAL § PF-8 says IV_COV/IV_COVLIST „have no case in the generator — invisible to the operator". [gap J] a cover with its own selectable sum insured is a normal shape (this ticket, 4727 CASCO_R limit, 9951 CM_SEATS) and the model says the datatype that carries it does not render. Is the pattern „definition list on PR_BASIC_COVER_DEF + LIMIT selected in the offer" instead? Neither § PF-2 nor § PF-8 of Stage IPAL says which shape a per-cover chosen sum takes (gap J, open).

CS-4 · HelpDesk 00098747 — 2214/2215 promo „65 години Булстрад": pay 60 months, get 65 — Home products 2214/2215: for the campaign, term 65 months, premium for 60; everything else unchanged.

Version with a DURATION axis where 65 → 60-month factor. worked_examples[] from live 60-month policies (the operator supplies). [ok]. Which of 2214/2215's templates — again the multi-template question (gap F).

CS-5 · Product 8000 „Здравна грижа" — packages × levels × options, cover modes, a Camunda process, CG-9 — Group health, EUR, QA only (10.239.82.106), 10 UI covers + 52 level-variant child rows (IP_O/IP_L/IP_E), consumption modes PRV/REIM per cover (PREVENTION and EXTRA_CARE PRV-only), tariff per member × package × level × option with ordered corrections (sector, group size, age band, −5 % commercial), Профилактика individually rated (no rate), Критични заболявания only above 150 persons, claims-side ABACUS templates SRVPRICE# and CLMIND#, BPMN in Core.Plugin.Bulstrad, HealthBasicProductId=8000 hardcoded.

Premium rating: per member tariff with ordered multiplicative corrections (sector −15 % then group size −5 %: 198 × 0.85 × 0.95 = 159.89 EUR). ld_rule MULT on the version [ok]. Rounding rule unstated → unresolved[]. The claims-side rules (SRVPRICE#, CLMIND# — limits, deductibles, co-pay) are also SRD_ANLT.PPA_* configuration but are not premium rating and the getRates skill does not exercise them. [gap Q] Stage Abacus defines S2 as „tariffs → ratings" proven by getRates; the health product's largest ABACUS configuration is a settlement rule set proven by a claim, for which no stage, skill or eval exists. The configuration summary has no field for it.

Challenges

• P A published rate covering a bundle of covers does not tell the split — always a question to the human, never arithmetic.
• P Rating may need a minimal IPAL catalogue first (the catalogue-sync dependency) — the module allows the S2⇄S3 loop.
• C Confirm the QT obsoletion state on the target branch before a production-bound product whose process carries a quotation step (Stage IPAL remark); UI evidence so far is from serdica-ui master, backend from bulstrad-staging (KI-054 documents drift).
• P Filter authoring/registration knowledge is thin in the estate's memory — the first filter case builds source/ knowledge with the backend owner.