Configuration work procedures

P These are the substantive methods used by the Configuration module. A method explains how an agent accomplishes a domain task, including its LLM decisions, evidence, optional executable helpers and proof. It is not a list of model-facing API verbs. Reading a connector, storing a paper, confirming a plan and executing an approved packet remain runtime operations. A source/binary helper automates a specified part of a method; it does not replace understanding the requested product.

P The methods use the existing S1–S5, joint and release identities. A case selects only necessary work and records the evidence supporting skipped stages. S3→S4 and S5 can prepare in parallel when their inputs permit; actual writes still follow declared dependencies. Here S4 Offer means an insurance-product package or selection, such as its covers and limits. It does not mean the commercial offer to perform a customer's change request.

Source basis. The existing configure-product procedure, the five stage pages, the configuration input and change contracts, and all 25 configuration cases ground this page. The case narratives are representative proposed executions derived from that evidence. Their success states are examples of required proof, not new observations of a running v2 system.

1. Choose the work from the request

P The root records the requested outcome, intended sales/operating surface, target environments, existing product or new product, required date and source documents. The question is what must change, not which stages can be filled. A request may be a lasting rule change, an explanation, a target-reconciliation report, or work that belongs elsewhere.

P CF-01's temporary threshold exception and CF-22's BSO batch belong to the existing Support/Data & Manipulation procedures. CF-17 asks for an INSIS-native product with rating and an interface seam; it does not justify constructing an IPAL sales catalogue. CF-25 may require only a comparison report. A product role definition or bypass rule is distinct from assigning an actual account: identity administration retains its declared owner and data boundary.

P Each selected agent receives a bounded task: objective; the relevant source/specification revision; current baseline and environment; predecessor result references; questions it must settle; expected outputs and falsifying examples. It returns its plan to its immediate parent before dependent work. Only relevant helper agents and procedures are selected. Consults to Data or Development return evidence; changed work and authority go through the root. A shared-Core requirement becomes classification and request/offer/delivery communication, with no Core implementation pipeline. Incumbent-system code remains with its external owner.

P Experience retrieval is part of the domain method. Search the relevant stage's articles, prior product/source requirements, confirmed mechanisms and reusable procedures; broaden the search vocabulary when a business phrase differs from its technical name. Read the underlying evidence and test current applicability. A similar product code, old successful deployment or retrieved template is not sufficient. CF-05 requires current selector/version facts; CF-18 requires the current source revision; CF-21 and CF-25 require semantic and directional comparisons, not a row-count match. See memory, skills and tools for ownership and reuse rules.

2. S1 — understand and normalize the source set

Owner: configuration.normalizer, with an isolated configuration.source_analyst when tariff interpretation is needed. The measured database prober answers narrowly scoped estate questions without seeing the product intent. Stage Normalization owns the detailed specification model.

Interpret before validating a representation

P Extraction produces evidence, not meaning. Preserve the original file and the relationship between text/table cells and file, sheet, range or page. An extraction should expose unreadable text, merged headings, formula/cached-value differences and absent sheets. openpyxl or pandas may help enumerate tabular data; neither can decide what a tariff heading qualifies, whether a clause is mandatory, or which of two emails changes the agreement. Do not treat a parsed sheet, a file name or a successful parser exit as a specification.

P The normalizer restates the requested product in business terms: objects, covers, definitions, factors, tariff, loadings/discounts/taxes, package wishes, required surfaces and worked examples. It determines which sources support each statement, identifies omissions and contradictions, and sends unresolved business decisions through the root. It does not silently choose a convenient source or infer an absent rate. For an existing product, it maps the confirmed meaning to current live_code/live_match evidence; the independent tariff reader remains DB-blind so today's storage cannot bias the interpretation.

Recorded example — 9951. The source-reading problem was not multiplication. The tariff repeated tables under three deductible variants × three vehicle groups, with the axes implicit in the material. The LLM had to identify those qualifiers and reconcile their meaning with the workbook before a helper could check that the model contained nine combinations. A program multiplying two supplied cardinalities cannot discover that the author omitted an axis. The 9951 reference and S1 model rules are the evidence for this distinction; nine is this example's result, not a product-wide constant.

Keep three different checks visible

F validate_product.py reads the JSON model, not the original tariff PDF or workbook. Its checks called “semantic” are executable model-consistency rules: for example reconciliation.*.in_model, claimed_in_source, recomputed counts and tariff.layer_model. Both claimed counts and interpreted content can be wrong in the same way. A JSON model with the wrong cover meaning can therefore be internally consistent. Record which checks ran; skipped structural validation is not passing structural proof.

