☰ Contents
AISA v2.0 / Technical documentation / The Product Configurator — the sibling that ran first

The Product Configurator — the sibling that ran first

F verified factP decided planC open challenge

A single-purpose configurator agent configured product 9951 «Каско Максимум» end to end on the Ablera dev environment in August 2026 — catalogue, rating, offers, routing — and then drove the sales wizard until a real premium rendered and reconciled against the tariff. It is the strongest existence proof the Configuration module has, and the only place in this wiki where a design statement can be marked proven rather than planned.

Three kinds of material come from it, and this page holds all three:

§ What it is Cite it for
SRC the published artifact and its 369 KB text extract — the primary source a fact about the run: what the agent had, what it lacked, what its own documents say
P the twenty load-bearing patterns, distilled so a reader need not open the blob a pattern the architecture adopts, by name and number
A · C · Q the three later configurator documents — Requirements, Design, Product design — reconciled with this wiki: what they add (A-1…A-20), where they contradict it (C-1…C-9), and what they leave open that the wiki already answers (Q) an estate fact the documents establish, or an open contradiction

Section ids are stable. § P-13, § A-19, § C-4 mean the same thing they meant before these three pages were merged. The schema facts found during the same run are on Schema Quirks, which keeps its own page because it is written as knowledge for an agent to read rather than as a record of the run.

SRC. The source — the artifact and its extract

What: "Inside the Product Configurator" — a published artifact documenting a working, single-purpose configurator agent with its own Claude Code workspace, "Serdica · product configuration".

Where: original at https://claude.ai/code/artifact/bc970674-6286-45b1-be55-1f5b0dbdc16a. That link sits behind a sign-in wall and is not a readable source; the readable source is the full-text extract in this folder, pc_agent_9951_artifact_extract.txt — 369 KB, the page narrative plus all 35 embedded documents plus the 9951 source tariff and template. Supplied by Vladimir on 31.08.2026 with the instruction to take it into account before creating the architecture.

Why it matters: it carries verbatim design decisions by Vladimir and Veselin — the tariff sub-agent's isolation, the round-trip test as the acceptance method, the tariff-file legend gap — and its own numbered requirements document (docs/01-REQUIREMENTS-FROM-MEETING.md, where R8 is the round trip).

SRC-1 The shape of the workspace

Not patterns — the arrangement the patterns were found in.

Everything else the extract states about how the agent worked is a pattern, and is in § P rather than repeated here.

SRC-2 What the run did not have

Named by the artifact itself. Each is a requirement on AISA Next rather than a criticism of the run.

SRC-3 The boundary it declares

"Policies, claims, premium collection, the conversational desk, ServiceDesk tickets — adjacent, and other agents own them."

An estate of focused agents is already in operation, including a shared memory fed by several of them. AISA Next is the case control, policy and audit layer over that estate — not a replacement for it. The boundary moved once: D76 and D81 withdrew autonomous production writes, autonomous customer-visible communication and a customer self-service surface from the exclusions and made them targets, reached one accepted risk class at a time. What remains excluded is N-12 — no autonomy the platform granted itself.

P. The twenty proven patterns

Cite a pattern by its number. The Lands in column names the page where the pattern lands; where a later decision widened or narrowed a pattern, the row says so. It is lands in and not used in because only five patterns are cited back by number from the page that applies them — P-7 (Factor Sources), P-9 and P-16 (Write Envelopes), P-15 (Stage IPAL) and P-17 (Shared Vocabulary); the rest land on a page that carries the practice without naming the number.

