Configuration Module

P Stage correspondence. joint Joint proof; release Release and verify. These are the same stage identities used by the product overview and case walkthrough. A checkpoint or nested task conversation stays inside its owning stage.

From stray documents to a deployed product, in two phases. The input is a business idea with unclear requirements: some tariff files, a template someone half-filled, emails with contradicting wishes. The module turns that into a product an operator can quote, sell and issue — asking early when the material is short, showing results on a working environment, and deploying only what a person approves, only as far as they choose. Every phase ends the same way: its own tests pass, and it signs out a document the next phase reads instead of its transcript.

P The flow at every presentation level. Normalization (S1) agrees the specification or delta and its baseline. Abacus (S2) is phase 1: rating, working-environment tests and tariff sign-out. Phase 2 branches into IPAL (S3) → Offer (S4) and Serdica (S5), which can work in parallel when their prerequisites are ready. Joint proof joins the selected sign-outs and the customer accepts the working preview. Release and verify applies the chosen set under H4 and the applicable effect gates, including H5 for customer-facing targets, then proves delivery. A delta selects only the required stages; an omitted stage's input comes from a verified baseline. The result returns to the parent request. The walkthrough expands this same selected work and its gates.

P Which environment is working and which are targets is knowledge per product line (D123): the existing policy-administration products work locally, then bulstrad-staging (TEST), then PROD, porting to master → bulstrad-qa afterwards; the health line (product 8000) works on QA, ports to master and targets the planned bulstrad-prod-2. QA is the working environment only where the product line says so.

Stages: Normalization · Abacus · IPAL · Offer · Serdica.

P Route before stages. A lasting product, tariff or rule change uses Configuration. CF-01 is a temporary relax/action/restore request and CF-22 is BSO batch provisioning: both use Support’s Data & Manipulation stages. Their CF prefix places them in the request census; it does not select the runtime module. The Configuration flow below describes the requests actually assigned to Configuration.

Agents in this module

P Open an agent below for its function, input/output brief, task context, methods and restrictions. These descriptions are generated from the same catalogue as the module agent subpage. The memory domains listed later are knowledge stores, not additional agents.

Task contract. Start only when the selected work and prerequisites are ready. Pin the profile, request/plan and source revisions; provide the original objective, relevant evidence, decisions, uncertainties and dependencies. The agent proposes a plan to its immediate parent, waits for that confirmation before dependent work, and returns a result or a precise question. Parent confirmation does not replace an effect gate. Runtime and context contract.

0. The agents

P The tree. A normalizer and four domain builders own their knowledge while receiving the relevant whole-case context; each S2–S5 builder has a domain validator. Two isolations keep the specification honest — the source analyst has no database connector, the estate prober is told nothing about the product it measures; independent verification with original source requirements and current evidence, excluding author reasoning; one write path through the platform's effect applier and auditor. The dashed edges are consults to the other modules' domains and the one handover.