P Rendering comes after the authored model. product.md and the HTML review are projections; corrections are made in JSON and rendered again. A deterministic renderer is a necessary helper, not an LLM semantic validator. The stage describes its input/output contract; this page does not claim that a named v2 renderer package has already been implemented or published. Similarly, a message-extraction script is only evidence for the formats it actually supports, not a universal document-understanding tool.

Existing products, multiple templates and revised material

P Use the current configuration-change contract for a scoped delta. Its literal fields include request_ref, selected_stages, targets[].baseline_ref, schema_ref, scope_ref, changes[].before_ref, desired_ref, assertion_refs, shared, input_bindings, skipped_stages, templates, obligation_refs, execution_obligations_ref and stage_edges. These preserve what changed and what each consumer relies on; they are not substitutes for the source interpretation.

CF-05: each declared template work item carries key, selector_ref, role_scope_ref, effective_from, product_spec_ref, target_ids and assertion_refs. The KOLHIDA_EUR/MAXO_EUR walkthrough is a composite of documented template and selector mechanics. It supplies no invented tariff numbers. S1 distinguishes the caller, insurance offer, template, effective date and seller visibility; S2, S4 and S5 then prove their own part of that relationship.

CF-18: a re-upload is not automatically a new product or permission to overwrite all prior work. Compare source revisions, identify changed requirements, retain contradictions, and produce a reviewable S1 delta. The runtime records supersession and invalidates dependent plans/results/acceptances. The LLM identifies which meaning changed and therefore which consumers need rework; software enforces the recorded dependencies. Unaffected work remains usable with its valid bindings.

Success and falsifiers. A reviewer can trace a material requirement to its source, see what remains undecided, and understand the selected work. Fail if the file parses but an implicit axis was lost; if a “default” price fills an unanswered tariff question; if two templates collapse into one selector; or if an affected stage still consumes a superseded requirement. H1 confirms the exact scope/specification revision; it does not grant target execution.

P Stage ownership. Each S2–S5 builder carries clarification, plan synthesis, selected execution coordination and sign-out in one domain task. It proposes preparation to the parent, then obtains the separately required H2/effect decisions. Domain-specific validators check S2 tariff, S3 catalogue, S4 package and S5 wiring respectively; configuration.integration.validator joins their evidence for joint/target proof. This retains the existing workflow and avoids a chain of agents that each sees only a fragment.

3. S2 — understand the tariff and make the selected version price

Owner: configuration.abacus.builder; independent configuration.abacus.validator checks the claimed result. The substantive procedures are abacus configure, getRates test, and the abacus seed handover when S3 needs it. Stage Abacus, Rating Files and Premium Vocabulary carry the detailed mechanics.

P LLM decisions. Determine each rate's base and dimension, grid axes, discount/loading scope, order and combination, and whether the rule is representable by the existing engine. A grouping of existing values may be a level set; a new computed factor or unsupported filter is a capability dependency. Preserve deliberately unpriced covers and explain the proof limit. Do not approximate an unsupported business rule into a convenient grid or equate compilation with correct pricing.

P The summary schema is a draft wire contract. Its field names are not all identical to the longer conceptual vocabulary on the stage page—for example stage/template versus “version stage”/“template code.” Bind the implemented adapter to the actual schema and explicit extension fields; do not silently serialize a different property name because the prose used it.

P Helpers and operations. Parsing a fixed grid format, comparing component arithmetic and preparing repeatable input fixtures can use concrete executable helpers when available. Creating versions, compiling, deploying a working rating version and resetting caches are engine/connector operations with effects. getRates is the stateless pricing call; choosing the correct factors and interpreting its result belongs to the method. The direct-call recipe also describes a historical SQL token helper with an autonomous cache write: that credential acquisition is not a read-only getRates primitive.

Success and falsifiers. Compare selected covers, base premium, each loading/tax component and roll-up with the approved examples and currency. The response's complete rates[] catalogue is not the set of selected covers. CF-04 fails if an older deployed version prices the request. CF-05 fails if KOLHIDA/MAXO callers silently receive fallback, even when both versions compile. CF-06 fails when an LD type row exists but the operative rule is absent. Check effective-date boundaries and unaffected templates. Never invent a numeric oracle when the source has not supplied enough to derive one.

4. S3 — turn the specification into a usable catalogue and process registration

Owner: configuration.ipal.builder, with independent configuration.ipal.validator. abacus seed transfers only the rating-owned skeleton; ipal configure completes the business catalogue; policy test proves the declared use. Stage IPAL owns the field and dependency detail.