# Pattern What it proves Lands in
P-1 Sub-agents isolated by denied context — the tariff analyst's scope contains no database connector, so storage cannot bend its reading; the grader sees two artefacts and no provenance, so it grades output rather than remembered reasoning isolation is provisioning, not an instruction to ignore something Agents § 0.2
P-2 Scripts as the only write path, dry-run by default writes are reviewable before they exist, and repeatable after. Widened by D74: each system's own configuration endpoints are the primary write path, because an endpoint applies the system's own validation and leaves its own trail; what no endpoint reaches is written as guarded statements. Both paths run as instances of a person-approved write shape (D72), which is what keeps "reviewable before it exists" true Configuration Module § 7.5
P-3 Environment lock — refusal before connecting scope is enforced by the connector, not by the agent's intention Trust and Data § 2
P-4 Semantic contract — product-model.json: business vocabulary, per-element provenance, an element without a source is a guess the hard part (reading documents) is reviewable before anything is written Stage Normalization
P-5 Mandatory two-way reconciliation counts — claimed in source vs in model, with the evidence range named; a mismatch is a stop silent incompleteness becomes visible Stage Normalization § WS-4
P-6 The layer model — name the axes a tariff repeats over, and what carries each in the document defeats the three naive readings that gave 7, 3 and 6 where the answer was 9 Stage Normalization § WS-3
P-7 unresolved[] / MISSING as a deliverable — never invent; a missing value is an open question an invented value looks finished and prices wrongly Agent Runtime § 11.2
P-8 Plan steps with stable ids and one assertion each an unrun step leaves nothing that looks wrong; assertions make absence visible Configuration Module § 7.3
P-9 Resumable apply via a state file — completed ids plus platform-returned ids; children re-parent onto returned ids, never predicted ones a run is resumable rather than repeatable Failure and Recovery § 3
P-10 Write log records the statement, target, environment, mode and row count — never result rows reconstruction and teardown without hoarding data Trust and Data § 5
P-11 Teardown = the set written — the set removed is exactly the set written reversal is derived, not remembered Failure and Recovery § 2
P-12 Donor diff as a completeness gate — self-consistent checks cannot find absent steps; compare against a live selling product of the same shape, accounted rather than blind-copied completeness needs an external reference Configuration Module § 5
P-13 The proof ladder — structural → priced → reachable → quoted → issued; report the rung reached, never imply the one above verification claims stay honest. The ladder ends at issued (D85) — there is no transferred rung, because arrival in the incumbent system is proved by the Support module, which owns transfer investigation. Quoted and issued are the joint proof of both phase-2 branches (D75); neither branch may claim them alone Configuration Module § 7.4, CR-3
P-14 Round-trip acceptance — export a working product with its real sources, re-derive it in a clean session, diff, grade with the isolated grader, trend the score a golden set that tests understanding, not memory Agent Framework § 6.5
P-15 Peers own their systems; after two failed attempts at an unknown write contract, stop and ask the owner bounded improvisation — and it is the consult trigger of D92: the question goes to the owning domain, comes back as evidence, and if the answer needs a write in the other module the asking root raises it as a handover (Hd) instead Agents Memory § 3
P-16 Idempotence guards with four documented silent failure modes — the four are named in Write Envelopes § 8, and two of them cannot be fixed in the writer re-running a script set is safe, and where it is not, that is known Configuration Details CG-5
P-17 Reuse before create — reuse the code, scope the value, check the consumers; never edit a shared row for one product one product's change does not become every product's change Configuration Module § 7.5
P-18 Knowledge upkeep — belief order running system → consuming code → knowledge base; four kinds of wrong with four treatments; guide, not diary memory that ages honestly Stage Precipitation § 3
P-19 Counterexample before "platform defect" the evidence rule that keeps blame accurate Stage Investigation
P-20 Per-product working papers — plan, write log, run log, build state, deliberate omissions: what makes a run resumable rather than repeatable the case, not the conversation, is the medium Agent Runtime § 11.2

A. What the three configurator documents add

Three later documents describe the same configurator as a product: the Requirements (52 requirements in nine areas, counts measured on PROD 02.09.2026), the Design (the workspace: eight layers, seven prompts, two isolations, one seed) and the Product design (the same configurator as a deployed service: six services, three gates, the ABACUS write path). Reconciled with this wiki on 03.09.2026.

The rows below are the facts and rules taken over. Every fact is quoted from the document it names; every rule is a proposal until confirmed.

⚠ The counts in these rows are evidence, not content. They are Bulstrad's production estate as it stood on 02.09.2026, and they stay on this page as the argument that was made — they were not copied onto the module's pages. What went onto those pages is the rule each count argued for, stated without its estate; the counts themselves became the first entries of the estate prober's probe catalogue, re-taken per customer and per environment rather than cited.