flowchart TB
  R["configuration.root"]:::owner
  N["S1 Normalizer"]:::work
  TA["Source analyst"]:::work
  EP["Estate prober"]:::work
  ST["S2–S5 domain builders
clarify, plan, coordinate"]:::work
  V["Domain validators
then joint product proof"]:::proof
  D["Deployer"]:::work
  M["Owned domain knowledge"]:::learn
  O["Other module or
external owner"]:::store
  R -->|"scope"| N
  N --> TA
  N --> EP
  N -->|"validated input"| ST
  ST -->|"signed results"| V
  V -->|"requested release"| D
  ST -.->|"when needed"| O
  M -.->|"compatible knowledge"| ST
  D -.->|"propose learning"| M
  classDef work fill:#eef4ff,stroke:#6889ba,color:#17365b,stroke-width:1.3px
  classDef decision fill:#fff4df,stroke:#b78c36,color:#65470d,stroke-width:1.5px
  classDef proof fill:#e9f5ef,stroke:#689b81,color:#224e39,stroke-width:1.3px
  classDef learn fill:#f1edf9,stroke:#9580b9,color:#534172,stroke-width:1.3px
  classDef store fill:#f5f7fa,stroke:#98a6b7,color:#34445a,stroke-width:1.2px
  classDef owner fill:#24486b,stroke:#24486b,color:#ffffff,stroke-width:1.4px
  click R href "../modules.html" "Confirms child plans; joins all selected stage and external results."
  click N href "stage-normalization.html" "Full product or existing-product delta; owns the specification revision."
  click TA href "stage-normalization.html" "Interprets source tariff material without database access."
  click EP href "stage-normalization.html" "Reads current state without inventing the customer's intent."
  click ST href "agents-and-skills.html#cap-configuration-abacus-builder" "Abacus, IPAL, Offer and Serdica; run only the selected dependency graph."
  click V href "agents-and-skills.html#cap-configuration-integration-validator" "Checks selected templates, stage results and complete target assertions."
  click D href "configuration-module.html#3b-release-packet-and-completion" "Coordinates the selected release through the shared authority/executor path."
  click M href "../50-agents/agents-memory.html" "Each stage proposes learning to its owner; the shared curator owns the case index."
  click O href "../case-journeys.html" "A consult brings evidence; Hd recruits work; external instructions retain an obligation."

Profiles and responsibility. Solid arrows pass work or evidence; dashed arrows are knowledge or conditional collaboration. Execution itself always uses the shared auditor, gate and deterministic connector protocol.

P Configuration is reached by a handover packet from support.root (D142, D143). The configuration root reads the packet — or, for a case an operator started in place, converses with the operator — for what material arrived, what the task is (new product, tariff change, packaging change), which stages it needs, the working environment and the intended deployment set, and instantiates the stage agents for exactly that (decision 02.09.2026). The packet's fields are named once in Agents § 5 and drafted in Contracts § 2 (handover-packet.schema.json); § 4b says what this module does with them. v1 skills such as /configure-product are evidence and seeds for the stage prompts and memory domains, never runtime components of the module. Standing rules on the edges [F: the PC 9951 run]: after two failed attempts at an unknown write contract, stop and ask the owning agent; a sub-agent's convenient "missing/inaccessible" that contradicts established evidence is re-asked with the how, not believed. Isolation is provisioning — the source analyst's scope contains no DB connector; the validator's scope contains no author transcript (Agents § 0.2).

Profiles in full — what each boots from, writes, may use, is denied, and the eval set that proves it: Components — Configuration § 3.

0.1 Its branch of the memory tree

configuration/
├─ AGENTS.md            stage index + module rules
├─ normalization/       input-document traps, whitelabel field catalogue, reconciliation
├─ abacus/              engine, versions, grids, filters, getRates skill
├─ ipal/                catalogue, factors, translations, input reading, camunda process registration
├─ offer/               LB packages, dependencies, conflicts, restrictions
└─ serdica/             routes, views, endpoints, core, roles, numbering, print

Every seed a fact, linked; migration is per domain and accepted on a measured hit-rate (Agents Memory § 7) — the tariff and catalogue domains are wave 1, the rest wave 2.

0.2 Agents, methods and executable helpers

P Full definitions live on Agents and methods. Shared definitions are referenced from Common agents and methods. Each method owns its optional executable helpers; runtime/connector operations are not extra skills.

Configuration work procedures explains the actual S1–S5/joint/release work and covers every CF case.

1. The phases

P Delta and template variants: Case journeys § 5 and configuration-change define the existing-product path. S1 reads current source/target configuration and the requested difference, selects only affected stages and binds unchanged prerequisites to evidence. Multi-template work is a bounded S2 fan-out and result-matrix join using single-template leaf specifications. Small size removes irrelevant stages, not required scope, assertions or effect gates. INSIS-native dependencies retain named external owners under the existing scope boundary; their missing proof prevents a false complete-product sign-out.

P Configuration runs in two phases, and phase 2 has two branches that run at the same time (decision Vladimir, 03.09.2026 — D75). Intake and normalization produce the specification; phase 1 builds the tariff; phase 2 builds the product and its wiring in parallel. Every phase ends the same way: its own tests pass, and it signs out a document the next phase reads — never the phase's transcript, never its agent.

flowchart TB
  N["S1 Scope and baseline"]:::work
  H["Confirm scope
H1 or H1a"]:::decision
  A["S2 Rating
selected templates"]:::work
  I["S3 Product
S4 Offers"]:::work
  S["S5 Wiring"]:::work
  J["Joint working proof
preview acceptance"]:::proof
  G["Release packet
H4 and effect gates"]:::decision
  T["Target proof
delivery acceptance"]:::proof
  N --> H
  H -->|"if rating changes"| A
  A -->|"rating result"| I
  A -->|"rating result"| S
  H -.->|"baseline-backed delta"| I
  H -.->|"baseline-backed delta"| S
  I --> J
  S --> J
  A -.->|"rating-only scope"| J
  J -->|"release requested"| G
  G --> T
  classDef work fill:#eef4ff,stroke:#6889ba,color:#17365b,stroke-width:1.3px
  classDef decision fill:#fff4df,stroke:#b78c36,color:#65470d,stroke-width:1.5px
  classDef proof fill:#e9f5ef,stroke:#689b81,color:#224e39,stroke-width:1.3px
  classDef learn fill:#f1edf9,stroke:#9580b9,color:#534172,stroke-width:1.3px
  classDef store fill:#f5f7fa,stroke:#98a6b7,color:#34445a,stroke-width:1.2px
  classDef owner fill:#24486b,stroke:#24486b,color:#ffffff,stroke-width:1.4px
  click N href "stage-normalization.html" "Start from supplied material and the current estate; confirm the requested delta."
  click H href "../gating.html" "Confirm the original specification or only its changed revision."
  click A href "stage-abacus.html" "Bounded template tasks rejoin on complete selector/version proof."
  click I href "stage-ipal.html" "Catalogue and offer work follow declared dependencies."
  click S href "stage-serdica.html" "Routes, roles, labels, numbering and print obligations."
  click J href "../case-protocol.html" "Join all selected stages and external dependencies; preview is not delivery."
  click G href "../gating.html" "Only the requested target set, with applicable H5 and write-class requirements."
  click T href "../case-journeys.html" "Verify the actual target; no missing template or dependency can hide behind a green build."

The full path and the delta path share the same contracts. Dashed routes use explicit current baseline bindings for unchanged stages; they do not bypass required proof or effect gates.

Stage ids name the stage documents, not a running order (D83).

P Where the workflow ends. Joint proof establishes the working-environment preview: quoted/issued only where the selected stages actually prove them. CG-11 records acceptance of that preview revision. If the agreed objective includes a target deployment, the case continues through H4, every applicable effect gate, execution and target verification; preview acceptance does not close it. A preview-only assignment may finish there because that was its explicit objective. The release sign-out names the target, applied artefacts and smoke evidence; final customer acceptance binds that delivery scope.

P Parallel preparation, explicit write prerequisites. Product and cover codes are fixed at H1, so 2A and 2B can plan concurrently. That does not remove foreign-key dependencies: a label must exist before a row referencing it, and shared rows/returned ids can serialise individual writes. The plan declares those edges and the runtime enforces them with result references and impact claims. Joint quotation/issuance waits for both branches.

What still has an order, and is therefore a joint test. Driving the sales wizard as an operator needs 2B's catalogue and 2A's visibility. So the quoted and issued rungs are proved once, after both branches report green — the joint proof — and neither branch may claim them alone (Configuration Module § 7.4). Each branch proves only the rungs its own writes support: 2B up to reachable, 2A the visibility and label assertions.

P Loop-backs are still real and are still allowed F: [product configuration]: work in 2B can surface a rating gap, which re-enters phase 1 as a delta — the phase amends the affected plan and evidence, and its sign-out is re-issued with a new revision (Configuration Module § Challenges). A re-issued sign-out re-opens the assertions of any phase that consumed the superseded one.

P A case may run a subset. A tariff change is S1 and phase 1 and deploys the rating alone; a packaging change is S1 and phase 2B; a whole new product runs everything. The stage set is the root agent's decision at intake, recorded in plan revision 1.

1b. The sign-out document

P One per phase, and the authoritative result the next phase consumes alongside the shared specification. It is a generated artefact, not prose written by hand: every section is projected from the phase's plan, its write log and its test results.

P A sign-out is confirmed at H3 by the role assigned in the case type: Operator by default, or Customer representative for client-led business results. CG-11 separately accepts the preview/delivery scope. It carries a revision number; a later phase records which revision it consumed, so a re-issued sign-out makes the dependent assertions re-run rather than silently drift.

Why a document and not a message. Five people build the stages and different people work the phases of one product over days. A sign-out is what lets phase 2B start from what phase 1 established rather than from what its agent remembers, and it is what a person reads when a case is picked up by someone else.

2. The stage protocol — every stage passes the same phases

sequenceDiagram
  autonumber
  participant S as Stage owner
  participant R as Root and case service
  actor H as Assigned decision holder
  participant X as Executor and connector
  S->>R: Plan and current baseline
  R->>H: Scope, assertions and required decisions
  H-->>R: Confirm or revise the exact packet
  R->>X: Authorised working-target operation
  X-->>R: Recorded effects and test evidence
  R->>S: Evidence for stage verification
  S-->>R: Signed result or a precise gap
  opt Requested target release
    R->>H: Joined release and effect decisions
    H-->>R: Current target authority
    R->>X: Apply selected release set
    X-->>R: Actual target version and proof
  end
  R-->>H: Preview or delivery result, explicitly scoped

One selected stage, from planning to target proof. Reads and case-local planning need no target write grant; every target effect goes through the coordinator. Preview and target delivery remain separate.

Phases 2/3, 6, 8 and 8b are the human's; everything else is the agents'. Verification is per stage — phase 5 on the working environment, phase 10 on the target — there is no separate verification stage. A dead end at any phase goes to the root and, unresolved, to the human (gate H6); executing a teardown is its own decision (H7); "this needs code" hands over to the Customer-specific development module (id source) with prior human confirmation (Hd).

3. Deployment scoping

The deployment set is chosen with the human — at planning, revisable later: rating only (a tariff change on an existing product), rating + product (product structure without new packaging/wiring), full (abacus + ipal + offer + serdica — a new product). Each stage emits its own idempotent script set with teardown — the emitting agent writes the revert of every artefact it emits (D120); deployment executes the union in dependency order; smoke = the deployed stages' skills run read-only against the target (getRates reference quote; offer resolution; route/label checks). Deploy-coupled items (core appsettings.json, Camunda registration from S3) ride the service-deployment plan and are sequenced with the scripts [F: stated 31.08; serdica stage, D86].

P Rules added from the case studies (02.09.2026) (Configuration Module § 8):

• The deployment set is any subset of stages in dependency order (R); the three names are presets. Non-ABACUS-rated families (cargo) deploy ipal only or ipal + serdica.
• Revising the set mid-case (G) 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.
• Compiling a rating on a target resets the engine cache — genRuleTable is a compensable, service-wide effect with a scheduling window, named in the plan (H).
• Time-boxed configurations (a promotion valid to a date, N) are a case type with an end date and a scheduled H7: „stop offering" (retire the offer, keep the rows) is distinct from „remove", and the plan says which.
• Shared rows are impact keys (Z): LT_LD_CODES, SR_MESSAGES, global factor values, LB_OBJECT_NA and the engine cache are keyed as shared, so two configuration cases on one working environment collide on them, not only on the product code.
• The customer at H3 (AA) is the Customer representative role (Trust and Data § 3): they see the working environment and give the acceptance CG-11 asks for; the role assigned by the case type answers H3.

3b. Release packet and completion

P Each stage emits a script/template set, expected target assertions and its revert descriptor. The deployer combines the selected sets in dependency order, resolves target-specific names and binds the exact artefact hashes. H4 fires on that combined release packet, after the selected stage sign-outs and required joint proof; it does not fire a second time merely because a stage has a protocol-phase-8 label. H5 and the other effect requirements fire immediately before target execution. A changed script/set/target reopens the affected decision.

P Preview acceptance and delivery acceptance use CG-11 with different scope values in the packet: preview or delivery, environment, selected set, proof level and artefact revision. Accepting preview never implies accepting a production change. The existing client Acceptance screen renders the scope explicitly; no second client application is needed.

P Emitting scripts or encountering an external-owner dependency is a truthful partial outcome. It resolves a case only when the agreed objective was the script/referral, or the customer explicitly changes the scope. A request for an operational product remains held until its declared target and downstream obligations are proved; Configuration does not claim transfer proof that belongs to Data & Manipulation.

4. The agents

The tree these rows form, the module's branch of the memory tree and its skills are at the head of this page (§ 0); every profile in full is Components — Configuration § 3.

4b. What this module asks of the others, and what they ask of it

P Two mechanisms, defined once in Agents § 5: a consult returns knowledge and costs a read; a handover (Hd) returns a changed system and costs a gate. Both handover directions here carry the one handover packet (D142 — request, response, completion; draft contract in Contracts § 2).

What Configuration asks:

P The module manifest declares Hd on S2–S5 with the handover packet as a produced contract: a working stage that stops at MISSING hands the packet to configuration.root, which raises the gate. The manifest is what the runtime instantiates, so the gate is declared where it can fire and not only described here.

What is asked of Configuration:

P The recurrence rule is what makes this traffic pay for itself: the second identical manual fix — precipitated by the Data & Manipulation module at S8 (D144) — is a configuration gap, and it arrives here as a handover rather than as a third repair — which is the whole economic argument for the two modules sharing one platform.

5. Worked reference

The 9951 «Каско Максимум» run [F: artifact] maps onto S1 (tariff PDF + template read, counts reconciled), S2 (ratings built and reconciled per cover), S3 (catalogue + wizard driven until a premium rendered), S4 (the packaging layer — whose absence the donor diff caught), single environment, no deployment stage. The module generalizes exactly that run with: per-stage human iteration, scoped deployment, and session/audit around it.

6. Evaluation

The module's golden set is the round-trip test [F: method proven in the PC 9951 run]: export a selling product + its real sources, run S1–S2 (model level) in a clean session, grade with the isolated grader (completeness · counts · correctness · excess · semantics; fatal/material/cosmetic). Re-runs when configuration/* domains, its skills, or model routes change.

7. The stage contract — what every stage owes every other

Five stage prompts are authored at the same time, by different people (Delivery track T2). Without one written contract each author invents their own input assumptions, output shape and completion test, and the mismatch only surfaces when the five are joined — the most expensive place to find it. This document is that contract: what a stage receives, what it must produce, how it proves it is done, and what it may not do. An author who has read this page can write their stage without asking anyone what the neighbouring stages expect.

The contract is binding on the prompt, not on the prose: a stage that produces something else, however good, breaks the pipeline.

7.1 What every stage consumes and produces

P A stage reads its predecessor's produced artefact, never the predecessor's transcript or reasoning. This is what lets the five be written, tested and replaced independently.

P The artefact a phase hands on is its sign-out document (Configuration Module § 1b): what was built with counts from the write log, what was tested with its assertions, the proof rung actually reached, what the next phase needs, what is open, and the phase's teardown. A stage consumes a sign-out revision, records which one, and re-runs its dependent assertions when a superseded sign-out is re-issued.

P Which rungs a branch may claim alone. Phase 2B claims up to reachable; phase 2A claims the visibility and label assertions. Quoted and issued are the joint proof taken after both branches are green, because driving the wizard needs the catalogue and the visibility together. A branch that reports quoted on its own has claimed a rung it cannot support (Architecture CR-3).

P A stage that needs something its input does not carry raises it as an open question against S1 — it does not infer the value, and it does not reach back into the source documents itself.

P Ownership of what the five stages did not name (Configuration Module § 8 K, L, Q, W, X, AB — from the twelve parts of the v1 skill):

P Two vocabularies the module works in. Shared vocabulary governs the code space — object, cover and factor codes, which are platform-wide and closed against invention. Premium vocabulary governs the premium terms a request arrives in, from the premium specification the Product Configurator is built against: what a rate is applied to, how a loading differs from a tax, why a write-off and a refund are different numbers, and which premium choices a product must settle for itself. Its terms are safe to adopt; its columns are claims to verify (Schema Quirks § 8).

P Amending the specification after H1 (U). A later stage that finds the specification wrong or short raises a Question against S1; the S1 owner edits product.json, the validator re-runs, the specification gets a new revision linked to the question, and the human confirms only the delta at an H1a decision; stages already applied re-reconcile their assertions against the new revision. Nobody else edits the specification.

P S3 may start before the S2 summary (V) when the catalogue skeleton is a prerequisite of rating — and in v2 that prepass is S3's, because those are S3's tables and the sync only ever runs IPAL → PPA (s3_prepass, never a v2 s2_bootstrap); the summary's skeleton_source records who created the rows, and S3 adopts rather than recreates them when the summary arrives. S3 may start on the factor codes fixed at H1 before the S2 summary exists; every assertion that reads a rate waits for the summary revision it cites.

7.2 The phase set

Every working stage S2–S5 uses the same eleven phases (Configuration Module § 2) — ten steps, with 8b splitting the approval of execution on a named target from the approval of the scripts. The author writes the stage-specific content of each; the phase order is fixed.

P Phase ownership. S1 normalizes and confirms the input at H1; it does not execute a configuration write cycle. S2–S5 prepare their sub-plans and obtain parent confirmation, then present the joined stage plan at H2 and its result at H3. Their script sets contribute to the selected release. Phases 7–10 participate in that joined release after the required working proof; they are not uncoordinated deployments before the preview. The operator chat shows the stage and sub-plan conversations, while the root joins their artefacts and requests human decisions.

7.3 The assertion form

P Every plan step carries exactly one assertion, and an assertion is a statement a tool can evaluate without judgement: a count, a row that must exist, a value that must equal a named expectation. "The covers look right" is not an assertion; "PR_BASIC_COVER holds 7 distinct cover codes for product 9951" is.

Why: an unrun step leaves nothing behind that looks wrong — the write log records only what ran. Assertions are what make absence visible at reconciliation (Agent Runtime § 11.3).

7.4 The done test

P A stage is done when, and only when:

1. every plan step id is matched against the write log and its assertion re-run green (Agent Runtime § 11.3);
2. the stage skill passes on the working environment — and on the target, if the stage is in the deployment set;
3. the produced artefact of § 1 exists in full, or its gaps are listed in the case's MISSING paper with what each blocks;
4. the human has confirmed satisfaction (H3);
5. the script set and its teardown exist (H4).

The stage reports the level it actually reached, never an implied higher one (Architecture CR-3). The configuration ladder is: structural → priced → reachable → quoted → issued, and it ends there [F: the PC proof ladder]. Arrival in the incumbent system is proved by the Support module, not by a configuration rung (D85).

7.5 What a stage may not do

P

• No writes outside its own targets. S2 writes rating; S3 writes catalogue; S4 writes packaging; S5 writes wiring. A stage that finds a defect in a neighbour's layer reports it — the loop-back is a decision, not a shortcut (Configuration Module § 1).
• No writes except through the effect applier, dry-run first, every statement logged with its target, environment, mode and row count — never result rows [F: the PC write rules].
• No shared or global row is edited for one product — scope the value, reuse the code, check the consumers [F: the PC reuse-before-create rule].
• No invention. A missing value is an open question, not a plausible guess; an invented value looks finished and prices wrongly F: [verify, don't guess].
• No personal data. Configuration holds none in the clear: identifiers in intake are substituted by case-local handles at the connector before storage (operator-agnostic case); only material that is personal data is rejected as wrong input (Platform Details PG-7, CG-9, D57).
• No unilateral code work. A rule the layer cannot hold is a handover to the customer-specific development module at gate Hd, never an approximation.

7.6 Ownership

P One author owns one stage prompt and its memory domain, and the five are disjoint: configuration/normalization, configuration/abacus, configuration/ipal, configuration/offer, configuration/serdica. No two stage agents write the same domain — that is what makes the pairs independent. Writes stay inside the own domain; cross-domain findings are handed over (Agents Memory § 2). Prompts are versioned and published through Agent Framework — the owner changes, the prompt-publisher role makes live — so five authors work independently without colliding.

P Each stage carries its own eval set — the author's proof that their stage works, runnable without the other four. The module's round-trip golden set (Configuration Module § 6) is the joint test and runs after.

Challenges

• P Loop-back semantics — P a re-entered stage amends, it does not replan (Measurements § RE § 12, generalising the 9951 run): it keeps plan and build state, takes the reported gap as a delta item, appends plan revision n+1 (trigger, affected steps, kept steps), applies only the delta with skip-done semantics, and re-runs its test phase in full. Replanning is reserved for a gap that falsifies a plan premise (process fit, object codes, deployment scope) — which is a gate to Development, not a loop-back. Confirmed on the first real loop-back.

8. Real material — eight live cases

P Reading status. These walks preserve the evidence and gaps that shaped the design. Where a walk quotes an older gate, ownership or completion rule, the current runtime, gating and release contract above govern implementation; a historic gap paragraph is not a second runtime rule.

F Re-read against STAGING and PROD on 07.09.2026 (Configuration module — typical cases): CS-2, CS-3 and CS-4 are typical kinds of change on the customer's estate (CS-4 once in twelve months); CS-6 recurs in another form (the seam and the print, not the rating); CS-7 is typical as a failure mode; CS-1 (Ablera dev) and CS-5 (QA) are architecture tests that never ran on STAGING; CS-8 is a mapping exercise, not a case. The eight miss the three highest-frequency kinds — threshold relax and revert, bypass and visibility lists, broker and channel templates — and the census behind them: four new products in twelve months against hundreds of monthly row changes to the existing sixty, 31 of 68 Jira configuration tickets applied on PROD directly, 38 of 42 HDesk asks naming INSIS. The typical-cases page carries the twenty-five real kinds (CF-01 … CF-25) and the eleven challenges they raise against this page.

P Each of the 25 has a journey. CF-01 … CF-25 are traced through the platform as designed — the requested delta against a fresh export, the selected stages and their sign-outs, the rating and offer proof, the preview the business looks at, the gated deployment set, the reversal and the restoration of a temporary change — in the interactive case walkthrough, case by case from Typical cases. Case journeys § 5 owns the delta, fan-out and release rules; Case Protocol the service boundaries.

Real material: the 9951 template and tariff (extract lines 4322–5480), knowledge/motor_tariff_2026.md, HelpDesk 00097807 (3607), 00098747 (2214/2215 promo), 00104411 (4727 Гуми), bst_health/, memory/reference/cargo_products.md, .claude/skills/configure-product/skill.md.

Conventions: [gap] = the architecture is silent or breaks; [ok] = the architecture answers the case. Page references are Page § n.

CS-1 9951 «Каско Максимум» replayed through v2

The case. 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). Eight covers, six mutually exclusive clauses, five offers each naming a template (CM_D400, CM_D200, CM_D000, CM_D000_ADV), nine tariff layers = 3 deductibles × 3 vehicle groups, 378 cells, tax 2.5 %, LDs applied SUMарно. Single environment, no deployment, personal session.

Intake. The configuration root reads the two files through connector readers and asks the operator: new product (yes — Продукт!B2 says 9951, "да се потвърди, че кодът е свободен"), working environment (dev), deployment set (full — a new product), donor (4704 or 4703, motor, object CAR; CG-2 says desirable not required). First plan revision records stage set S1–S5. Ledger: CASE_OPEN, grants DEV/IPAL/read, DEV/ANLT/read, DEV/gateway/read; every write grant arrives later, per gate.

Deployment. Set = full; target = Bulstrad QA. H4: five script sets + teardowns; QA execution is H4 + the effect applier because QA is not customer-facing; STAGING/TEST and PROD use H5 (D114). [resolved — Gating § 1 / D114]. On QA the set is deployed in dependency order; smoke = getRates reference quote + offer resolution + route/label check, read-only. Teardown at H7 derives from the write log; irreversibles named: consumed policy numbers from the S3 test issue on dev.

Ledger. GATE_DECISION ×(H1, H2×5, H3×5, H4) — no H5, because the target is QA and QA is not customer-facing (D114) — GRANT bound to statement hashes, WRITE_LOG rows with row counts never result rows, MEMORY_WRITE when configuration/abacus learns a new engine refusal.

Where it breaks / is silent. (A) the proof-level ceiling under POL-only has no exit path; (B) S5 surface omits numbering/print; (C) H5 wording; (D) product.schema.json offers[].conflicts is a free array while the live table is flat per cover — the PC extract's „known gaps in this shape" (conflict group, object scoping of LBRR rules, LB_COVERS_DEF dimension/currency, LD rating table/formula/cap, ld.rate cannot round-trip, ld_constraints, top-level limit_restrictions, documents, annex_types) are not carried into the v0 schema, though Stage Normalization § Challenges says the catalogue is „the PC model plus the sections the estate's own products need".

What this case asked of each stage: S1 in Stage Normalization · S2 in Stage Abacus · S3 in Stage IPAL · S4 in Stage Offer · S5 in Stage Serdica

CS-2 2026 EUR tariff on 4710 ГО and 4704 Каско — abacus-only

The case. Bulstrad publishes the 01.01.2026 EUR tariffs (two PDFs in knowledge/sources/). 4704 has 71 DEPLOYED versions (broker templates, e.g. ER_RENT_EUR), clause covers CASCO_FULS/CLAUSE1-3/CASCO_B plus 17 add-ons; 4710 prices by region I–V × fuel × cc × kW × age with fixed premiums for non-passenger vehicles and a short-term scale (30/50/70/90 %). The PDFs carry matrices the knowledge file does not transcribe (buses, trucks, trailers, machinery at three deductibles). Nothing structural changes; the ask is „new numbers from 01.01.2026".

Intake. Root: task = tariff change on existing products, stage set S1 → S2, deployment set abacus only. Environment path per D123 for the policy-administration line: the working environment is local/dev, the first target is bulstrad-staging (TEST) — customer-facing, so H4 + H5 — then PROD. Two products → two cases or one? Agent Runtime § 11 impact keys are per product/version, so two cases; the operator will want one.

Deployment. 71 version inserts + rating files + compile per version; on PROD, genRuleTable resets the running engine's cache (extract line 3976) — a customer-visible effect during business hours. Effect class: compensable? irreversible? Failure and Recovery § 2 lists cache state as outside rollback but no stage page names the compile as a scheduled/irreversible step. Smoke: getRates read-only against PROD for each template — [ok], computes and stores nothing. H5 = customer-facing environment: [ok] here (D114).

Teardown. Old versions stay DEPLOYED with earlier effective dates; teardown = set new versions back to DONE/delete the rows written. Written policies quoted on the new versions in between are irreversible — name it.

Silence. (E) live-code mapping in S1 without DB; (F) one template per spec; (G) set revision protocol; (H) compile as a production-visible effect with its own effect class.

What this case asked of each stage: S1 in Stage Normalization · S2 in Stage Abacus

CS-3 HelpDesk 00097807 — 3607 „трудова злополука": new clause, loading, minimum premium

The case. 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". Category: „ИНСИС > Продукти: конфигурация/промяна" — 3607 lives in both INSIS (Матрица) and IPAL; Ablera implemented in INSIS first, then „при одобрение ще я приложим и в IPAL".

Intake. Root: change to an existing product, dual-system, stage set S1 → S2 → S3 (new cover + LD + definition), S4 (the clause must be selectable — an offer cover row), deployment set abacus+ipal at least; working environment local/dev, first target bulstrad-staging (TEST — which needs the INSIS TEST side too), then PROD (D123); a companion Development sub-case is likely from the start. [resolved 02.09.2026 — D57] The intake of a HelpDesk ticket brings a named reporter, three named employees as a requirement („only Зорница, Валя, Захариев may convert"), and eleven policy numbers (3607260100000015 …); personal data is removed at intake — identifiers and detected names are handle-substituted at the connector before storage, the case is operator-agnostic; only material that is personal data is rejected as wrong input (Configuration Details CG-9).

INSIS side. Ablera changed INSIS first (Forms/PL-SQL rules, CFG_GEN_COVERS clause × perils for the new clause, HT_INSR_TYPE untouched). [closed by Stage IPAL § The INSIS side / D85] No configuration stage writes INSIS; the contract and seam are one PL/SQL script, recorded as a named deliverable with an owner. For a dual-system product the order matters (INSIS first so the transfer has a target), but no INSIS connector or teardown checklist belongs to this module.

H3. The customer tested on TEST across two months with real-looking policies and found the group-count bug and the short-term miscalculation. In v2 the policy skill asserts the persisted structure but the premium assertion belongs to S2's worked examples — which for a per-person count need examples with 1, 5, 6 persons split across groups. Stage Abacus: „the plan names the expected premium per worked example" — [ok] if S1 wrote those examples; the ticket gives none until the customer's xlsx arrives (3607_Tariff_TESTS_16032026.xlsx) — an unresolved[] „no worked examples in source" should block H1.

Silence. (I) CG-9 scope on HelpDesk intake; (J) per-cover chosen sum shape; (K) checks/validations have no stage; (L) INSIS side has no stage, connector, grant or environment pairing.

What this case asked of each stage: S1 in Stage Normalization · S2 in Stage Abacus · S3 in Stage IPAL

CS-4 HelpDesk 00098747 — 2214/2215 promo „65 години Булстрад": pay 60 months, get 65

The case. Home products 2214/2215: for the campaign, term 65 months, premium for 60; everything else unchanged. Also „трябва да го има и в Матрица" (INSIS/PORTAL channel). Closed ticket — Ablera delivered.

Intake. Root: packaging/term change on existing products, time-boxed. Stage set: S1, S3 (duration factor values — DURATION/DURATION_DIMENSION lists come from PR_PRICING_FACTOR_DEPENDENT), S2 (a version where 65 months prices as 60: either a rate condition on duration or an LD of −5/65 on the annualised premium — the honest reading is a tariff constraint „premium(65) = premium(60)"), S4 (a promo offer? the ticket does not ask for a package; the existing offers stay). Deployment set abacus+ipal. Working environment local/dev; first target bulstrad-staging (TEST), then PROD (D123).

Матрица. The PORTAL channel skips IPAL's checks (field_validation_frameworks.md); the 65-month rule must exist in INSIS too. Same as gap L.

Teardown after the campaign. The campaign ends; the 65-month value must stop being offered while issued 65-month policies stay valid. CG-8 makes reversal first-class and H7 gates it. [closed by Configuration Module § 3] Time-boxed configuration is a case type with an end date, a scheduled H7, and a teardown that distinguishes „stop offering" from „remove".

Silence. (M) closed constraint enum; (N) time-boxed configuration and scheduled reversal; (L) again.

What this case asked of each stage: S1 in Stage Normalization · S2 in Stage Abacus · S3 in Stage IPAL · S4 in Stage Offer

CS-5 Product 8000 „Здравна грижа" — packages × levels × options, cover modes, a Camunda process, CG-9

The case. 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. Suppose Bulstrad Life asks for a new package „Extra Care Plus" with a fourth level, or a second health product.

Intake. The health line works on QA and ports to master, with the planned bulstrad-prod-2 as its eventual target (D123); stage set full; deployment set abacus+ipal+offer; process: existing health BPMN — S3's pre-check must establish whether it is product-parameterisable. It is not: HealthBasicProductId=8000 is a constant (bst_health generic guide § 0). A second health product is Development work before S3 can start — a legitimate Hd at plan time. [ok] (Stage IPAL: „no is a deploy boundary → Hd, never a forced near-fit").

CG-9. The handover corpus's tariff worked example (UAT workbook Tariff HC_Bulstrad.xlsx) and the census sheets contain member names, dates of birth and ЕГН; the template's premium sheet defines a census list as the rating input (Пол, Дата на раждане, …). [resolved 02.09.2026 — D57] Worked examples for census-rated products are synthetic (age band, gender, count), marked so; stray identifiers are removed at intake, and only material that is personal data (a real census file) is rejected as wrong input — the stop no longer fires on the corpus.

Silence. (O) census-shaped worked examples vs CG-9; (P) level variants and cover modes have no spec shape; (Q) claims-side ABACUS configuration has no stage or skill.

What this case asked of each stage: S1 in Stage Normalization · S2 in Stage Abacus · S3 in Stage IPAL · S4 in Stage Offer · S5 in Stage Serdica

CS-6 Cargo 1101/1102 — a product that transfers to INSIS, with no INSIS structure in the spec

The case. Bulstrad asks to add HSSC (HelpDesk 00102452 „Добавяне на HSSC по всички кодове по Карго") — a new ICC cover across 1100/1101/1102/1103 — and, separately, a new print variant. Cargo facts: children carry the framework number + 3-digit counter and do not use CFG_POLICY_NO_SEQ; the tariff is a per-framework rate on POL_PREM_RATE (sometimes an absolute amount with rate_dim='V'), not an ABACUS grid; covers ICC_* map to INSIS CARGO* via CFG_MAPPING_COVERS; DOCUMENT_TYPE gates two print sets; policies are foreign-currency native; DUE_DATE reaches O_CARGO.OCGP9 through CFG_MAPPING_FLFLD.

Intake. Root: cover addition on a dual-system family; stage set S1, S3, S4 (offer cover row per product), S5 (labels, print), and the INSIS contract + seam — which are not stages. Deployment set „abacus+ipal" is wrong on its face: there is no abacus work, rating is policy data. [closed by Configuration Module § 3] The deployment set is any subset of stages in dependency order; a family whose rating is not in ABACUS uses „ipal only" or „ipal+serdica".

Transfer as verification. „Issuable" for cargo means transferred to the customer, but the configuration proof ladder ends at issued (Configuration Module § 7.4, D85). [closed by Stage IPAL § The INSIS side / residual: transfer proof is a Support case] The seam deliverable is recorded, and /check-transfer-style verification belongs to Support rather than to a configuration rung.

Teardown. The INSIS side of a test transfer (POLICY, INSURED_OBJECT, GEN_RISK_COVERED, PREM_INST, GL) is not undone by deleting IPAL rows; the SD-1515 recipe shows what a reversal costs (Bulstrad-IT storno + Forms + date shifts). [closed by Stage IPAL § The INSIS side / residual: Support verifies transfer].

Silence. (R) deployment-set vocabulary — status: closed by Configuration Module § 3; (S) tariff required — residual: schema contract; (T) no transferred rung — status: closed by Stage IPAL § The INSIS side / residual: Support verifies transfer; (L) INSIS side — status: closed by D85.

What this case asked of each stage: S1 in Stage Normalization · S3 in Stage IPAL · S5 in Stage Serdica

CS-7 Mid-run discovery — the missing factor and the bundle rate

The case. Two discoveries after H1, both from real material. (a) 9951's Правила за премия: „CM_ASSIST — фиксирана премия по серия на картата и възрастова лента"; the questionnaire has no question for the card series, and the offers hard-wire series С to BASE and Д to FULL. The rating grid keys on a factor the spec's factors[] does not declare. (b) 4704 clause packages: the PDF gives one rate for „Пълно каско" (fire + accident + malicious + theft) while 9951-style IPAL covers are four codes; the customer wants the four covers priced separately on the policy print. The published bundle rate does not tell the split (Stage Abacus § Challenges: „always a question to the human, never arithmetic"). And (c) HelpDesk 00104411: „the answer to Q4 (Гуми limit) must be mandatory when CASCO_R is selected" — a conditional requirement.

What the architecture says. Configuration Module § 7.1: „a stage that needs something its input does not carry raises it as an open question against S1 — it does not infer the value, and it does not reach back into the source documents itself." Agent Runtime § 11: a question parks the affected tasks only; the answer updates the plan revision; verified work is never discarded. Stage IPAL § PF-6: „a conditional requirement in a specification is raised as an open question, never guessed" — and the flat QT_REQUIRED cannot express it, so the eventual answer is Hd (code) or a CFG_FLD_VALIDATION check (gap K).

Walk-through (a). S2 at plan time (phase 2) finds the grid axis CARD_SERIES absent from factors[]. It emits Question to the root: gap = „grid axis CARD_SERIES undeclared", checked = factors[], objects[] attributes, depends = CM_ASSIST rating and the BASE/FULL offers, alternatives = (i) operator factor LIST {С, Д} at policy level, (ii) derived from the offer (BASE ⇒ С) — a constant per offer, (iii) drop CM_ASSIST from the run. [closed by Configuration Module § 7.1] The S1 owner edits product.json, the validator re-runs, the specification gets a revision linked to the question, and the human confirms only the delta at H1a.

Walk-through (b). The bundle split is a business decision (how much of 4.94 % is theft). S2 records not_held_by_rating[]? No — it is held by rating once split. It is unresolved[] blocking for S2, non-blocking for S3 (the catalogue does not need the split). MISSING paper: what = split of clause rate over four covers; why = cover_rates per cover; where = Bulstrad actuary; blocking = S2 yes, S3 no. [ok] the paper shape carries this. The parking rule lets S3 proceed on the catalogue while S2 waits — Agent Runtime § 11 „parks the affected tasks only" [ok]; S3 may start on the factor codes fixed at H1 before the S2 summary exists, and every rate-reading assertion waits for the summary revision it cites. [closed by Configuration Module § 7.1].

Walk-through (c). Conditional requiredness: S3 plans an open question at H2; the operator answers „yes, mandatory when selected". The layer cannot hold it (flat Y/N), CFG_FLD_VALIDATION might (a conditional check with an overrule group), else Hd. The answer path is clear once someone owns checks (gap K). The 4727 policy was registered through Матрица — the check must also exist in INSIS (gap L).

Ledger. Question and Answer records with the gate id; a PLAN revision 2 for S2; the spec artefact hash changes; GATE_DECISION for the re-opened H1 — whichever name it gets.

Silence. (U) post-H1 specification amendment; (V) S3 partial start before the S2 summary.

CS-8 The twelve configuration parts onto five stages

The case. /configure-product proposes twelve parts plus five optional ones and asks scope before writing. The module claims v1 skills are „evidence and seeds … never runtime components" (Configuration Module § 0). Map each part to a stage and see what falls through.

Where the skill and the module disagree. The skill's part 2 says „pricing factors (× QT and POL)" and its acceptance check 2 tests for a missing QT row on quote-step products; the module says POL only, no exceptions, and the QT dependency is MISSING. product.schema.json carries no factors[].collected_at_quote key: it was removed on 02.09.2026 together with the POL-only rule (Stage Normalization § WS-2). [gap Y closed 02.09.2026] The skill's rule 2 „core tables are not altered without permission" (the CFG_POLICY_NO_SEQ.PRODUCT_CODE VARCHAR2(4) case) is DDL: the effect applier applies it under HW-ddl with the current D65 stage identity (D104).

Proposal. Superseded by D85: INSIS side is one script, no sixth stage. The explicit ownership rows in Configuration Module § 7.1 cover checks, tariff request, commission, reinsurance, BSO and questionnaire; INSIS-side parts stay named deliverables outside Configuration.

Gap table

Coverage

Exercised. Configuration Module § 7.1 consume/produce for S1–S5 (CS-1) and „raise against S1, never infer" (CS-7); § 7.3 assertion form (CS-1, CS-2); § 7.4 done test items 1–5 and the proof ladder (CS-1, CS-6); § 7.5 no writes outside own targets (CS-2), no shared row (CS-4), no invention (CS-7), no personal data (CS-3, CS-5), no unilateral code (CS-3); § 7.6 one author/one domain (CS-8). Gates: H1 (all), H2 (CS-1, CS-3, CS-7), H3 (CS-1, CS-3), H4/H5 (CS-1, CS-2), H6 (implied in CS-7 only), H7 (CS-1, CS-4, CS-6), Hd (CS-1, CS-3, CS-5, CS-7). Rules: CR-2, CR-3, CR-7, CR-8 (CS-3 intake content), CR-9 (CS-2 compile). Stage Abacus § SUM-1…SUM-6 fields (CS-1, CS-2). Stage IPAL § PF-2 axes 1–10 and § PF-9 order (CS-1, CS-3, CS-4). POL-only rule and remark (CS-1, CS-8). Layer model and reconciliation (CS-1, CS-2). Contradiction-as-question (CS-3, CS-5). Parking (CS-7). Deployment sets abacus-only (CS-2), full (CS-1), „ipal only" (CS-6). Failure and Recovery § 2 effect classes (CS-2, CS-6), § 5 exemption test (CS-2).

Never exercised by these cases. Configuration Module § 7.6 per-stage eval sets and the round-trip golden set (§ 6) — no case exported a selling product; Agent Runtime § 2 budget thresholds and § 6 compaction; Failure and Recovery § 3 worker death / poisoned resume; Failure and Recovery § 1 shape B (leased transaction) — every write here fits shape A; Agent Framework § 6 prompt lifecycle; Agents § 0 auto-learning a domain; Agent Runtime § 11 session handover between operators; the validator profile's isolation (assumed, not tested); the depth of Trust and Data § 4 — configuration substitutes handles at intake like every module (D57), but no case here exercised a handle map across a module boundary; Stage Offer's rule-combination sampling challenge; the S2⇄S3 „needs minimal catalogue first" loop as a planned step rather than the s2_bootstrap fact.