P LLM decisions. Interpret how a document cover fans out by object; which limits/deductibles belong to each cover; which factors are answered, derived or passed through; whether a donor code has the same meaning; and whether a deployed process actually fits the requested product. The rating summary supplies rated codes/axes/LD scope, not product names, risks, documents or package wishes. Those still come from the specification. CF-16's variant must adopt only fitting donor structures; CF-21's nomenclature reload must preserve existing tariff and historical meaning.

P Current v2 policy writes pricing factors with SALE_STAGE='POL'. The v1 configure-product seed also documents conditional QT use in the existing estate. Do not copy that legacy step into v2 to make a test pass. If the target's quotation path still requires QT, record the capability gap and supported proof level; the necessary process/UI change goes to its owner. Likewise, an INSIS-native question, clause or code change remains a named external deliverable, not an implied unrestricted INSIS configuration tool.

P Helpers and operations. A measured schema probe, known projection of rated cover/LD/factor data, key comparison or fixed assertion script may automate mechanical work. The agent still chooses the semantic mapping and handles unsupported variants. Registered configuration endpoints or approved templates produce the scoped changes through the runtime auditor/gates/executor. This page introduces no generic “catalogue-builder” binary. Process inspection is a connector read; registration is an effect; authoring/changing the process is separately owned work.

Success and falsifiers. CF-07's value appears under the right parent and reaches the intended downstream code; a populated dropdown alone is insufficient. CF-10 preserves legitimate target-only definitions. CF-12's new cover has every promised dependency. CF-14's question is actually required/consumed where promised. CF-15 fails if the transfer ignores its row. CF-23 checks historical and unaffected commissions. CF-24 fails when the column exists but values are null or never selected. Quotation/issuance proof waits for the required wiring and package branches; test issuance has its own number, document and workflow effects.

5. S4 — construct and prove insurance packages and cover selection

Owner: configuration.offer.builder, with independent configuration.offer.validator. The method is ipal configure for packages/rules plus offer test. Stage Offer and the LB/LBRR reference define its domain.

P LLM decisions. Translate “standard,” “extended,” required options, restrictions and customer descriptions into explicit selections and rules. Separate the insured object's segmentation from the role of the seller. Decide whether the requirement is a package preset, a relative limit, a dependency/conflict or a rating-template selection. Unclear business combinations remain questions, not arbitrary defaults.

Concrete surfaces. LB_OFFERS, LB_OFFER_COVERS.REC_EXTENT (M mandatory, R recommended, O optional), LB_COVERS_DEF, LB_COVERS_DEF_RULES, LBRR_COVER_DEPENDENCY, LBRR_COVER_CONFLICTS and LBRR_LIMIT_RESTRICTIONS carry different meanings. LB_OFFER_PRICING_RULE.TEMPLATE_CODE links an offer to rating. The documented selector chain TemplateOfferCode → OfferCode → LbOfferPricingRule.TemplateCode → config.DefaultTemplate → DEFAULT_TEMPLATE can fall back silently. Show intended and fallback paths separately.

P Helpers and operations. Fixed selection matrices and known rule assertions can run as executable checks. The agent selects the meaningful combinations and explains a counterexample. Offer resolution and getRates are connector calls; an actual issued test is an effect. Templates can prepare the admitted rows, but cannot decide which cover combinations the insurer meant.

Success and falsifiers. CF-13 must reject forbidden combinations as well as price valid ones; “available” must not become “selected.” CF-05 requires the intended caller to select the intended template/version while default callers retain their declared behaviour. CF-12/CF-16 must show the new clause/variant with its correct package, not an inherited donor selection. A happy-path quote with wrong optionality fails the method.

6. S5 — make the configured product reachable and correctly presented

Owner: configuration.serdica.builder, with independent configuration.serdica.validator. The methods are the wiring part of ipal configure and the route/label/endpoint check. Planning may run beside S3→S4; write prerequisites and the final customer journey still join. Stage Serdica owns the precise wiring rules.

P LLM decisions. Determine which actor should see and use the product, which labels are authoritative, whether a message key is shared, which document/copy/parameter set is intended and which numbering principal/office/year applies. Distinguish a navigation issue from backend access, a DB message from a frontend source translation, and a print registration from a BI template/evaluator change. Preserve deliberately different meanings across surfaces rather than “harmonising” them without a requirement.

P Helpers and operations. A known language-key sweep, numbering metadata comparison or document-set assertion may automate the declared checks. The LLM interprets audience and intended output. Connector reads supply current evidence; cache refresh, sequence DDL, message changes and printing are effects with their applicable decisions. No stage gains permission through a helper's name.