# What the documents establish Where it lands
A-1 A product occupies four surfaces in two databases with no foreign key between them — SRD_IPROD (the product), SRD_ANLT (the ABACUS tariff), SRD_INTEGR (rules and the INSIS seam) and ABC_ACCESS on the INSIS database (INSIS-side ABACUS); two of the four have no maintenance screen [F: Requirements § 01] the surface map per stage in Components § 1
A-2 The INSIS-side ABACUS checks fire on the IPAL transfer, at three points, and CFG_ABC_FLD_VALIDATION holds 797 rows / 66 products at BEFOREPREM, 211 / 45 at AFTERPREM, 60 / 16 at CONVERT; TR_POLICY:732–738 reports a failed convert as transferred for every product except 4710 [F: Requirements § 01] Not a configuration stage (D85). The INSIS-side rows are one PL/SQL script per product, and the configuration proof ladder ends at issued — there is no transferred rung to verify. The TR_POLICY finding is a Support fact: transfer investigation must read POLICY_STATE and never the return value
A-3 Neither surface generates the other: product 2215 has 49 factors in PR_PRICING_FACTORS, 29 in PPA_FACTORS, 3 in its rate files; ppaSync carries the skeleton and no rates, is absent from bulstrad-prod and bulstrad-staging, and defaults taxRule='SUM' where every live product uses MULT; TRANSFER_PRODUCTS.CreateProduct (91 tables) touches neither SRD_ANLT nor ABC_ACCESS, so trProduct moves a product without its tariff [F: Requirements § 01] the deployer never uses trProduct; contradiction C-3 on the seed direction
A-4 The ABACUS → IPAL seed covers 98.4 % of covers (538 of 547), 91.6 % of loadings and taxes, 44.2 % of factors over the 63 products ABACUS knows; 290 covers and 210 factors exist only in ABACUS and are refused; COVER_TYPE is never invented; nine parts (≈ 7 870 rows) have no ABACUS counterpart; per-product coverage ranges from 78 % (2200) to 11 % (4800); it is a one-time seed, never a sync [F: Requirements § SY] the small component abacus_seed in Components § 3
A-5 Naming and value rules measured on PROD (57 products): 692 of 692 cover codes match ^[A-Z0-9_]+$ in VARCHAR2(15); limits follow the DEDUCTIBLE* / DEDUCTIBLEV* / LIMIT_AG_* / LIMIT_EV_* / LIMIT_PE_* grammar; message keys are product-first (P7008_PF_IV_HOME); SR_MESSAGES.MSG_TYPE LABEL is not the convention (22 rows); PR_PRICING_FACTORS.SALE_STAGE is POL on 1 977 of 1 977 rows; DATATYPE LIST 1 038 · NUMBER 259 · IV_COV 245, STRING 2 rows; VALUE_SOURCE POV on 84 %; PR_BASIC_LD.SEP_ACCOUNT tracks LD_TYPE on 1 465 of 1 465; LD_SIGN separates loading from discount; LOB has ten free-text spellings [F: Requirements § 03] seeds for configuration/ipal and configuration/serdica; S3 and S5 assertions
A-6 Environments differ, and DEV most: UI_REQUIRED exists only on DEV and TEST (measured 02.09.2026: it is also present and NOT NULL on QA and STAGING, and absent only on PROD — Measurements § DB-3); SALE_STAGE='QT' 23 products / 254 rows on DEV, 0 on TEST and PROD; PR_CONSISTENCY_CHECKS absent on DEV, 52 rows on PROD; INSIS and ABC_ACCESS absent on DEV [F: Requirements § 03] the estate prober counts a convention in all three environments before a stage relies on it
A-7 ABACUS version selection is ORDER BY version_id DESC among DEPLOYED rows — the highest id wins, not the latest date; genRuleTable requires stage DONE or CONFIRMED plus an EFFECTIVE_DATE and writes RATING_TABLE_FILES per version; one file set can feed N deployments [F: Requirements § AB, § 04] S2 assertion "the intended version is the highest deployed id"; the deployer's blast-radius list of versions consuming a changed file
A-8 The composition rule is a per-product decision that changes the premium: 1300 × 1.05 × 1.30 × 0.90 − (1300 × 0.10) = 1467 against 1300 × 0.90 × 1.05 × 1.30 × 0.90 = 1437 [F: Requirements § AB] ld.combination_rule and order are mandatory in the specification; a worked example in the product document
A-9 A rate is a fraction: 0.08 % of sum insured is 0.0008 in a rate file; product 2215 carries 0.007 and 0.028 at BP_RATE_DIM='P' [F: Requirements § 04] the tariff analyst's unit line and the S2 unit assertion
A-10 Key spaces collide across products — product code, tariff file name, CFG_ID, MSG_ID, question id, print REP_ID; MSG_ID is a hard foreign key and a key with no parent row never reaches the UI; there are no triggers or identity columns on these tables [F: Requirements § PR] S3 and S5 plan steps "allocate key" with a uniqueness assertion each; the S5 label sweep asserts the parent row
A-11 INSIS product codes: HT_INSR_TYPE holds the bands 11 · 22 · 33 · 34 · 35 · 36 · 38 · 47 · 48 · 59 and CFG_MAPPING_PRODUCT_CODES has exactly one row, so the IPAL code is the INSIS insr_type by default; 15 product-aware SRD_INTEGR packages may need a development change, not a configuration row; 43 product codes are hard-coded in that PL/SQL and zero in SRD_IPROD [F: Requirements § IX, § 01] The pre-check of the per-product INSIS script, and its Hd trigger list — a change to one of the 15 product-aware SRD_INTEGR packages is Development work, not a configuration row (D85)
A-12 The two isolations: the tariff reader is given no schema vocabulary; the estate prober is given no product intent, holds a SELECT-only credential, returns counts and never advice, and keeps permitted distinct from used (a value present in one or two rows out of thousands is reported as such, never as a convention) [F: Design § 02, § 04] the tariff analyst exists in the wiki; the estate prober is new — a sub-agent profile in Components § 3
A-13 Model checks before any SQL (cover set, factor set, value sets, the tariff's own arithmetic) and acceptance in four parts (completeness per surface, deliberate omissions, cross-layer agreement, the manual test), with expected counts derived from the model and the rollback written in the same sitting as the SQL it undoes [F: Requirements § VF, Design § 03] the validator gains the tariff-arithmetic check; the deployer's acceptance script has the four parts
A-14 The source set is inventoried before it is read: one row per file, one authoritative file per part, a later file supersedes only where it says so, reconciliation across files not within each [F: Design § 04] the S1 source inventory; the specification's meta.sources gains authoritative_for[] and a conflicts list
A-15 The open-question shape: number, the decision as a question, what it blocks, options with consequences, the assumption under which work continues, the cost of being wrong [F: Design § 04] unresolved[] entries gain assumed and cost_of_being_wrong
A-16 The ABACUS write contract of the service: a new version in a non-deployed stage only, never a row of a deployed version, never RATING_TABLE_FILES; an allow-listed table set in code; no DDL; preview with row-count estimate and diff; one transaction, one audit record; undo is a drop; deploy is a separate role-gated act that lists every version consuming a changed file [F: Product design § 05] the S2 write executor's rules; H5 for ABACUS carries the consuming-version list
A-17 Intake immutability: inputs are unpacked, hashed and stored immutably; Office, PDF and spreadsheet files are converted once to text and tables; a change to the inputs is a new run, never an edited one [F: Product design § 03] S1 connector readers; the case's papers hold the rendition
A-18 Two loops, kept apart: a correction edits the model and re-projects only the sections that changed; a revised specification is a new run diffed against its predecessor at the model level, answers carrying forward where the question is unchanged [F: Product design § 06] the H1a delta decision of Configuration Module gains "re-project changed sections only" and "answers carry forward"
A-19 Engine knowledge and estate knowledge are separable: the rate-file grammar, premium vocabulary and the version-and-deploy model are generic; product codes, counted defaults and role names are per estate and are measured per tenant on first connection [F: Product design § 04] a per-customer scope for measured conventions in the configuration/* domains, each count with its date
A-20 Delivery that can be stopped: skeleton with file output → the model as data → read connection and the automated verification gate → the write path last → the ABACUS-only shape [F: Product design § 12] the abacus-only first slice can run in files mode before its write path exists

C. Where they contradict the wiki

Each contradiction is a C with the decision that resolves it; nothing on a design page was changed by this reconciliation.

Decided 04.09.2026 — C-2 → D120 (the emitting agent writes the revert) · C-4 → D121 (a dedicated abacus–insis sub-agent of Support) · C-5 → D122 (unpriced stays unpriced, with a pre-emptive note) · C-6 → D123 (environment path per product line) · C-7 → D124 (provenance classes) · C-8 → D125 (ABACUS addressed as a system of its own) · C-9 → D126 (no commercial-residency key). The rows below keep the readings as they stood; the register row is the decision.

# The wiki says The configurator documents say Resolution
C-1 ✅ S3 writes the IPAL catalogue on the working environment through the write executor, under the case's grants, and deploys to targets as script sets (Configuration Module § 2–3) SRD_IPROD has no staging concept — a row in PR_PRICING_FACTORS is live for the next quote — so IPAL output stays files in the first release; a direct write needs a product-scoped transaction, a generated rollback executed as one unit, and access rows written last (Product design § 05) Settled (D72): gated write operations are allowed, under the write-gating protocol. The working-environment write stays, and it is a W1/W2 instance of a person-approved write shape, checked by the write auditor for exactness, boundedness, reversibility and scope before its gate (Gating). The configurator's three conditions are the shape's fields, not a separate rule: the product-scoped transaction is the shape's operation, the derived teardown is a required field, and access rows written last is the shape ordering that keeps a half-configured product invisible. Shared rows stay W3 — a person, every time. Customer-facing targets stay H4 plus H5, which is the documents' "files" mode
C-2 ✅ Each stage "emits its idempotent script set with teardown" (Configuration Module § 3); how the scripts are produced is not stated The model never emits SQL that reaches a database; the projection from the validated model into SQL is deterministic code, reviewable permanently and stable across runs, which is what allows two runs to be diffed (Product design § 04, § 10) Settled (D120): the statement fallback path is assembled by the stage agent from the approved template (D72) — it may be SQL, a revert script, or a configuration-endpoint action (D74) — and the same agent emits the revert for every artefact it emits, in the same step, so a phase is revertable without reading its transcript. D74 already makes each system's own configuration endpoints the primary write path, so most objects are not written as authored statements at all. Diffability of two runs of one product holds at template + parameters, not at a deterministic projection: the render-product reading of D40 is withdrawn for this path. Register § 24
C-3 ✅ Rating may need a minimal IPAL catalogue first — "the IPAL → ABACUS catalogue sync" — and S3 may bootstrap the skeleton before S2 (Configuration Module § 1, Configuration Module § 7.1) ppaSync is absent from the customer branches and several of its defaults are wrong; the only measured head start runs the other way, ABACUS → IPAL, once, for three of the twelve parts (Requirements § 01, § SY) Settled (D75, D74): the tariff phase is first, and it is the first writer. Phase 1 authors the rating; the abacus seed skill then seeds the product skeleton from it, tagged as proposals; the reverse path is not relied on until it is measured on the customer's own branch. The bootstrap case — a catalogue skeleton needed before rating — stays allowed as a loop-back and is recorded in skeleton_source
C-4 ✅ The ABACUS-side validations and the tariff request mapping ABC_CFG_PRICING_FACTORS are owned by S2 for every product (Configuration Module § 7.1) Never configure SRD_INTEGR.ABC_* for an IPAL-only product: it is the INSIS → ABACUS proxy, every entry point typed policy@insis%ROWTYPE; IPAL calls the engine directly from the backend (Requirements § IX-1a) Settled (D121): ABC_CFG_* belongs to a dedicated ABACUS↔INSIS capability, not to S2. The tariff request map (SRD_INTEGR.ABC_CFG_PRICING_FACTORS) and the ABACUS-side validations are the INSIS → ABACUS proxy, and they are worked by a dedicated abacus–insis sub-agent of the Support module, consulted by Configuration S2 when the specification says the product is priced from the INSIS side. For an IPAL-only product S2 never configures the map, and the acceptance script asserts it is empty. Register § 24
C-5 ✅ Missing rates are never faked: a temporary rate and a version left OPEN, so nothing reaches a real quotation (Stage Abacus) A cover the specification names but does not price is configured at rate 0 in both surfaces, with SELECTED='Y' and CHANGEABLE='Y', so an underwriter can price it by hand; an absent cover cannot be sold at all (Requirements § AB-2, AB-3) Settled (D122): an unpriced cover stays unpriced, with a pre-emptive note. S2 neither invents a rate 0 nor blocks the version for a cover the specification names but the tariff does not price; the cover is left without a rate and the tariff analyst adds a pre-emptive note — a specification line and a line in the customer preview — that the cover is unpriced, because customers sometimes intend the opposite. It becomes an unresolved[] item only when the specification itself is ambiguous about the cover. The two-case proposal (rate 0 vs OPEN) is withdrawn; open_or_provisional[] keeps recording what stayed unpriced. Register § 24
C-6 ✅ The Configuration module's working environment is QA; TEST/STAGING is customer-facing and a deploy there is gated like production (Configuration CG-12, Whitelabel Catalogue § 4) Feature-gated products go to QA; general configuration goes to TEST (Requirements § 02, § 03) Settled (D123): the environment path is knowledge per product line, not one global wording. Working and target are decided per path: the existing policy-administration products develop locally, test locally as far as possible, then bulstrad-staging (TEST), then PROD, with the port to master and on to bulstrad-qa afterwards; the health line (product 8000, ДЗО) works on QA, ports to master, and will target the planned bulstrad-prod-2. “QA is the working environment of every configuration case” is not confirmed — it holds only where the product line says so. The paths are environments.paths in the customer plug-in, per product line. Register § 24
C-7 ✅ Every field carries source (file, sheet, range, clause or message id) and unknowns go to unresolved[] (Stage Normalization § WS-6–7) Every line carries one of three provenance classes: SPEC (the customer wrote it), SYS (the database settled it — a constraint, a key, a counted convention), DEC (a decision taken here, to be confirmed) (Requirements § MD) Settled (D124): Add a provenance.kind ∈ {spec, system, decision} next to source in schema 1.1 (additive, product-agnostic); decision entries are the unresolved[] items; system entries cite the prober's count. Decided 04.09.2026 — see register § 24
C-8 ✅ The platform serves IPAL support for any customer; Bulstrad is the first plug-in (Platform PG-23) ABACUS is the product and IPAL is an option: shape 1 is ABACUS alone behind a foreign policy administration system, with a PAS contract export instead of an IPAL catalogue; "the smaller product and the larger market" (Product design § 01) Settled (D125, after D77): the widening is decided — the platform is for complex products that span many services, systems and procedures, whatever administers them, and Bulstrad on Serdica and IPAL is the case study; a second customer replaces bricks and not the building. Settled (D125): ABACUS is addressed as a system of its own, and shape 1 is a product shape to build for. The rating engine alone behind a foreign policy-administration system — with a pas_contract export instead of an IPAL catalogue — gets its own plug-in, an export skill, its own connector and its own where-chip; the Configuration module's deployment-set preset abacus only is that customer shape (no IPAL sources, any OIDC identity provider), and PG-23's wording widens from “IPAL support” to policy-administration support. That Bulstrad owns and operates ABACUS and IPAL as one does not merge them in the platform's model. Register § 24
C-9 ✅ Configuration handles no personal data and may use any adapter (Platform Details PG-7) Tariff documents are commercially sensitive; retention and residency are tenant settings, and a tenant may forbid sending inputs outside its region (Product design § 07) Settled (D126): no commercial-residency key. The platform's customers are bound to one region, so data_boundary.commercial_residency is not added to the customer plug-in (Whitelabel Catalogue § 3); until a multi-region customer appears, tariff documents follow the personal-data route rules that already apply. Re-opened only then. Register § 24

Two more differences are naming only and need no decision: the configurator's scope groups A / B / C map onto the stages (B = S2, A = S3 + S4 + S5) and onto the deployment-set presets — group C has no stage: D85 made the INSIS side one PL/SQL script per product with a named owner; its roles PC_VIEWER / PC_AUTHOR / PC_WRITER / PC_DEPLOYER / PC_ADMIN map onto Viewer / Operator / Operator with a write grant on the working environment / Approver (H5) / Administrator. The platform's role set is larger than that mapping: it also holds the Prompt publisher (the role that makes a prompt version live, D10) and the Customer representative (the customer's business user who gives the acceptance at CG-11) — six roles in all (D134) (Trust and Data § 3).

Q. What the documents leave open, and the wiki already answers

Related: Components — Configuration · Configuration Module · Schema Quirks · Requirements Register · Baseline · Configuration module — goals

PreviousMeasurements — 02.09.2026NextSchema quirks