Success and falsifiers. CF-20 requires both navigation and backend denial for excluded roles. CF-03 must not widen unrelated bypass/visibility rights. CF-11 requires the actual visible approved text after the correct refresh. CF-08 checks wanted and unwanted documents and exact copy counts; an unknown selector that emits extras fails. CF-09 verifies principal resolution and an explicitly authorised number-allocation test; a used counter is never reset merely to make that test succeed. CF-19 includes expiry behaviour; hiding a product must not erase definitions required by issued policies.

7. Joint proof — verify the requested product as one result

Owner: independent configuration.integration.validator, with root-owned scope and acceptance. It receives objective, source/specification revision, selected stage sign-outs and evidence; it does not receive the author's reasoning as the answer to repeat.

P The validator decides whether the claimed proof level follows from the evidence and identifies separating counterexamples. Check coverage against the actual request, not the number of green stage cards: intended caller → selected offer/template/version → factors → rated selected covers → visible/persisted result, with only the surfaces the customer requested. Include forbidden selections, excluded actors, effective-date edges and unaffected siblings. An INSIS-native request must not be graded on an invented IPAL issuance journey.

P Mechanical assertions may replay known inputs and compare outputs. Independent semantic review still asks whether those examples actually test the requirement. If every test uses the wrong rate base, green arithmetic proves only consistent execution of the wrong interpretation. Transfer or external INSIS proof is obtained through the accountable Data/external-owner work and joined as evidence. An external report alone is not verified completion.

P The sign-out draft carries tested, what_next_phase_needs, open_items, artefacts, signed_by and optional supersedes. Use real result references and hashes. Its legacy phase payload vocabulary is not a replacement for canonical manifest stage ids. Working preview, requested target delivery and customer acceptance remain separate scopes; CG-11 for a preview does not close a production-delivery obligation.

Falsifiers. CF-05 has two compiled templates but only one selected by callers; CF-12 prices a cover that cannot transfer; CF-17 proves ABACUS while INSIS-native use remains blocked; CF-18 joins old and new revisions; CF-24 proves a column without its consumer. Each fails the relevant requested result even if individual structural checks passed.

8. Release, recovery and what the next request reuses

Owner: configuration.deployer coordinates the selected target set; independent verification checks the target result. The runtime performs enforcement and connector execution.

P LLM work. Reconcile the approved working result against each fresh target baseline, identify legitimate target-only differences, select the compatible order and explicit external dependencies, and explain recovery limits. CF-25 demands direction and disposition for differences, not whole-estate synchronization. CF-10 preserves accepted target definitions. CF-19 separates stopping new sales from later retirement while existing policies retain valid terms.

P Deployment packet preparation. After the accepted working result, the deployer creates the delivery material for each named target: ordered API requests or parameterised SQL/configuration scripts as applicable; source/build artefact hashes where a coupled change is required; current schema/key bindings; preconditions and expected affected counts; post-checks; recovery steps and owner confirmations. These are generated from the approved semantic delta and fresh target baseline, never copied blindly from working ids. Packet review (H4), execution permission (H5 and any other applicable effect gate), application, independent target proof and required recovery remain part of requested delivery. They are not asynchronous precipitation. Joint proof and release-and-verify do each raise a precipitation event of their own: what the agreement and the target required is filed as a proposal and left to the asynchronous workflow, which never holds the delivery open (Stage Precipitation).

P Mechanical work. Use the declared endpoint or approved template for each admitted operation, with current target keys, expected counts, assertions and recovery references. H4 reviews the release material; H5 applies to customer-facing execution; shared-row, DDL and other effect requirements still compose. An effect journal or owner receipt is then reconciled with current state before retry. Unknown outcomes are not re-executed because a surrounding session ended.

P Proof and recovery. Establish which target version actually serves and repeat the requested actor/template/date/behaviour checks. A working preview, successful compilation or metadata row does not establish that fact. Required restoration or expiry obligations are durable. Compensation uses original effects and fresh state, preserves intervening valid edits and goes through H7 plus applicable effect requirements. Database rollback cannot undo issued numbers, generated documents, process instances or messages.

P Retained experience. After the verified result, retain the source request/revision, semantic decisions and rejected alternatives, actual target outcome, failed assumptions and current-applicability checks. The owning domain can improve its procedure or propose a concrete executable helper for repeated extraction/comparison/calculation. For example: a fixed grid-cell counter can save repeated enumeration; it cannot replace discovering a new tariff axis. The next request retrieves the method and rechecks current sources, selectors, schema and target state. It does not reuse old rates, surrogate ids, grants or completion claims.

9. Coverage of the 25 configuration cases

P The table names the required method emphasis, not an unconditional stage sequence. Typical Cases preserves the evidence; the linked walkthrough carries its illustrated path and concrete state transitions.