Data and information module — typical cases
What this page is. The recurring shapes of the module's work as the archive shows them, not as the design assumed them. It complements Case Studies, whose ten walks were chosen to stress the architecture; here the only questions are how often does this happen, what does it touch, and what does the module do with it. Twenty-four cases, ordered by count × pain; each names its tickets, its mechanism, its fix shape, its verification and its walk through the stages of Data and Information Module § 1. Counts are over the 345 analysed tickets — one primary shape per ticket, archive dates 24.03 → 01.09.2026, four older precedents — unless a stream is named. That is a seventh denominator next to the six of Data and Information Module § 0.2: it counts what the desk actually had to do, where the catalogue counts what the customer asked for by keyword, so the two must not be mixed.
0. What the census says F
- Policy-data corrections are 156 of 345 (45 %); account, agent and role provisioning 42 (12 %); pure answers ≈ 20 (6 %). The rest is other modules' work arriving through the desk: code defects 39 (11 %, 17 of them in July around the 2200/2222 launch) and CRs 7 → Development; product configuration 19 → Configuration; print 19 splits three ways (§ DC-17); master data 15; infrastructure aftermath 11.
- A write executed by the desk is the ending of 144 cases (42 %), not two thirds. 79 (23 %) end as proposed SQL left to Bulstrad IT, an operator or a held batch; 22 (6 %) end in a UI action; 99 (29 %) in no write at all. The "220 of 333" of Data and Information Module § 0.2 and Measurements § TM-7 counts analyses that contain a write statement (reproduced here: 213 of 346 = 62 %); it is not the executed share.
- The two shapes the owner asked about are typical. Multi-year 4704 family repair: 18 tickets (5.2 %, the sixth shape by count; 22 with four adjacent tickets), 30.03 → 27.08.2026, one to five every month. Cargo 1101/1102/1103 family: 33 tickets (9.6 %) over four sub-shapes — framework extension 13 (steady, about two a month), 1103 statements 6, 1102/1100 certificate corrections 7, framework sync 5 (none since 26.06.2026), text 2. The status-flip sub-shape — IPAL APL/OPEN against an INSIS state that has to be flipped by hand — is ≈ 8 MYR and ≈ 10 cargo tickets, and its recurring trigger is one operator gesture: „Върни в предложение" / „Отказана оферта" / a re-pressed transfer, named in 24 one-line summaries and in at least four more analyses (SD-1554, SD-1784, SD-1986, SD-2199).
- The keyword catalogue overstates most shapes two- to four-fold against what the analyses did (retransfer 112 asked vs 32 done; installments 30 vs 13; ИП setup 31 vs 9; print 50 vs 19; framework sync 13 vs 5) but keeps the order; framework extension (14 vs 13) and MYR (25 vs 18–22) are close.
- Trends, March → August 2026. Declining: account and agent provisioning (7 a month April–June → 2 in August); cargo framework sync (none since June — the skill and the selector fact exist). Rising: print (7 in August), status and period desync and restore-after-mistaken-cancel (from July), ЕИСОУКР (3 in August). Flat: MYR ≈ 3, cargo extension ≈ 2, installments ≈ 2 a month.
- Two shapes live mostly outside Jira. VIN and registration corrections: 6 Jira tickets against 12 OTRS notification-mail threads and one HDesk ticket; „куха полица": 2 against 7 threads and 3 HDesk tickets. The eval corpus must count
emails/or it misses them. - Canonical precedents older than the archive (SD-1014 12.2025 MYR revert cascade, SD-517 08.2025 foreign
POLICY_NO, SD-407 06.2025 holder swap, SD-1237 framework sync) exist only in memory pages; an experience index seeded from analyses alone would not know them.
| Shape (what the desk did) | n | share | executed IPAL / INSIS / both · proposed · UI · none | typical products |
|---|---|---|---|---|
| CODE-DEFECT → Development | 39 | 11.3 % | 1 / 1 / 0 · 3 · 1 · 33 | 4704, 2200/2222, 4710 |
| CONFIG (15 validation relax/revert · 19 product configuration) | 34 | 9.9 % | 6 / 2 / 1 · 14 · 1 · 10 | 3615, 4710, 2200, 4800 |
| TRANSFER-STUCK | 29 | 8.4 % | 10 / 0 / 1 · 9 · 8 · 1 | 4704, 4710, 22xx, 36xx |
| ACCESS-USER | 26 | 7.5 % | 21 / 0 / 0 · 2 · 0 · 3 | — |
| 19 | 5.5 % | 4 / 5 / 0 · 1 · 0 · 9 | 2200, 1102, 2215, 4704 | |
| MYR (multi-year 4704 family) | 18 | 5.2 % | 5 / 3 / 1 · 5 · 3 · 0 | 4704 |
| PARTY (holder, owner, lessee, bank, agent participant) | 15 | 4.3 % | 2 / 4 / 4 · 4 · 0 · 1 | 4704, 4710, cargo |
| MASTER-DATA (BSO, make/model, LOV, авариен комисар) | 15 | 4.3 % | 8 / 1 / 0 · 5 · 0 · 1 | 4710, cargo |
| INSTALLMENTS | 13 | 3.8 % | 4 / 1 / 3 · 4 · 1 · 0 | 4704, 1126 |
| CARGO-FRAMEWORK-EXT | 13 | 3.8 % | 2 / 1 / 6 · 3 · 0 · 1 | 1101 |
| PRICING-FIX (one policy) · ACCESS-AGENT | 9 · 9 | 5.2 % | 3 / 0 / 2 · 2 · 2 · 0 — 6 / 0 / 0 · 2 · 0 · 1 | 4704, 2200 — |
| QUESTION · CR · CARGO-1102/1100 · ACCESS-ROLE | 8 · 7 · 7 · 7 | 8.4 % | mostly none · none · 1 / 1 / 2 · 3 — 5 / 0 / 0 · 1 | — |
| VEHICLE-DATA · RESTORE-CANCELLED · EISOUKR-GF · COMMISSION · CARGO-1103 | 6 each | 8.7 % | see the cases | 4704, 4710, 1103 |
| PRICING-EXPLAIN · CARGO-FRAMEWORK-SYNC · BETH | 5 each | 4.3 % | none · 3 / 0 / 0 · 2 — | 4710, 1101 |
| STATUS-DESYNC · POLICY-SYNC · CUSTOMER-DATA | 4 each | 3.5 % | 4710, 2200, 2215 | |
| OUTAGE · CAMUNDA · TRANSFER-ROUTINE · PERIOD-DESYNC · KUHA-POLICA · CARGO-TEXT | 3 · 3 · 2 · 2 · 2 · 2 | 4.1 % | 2215, 4710 | |
| other (currency, annex duplication, report, claim) | 6 | 1.7 % | ||
| Total | 345 | 93 / 23 / 28 · 79 · 22 · 99 (+1 unknown) |
1. The ten case studies, re-read against the census F
| Case | Shape here | Verdict | Evidence |
|---|---|---|---|
| § 2 sample of the module page — a print template cell, second identical fix → Hd | PRINT 19 | recurring, not as written | 5 of 19 are CFG_PRINT_DOCS cell fixes (SD-1499, SD-1819, SD-2077, SD-2116, SD-2141) — Configuration writes; 4 are BI-template defects fixed by Bulstrad's template author; ≈ 8 are the data half, „the print is right, the data is wrong" (§ DC-17). The sample shows only the first kind |
| 1 — SD-1717 stuck transfer after revert | TRANSFER-STUCK 29 | typical as a shape; TransferAlreadyStarted itself once |
18 of 29 fixed by a state flip and/or a UI retransfer; a revert precedes the failure in SD-1717, SD-1566, SD-1626, SD-1856 |
| 2 — SD-1757 orphan company delete | CUSTOMER-DATA 4 | architecture test | chosen for the 5-step write; 3 of the 4 tickets left their rows as proposed SQL |
| 3 — SD-1841 framework sync with a duplicate master | CARGO-FRAMEWORK-SYNC 5, none since 26.06 | recurring, not as written | the common forms are the one-field migration-import repoint (SD-1561, SD-1564) and the two-field fresh-proposal repoint (SD-1617, SD-1748); the two-masters edge occurred once |
| 4 — SD-1863 print „Добавък 2" → Master CR | CR 7 · PRINT | not a data case | § 2 Personalizations: code + template + 14 configuration rows; Configuration and Development handover; only the „58 unwanted documents" residue is data |
| 5 — SD-1729 IPAL access for a broker | ACCESS-USER 26 | typical | the „person already holds the only allowed account / stale layer" twist recurs: SD-1613, SD-1616, SD-1641, SD-1690, SD-1696 |
6 — SD-1675 foreign POLICY_NO, answered from precedent |
TRANSFER-STUCK sub-mechanism, 2 occurrences (SD-517, SD-1675) | recurring, not as written | the kind — memory answer, the customer performs the UI step — is typical (§ DC-22); the mechanism is rare |
| 7 — SD-1721 65-month promo | CONFIG · CODE-DEFECT, once | architecture test | environment-provenance retraction on a campaign |
| 8 — SD-1554 MYR loses period 3 after revert | MYR 18 | typical as written | the revert-cascade variant ≥ 7: SD-1014, SD-1554, SD-1642, SD-1783, SD-1784, SD-1986, SD-2073, SD-2199 |
| 9 — SD-1627 / 1636 / 1651 retraction cycles | MASTER-DATA 15 · CARGO-1102 7 · PRINT 19 | architecture test | the three underlying shapes are typical; the case is about the platform's own errors |
| 10 — SD-1846 HelpDesk mirror „кухи полици" | KUHA-POLICA 2 in Jira + 7 mail threads + 3 HDesk | recurring, not as written | the real shape is SD-1773 / thread 1.27 (SD-1882): 4710 GFIRM timeout → IPAL three-layer sync; SD-1846 is a mirror-closure artefact |
Four of the ten are typical as written, three recur in another form, three are architecture tests. The Case Studies page keeps its value as the stress test of the design; this page is the sizing list.
2. The cases
Format: ask · evidence · mechanism · fix shape · verification · walk · variants · coverage today. Fix-shape vocabulary: read-only answer · data correction in IPAL, in INSIS under grant, or in both · external-owner step (Bulstrad IT, the customer's operator) · retransfer (UI action) · Hd to Configuration or Development. Walks name the stages of Data and Information Module § 1 and the gates of Gating § 1.
DC-01 — Stuck or failed IPAL→INSIS transfer. Ask: „моля за трансфер / предложението е в очакване на трансфер / грешка при трансфер". Evidence: 29 + 2 routine + 1 annex duplication = 32 (9 %); SD-1566 (20.04), SD-1704 (21.05), SD-1717 (26.05), SD-1754 (08.06, 45 stale policies), SD-1779 (17.06), SD-2129 (13.08); mail thread 1.15 (a 22-policy backlog, 06.2026). Mechanism: C_POLICIES.POLICY_SUBSTATUS INT_TRNSF_FAIL/PEND with POL_ANNEXES OPEN/REG, TRANSFERRED_ITEMS.RQ_STATUS = REQUESTED, the MIGR_LOG trace; causes split into a validation gate (BEFORETRANS casco IV gate SD-1779, minimum premium SD-1466, retro car year SD-1557), the idempotency guard after a revert (TransferAlreadyStarted, SD-1717), a dblink cut mid-transfer (SD-1566, KI-013) and INSIS-side halts (ORA-00257 SD-1941, tablespace KI-051). Fix shape: state flip on two IPAL tables + retransfer from the UI as the underwriter identity, or relax/override then retransfer; proposed only when a gate must be reverted afterwards. Verification: PAS_POLICY_ID equals the INSIS POLICY_ID in state 0/12, ACTIVE/APPROVED both sides, the customer prints. Walk: S1 incident Sev 3 → S3 skill unless the gate is unknown → S2 transfers investigator → S4 → S5 UI action (+ IPAL flip) on PROD → S6 the policy prints → S8 gate-catalogue entry. Variants: per-product gate (4704 IV, 4710 ЕИСОУКР, 22xx object values, 36xx minimum premium); a bulk backlog after an outage. Coverage: Case 1; /check-transfer; ipal_transfer_paths, casco_iv_underwriting_limit_gate.
DC-02 — Multi-year 4704 family repair. Ask: „период /N не се прехвърля / не излиза на печат / грешка 5.4 / анулирани периоди". Evidence: 18 MYR + 4 adjacent (SD-1602, SD-1736, SD-1933, SD-2111) = 22 (6 %); 30.03 → 27.08.2026, one to five a month; SD-1552 (15.04), SD-1598 (24.04), SD-1638 (05.05), SD-1763 (11.06), SD-1783 (18.06), SD-1867 (02.07), SD-1986 (27.07), SD-2073 (06.08), SD-2199 (27.08). Mechanism: the invariant ipal == insis == myr over C_POLICIES (master POL + N−1 APL children linked by SR_POLICY_ID_SRC), the INSIS POLICY rows per period (POLICY_REF, states −2 / 0 / −30) and C_CAR.MYR_POLICY (N rows); six sub-mechanisms — (a) INSIS batch converted period /N and IPAL was never told → INT_TRNSF_FAIL (KI-029; SD-1552, SD-1556, SD-1815, SD-1867); (b) an IPAL revert of the master cascades the children to −30 with POLICY_NO renamed to the id, and the retransfer recreates only /2 (SD-1554, SD-1783, SD-1784, SD-2073); (c) MYR_POLICY rows missing or gutted after revert cycles → the period prints empty (KI-055; SD-1598, SD-1642, SD-1986, SD-2199); (d) euro-conversion repair miss → TRPOLICY_DUPL (SD-1525, SD-1763); (e) renewal POL_OBJECTS.SR_OBJECT_ID stale after an owner or reg-no annex (KI-027; SD-1638, SD-1818, SD-2066, SD-2111); (f) a print race before the register is filled (SD-1736), num_instalments = 1 on /N (SD-1602). Fix shape: (a) IPAL-only status UPDATE; (b) return the master to application, edit, retransfer — or rename the cancelled INSIS rows; (c) INSIS MYR_POLICY INSERT/UPDATE (both systems, some rows by Bulstrad IT) or revert + retransfer; (e) repoint every period to the neutral snapshot. Verification: phases 0–2 of the checklist, then „periods 1..N print". Walk: S1 incident Sev 2 → 3 (§ 1.5.3) → S3 skill with the variant picked; an unknown variant → S2 → S4 → S5 shape A or a UI sequence on PROD → S6 print of /N → S8 the variant letter to the pattern page; a second sighting of (b) → Hd Development („a revert must not cascade"). Variants: 2215 multi-year property shows an (a)-like installment smear (SD-1933, KI-014). Coverage: Case 8; multiyear_policy, multiyear_policy_verification_checklist, myr_policy_missing_last_row_pattern; no skill yet — catalogue row 11 is a proposal.
DC-03 — User account create, repair, deactivate. Ask: „моля за достъп в АЙПАЛ за OSB_LINK.LDAP_USERS), the IPAL customer master (C_CUST, C_CONTACTS), the IPAL login (USER_ACCOUNTS, IC_USERS, roles); SR_CUST_ID unique → one account per person; employee→ИП moves leave CURRENT_BRANCH stale (SD-1641) or the wrong SR_CUST_ID (SD-1696). Fix shape: IPAL INSERT/UPDATE set + „Enable login" in the UI (IPAL-only in 21 of 26). Verification: login layer + account tree; the person logs in. Walk: S1 access Sev 4 → S3 skill (template) → S4 → S5 shape A + UI action → S6 login → S8 nothing. Variants: reactivation, ЕГН typo, Матрица vs IPAL split. Coverage: Case 5; bulstrad_employee_account, ipal_user_layer_separation.
DC-04 — ИП agent, broker, office provisioning and bulk product roles. Ask: „разширение на ИП P_AGENTS / P_OFFICES (and counters, KI-049); IPAL IC_USERS, IC_BRANCHES, CFG_POLICY_NO_SEQ are not mirrored; bulk roles are UR_* grants keyed on product routes. Fix shape: IPAL INSERT set (+ a sequence request for a new office). Verification: the picker shows the broker; a test issuance number. Walk: S1 access or configuration → S3 skill /add-agent → S4 → S5 shape A → S6 → S8 checklist. Coverage: /add-agent; exclusive_agents, ipal_new_office_provisioning_checklist.
DC-05 — Cargo framework 1101 extension and date drift. Ask: „удължаване на рамков договор до POLICY.INSR_END + GEN_RISK_COVERED; IPAL keeps six date layers (C_POLICIES, POL_ANNEXES, POL_OBJECTS, POL_COVERS, POL_PREM_RATE.VALID_TO, POLCLM_PARTICIPANTS) plus the REPORT_POLICIES_PC cache; the 1102/1103 selector wants endDate > today + 7. Fix shape: dual UPDATE to the most-future date (both systems in 6 of 13); a selector-window case is an explanation plus the extension. Verification: every layer equal; a child certificate issues (number-consuming). Walk: S1 data correction Sev 4 → S3 skill → S4 → S5 shape A on PROD → S6 the child issues → S8 nothing. Variants: non-date drift (agent, average agent, rate) surfaced for confirmation. Coverage: cargo_framework_extension_workflow, ipal_framework_selector_lookahead; no skill.
DC-06 — Cargo framework sync or repoint so a child can issue. Ask: „синхронизиране на договор 1101xxxxxx в АЙПАЛ". Evidence: 5 (1.4 %): SD-1561 (17.04), SD-1564 (20.04), SD-1617 (30.04), SD-1748 (05.06), SD-1841 (26.06); none since. Mechanism: the framework was born in INSIS Forms; the IPAL row is a migration import (PAS_POLICY_ID = SR_POLICY_ID self-sentinel, real number) or a fresh UI proposal (surrogate POLICY_NO, APL/OPEN/REG, wrong cover set); a forced transfer forks a duplicate INSIS application. Fix shape: one- or two-field repoint + APL→POL flip on C_POLICIES and POL_ANNEXES, covers, rate triad, holder, ISSUE_DATE, cache row; the customer decides the duplicate's fate. Verification: checklist § 0 diff = 0; a child 1102/1103 issues. Walk: S1 → S3 skill /sync-framework → S4 → S5 shape A → S6 → S8. Variants: an expired framework needing a fresh proposal repointed to the INSIS master. Coverage: Case 3; /sync-framework; cargo_1101_family_sync, cargo_1103_expired_parent_with_renewal_discriminator.
DC-07 — Cargo 1103 statement and 1102/1100 certificate corrections. Ask: „корекция на месечно сведение", „сертификатът трябва да падне на PAS_POLICY_ID is reset; USD rate override; ORA-01438 on the USD path. Fix shape: both systems (SRD_INTEGR.CARGO_POLICY_UPDATE, or the APL/OPEN flip + „Преизчисли" + flip back, or PAS reset + retransfer); return-to-application first when unpaid. Verification: totals both sides; reprint. Walk: S1 data correction → S3 skill or memory → S4 → S5 shape A on PROD → S6 reprint → S8. Variants: intent ambiguity (proposal or policy, SD-1636) → a question to the customer. Coverage: cargo_policy_update, cargo_1102_premium_change_retransfer, cargo_1102_historical_fx_rate_override.
DC-08 — Party and participant repair. Ask: „смяна на застраховащ", „собственикът на печата е грешен", „посредникът не е пренесен", „банката не излиза". Evidence: 15 (4.3 %); SD-1568 (20.04), SD-1595 (24.04), SD-1653 (08.05), SD-1702 (20.05), SD-1718 (26.05), SD-1787 (18.06), SD-1821 (22.06), SD-1898 (07.07), SD-2111 (07.08); mail 1.32. Mechanism: IPAL POLCLM_PARTICIPANTS against INSIS POLICY.CLIENT_ID, O_OBJECT_OWNERS (two active rows = 200 %), O_OBJECT_CREDITED; annex propagation gaps (KI-001, KI-004); AGENT ATTRC1-4 empty → direct business; an IPAL-only new party (SOURCE_ID NULL). Fix shape: both systems (INSIS 4, both 4) or an annex re-issue; INSIS rows under the support grant. Verification: print and debit note show the party. Walk: S1 → S3 memory or skill → S4 → S5 shape A → S6 reprint → S8. Coverage: pholder_swap_ipal_only_propagation_gap, insis_object_participant_tables, agent_participant_attrc_gap.
DC-09 — Installment plan and due dates. Ask: „1 на 4 вноски", „падежите са грешни", „бутонът е неактивен". Evidence: 13 (3.8 %); SD-1532 (07.04), SD-1602 (27.04), SD-1732 (01.06), SD-1781 (17.06), SD-1914 (09.07), SD-1929 (13.07), SD-1933 (13.07), SD-2186 (26.08), SD-2196 (26.08). Mechanism: IPAL POL_PPLAN is an independent splitter; INSIS PREM_INST + PREM_INST_FRACT hold six date columns; CHANGE_INSTALLMENTS writes INSIS only; KI-014 smear; KI-009 button disabled by a residual annex; an MYR /N born with one installment. Fix shape: procedure call or dual UPDATE (both 3, IPAL 4, INSIS 1); return-to-application when unpaid. Verification: sums equal the premium, dates aligned both sides, paid installments untouched. Walk: S1 → S3 skill → S4 → S5 → S6 payment-plan screen → S8. Coverage: change_installments_procedure, pol_pplan_not_a_mirror.
DC-10 — Discount, loading, deductible on one policy, and „why this premium". Ask: „отстъпката не е приложена", „завишение при смяна на собственост", „самоучастието е грешно". Evidence: 9 fixes + 5 explanations = 14 (4 %); SD-1611 (29.04), SD-1694 (18.05), SD-1786 (18.06), SD-1897 (07.07), SD-2118 (11.08), SD-2137 (17.08); HDesk 00092847, 00098744 and three getRates asks; mail 1.7, 1.14, 1.16. Mechanism: POL_PREM_RATE holds the ABACUS result, not the fed factor; POL_COVER_DEF, INSIS GEN_RISK_COVERED / PREM_INST; half the cases end as an explanation (a getRates replay) or a Configuration finding. Fix shape: UPDATE or annex (IPAL 3, both 2, UI 2) — or an answer. Verification: the premium reconciles; reprint. Walk: S1 → S3 skill → S2 pricing investigator when unexplained → S4 → S5 / S6 → S8; a configuration cause → Hd Configuration. Coverage: premium_ld_applied_vs_fed_factor, abacus_getrates_direct_call, casco_no_claims_discount_years_based.
DC-11 — Vehicle data correction (VIN, reg-no, type). Ask: „корекция на рама / ДКН по полица", „сгрешена рама". Evidence: 6 Jira (1.7 %) + 12 OTRS mail threads + HDesk 00080729 = 19; SD-1700 (20.05), SD-1707 (21.05), SD-1724 (28.05), SD-1737 (02.06), SD-1861 (01.07), SD-2154 (18.08); threads 1.6, 1.8, 1.12, 1.22–1.25 (05–06.2026). Mechanism: OBJ_CAR versions chained by SR_OBJECTS, INSIS O_CAR, the object mapping; a plate-keyed graft of a different vehicle (KI-036); case-sensitive VIN (KI-019); the ENGINE_NO * marker. Fix shape: chain-aware dual UPDATE (both 2, IPAL 2) or an annex; КАТ is the third side. Verification: COMPARE_IPAL_INSIS_CAR = 0; print. Walk: S1 (origin OTRS) → S3 skill → S4 → S5 → S6 → S8. Coverage: vin_update_chain_aware, insis_ipal_car_sync_invariant; no skill.
DC-12 — Restore a policy cancelled by mistake. Ask: „моля за възстановяване на полица", „анулирана по погрешка". Evidence: 6 (1.7 %), rising: SD-1689 (15.05), SD-1756 (08.06), SD-1784 (18.06), SD-1877 (06.07), SD-2181 (25.08), SD-2195 (26.08). Mechanism: „Върни в предложение" + „Отказана оферта" → IPAL CLOSED/CANCELLED, INSIS −30 / −38 with POLICY_NO renamed to the id; the MYR variant cancels the whole chain. Fix shape: application state (one row + retransfer) vs active state (multi-layer); the INSIS revive to −2 is a Bulstrad IT step (SD-1636); proposed in 3 of 6. Verification: ACTIVE both sides; print. Walk: S1 → S3 memory (paths A–D) → S4 → S5 shape A or an external-owner step → S6 → S8. Coverage: cancelled_policy_restoration_paths, prefer_path_a_when_no_regulatory_tie.
DC-13 — IPAL↔INSIS status or period desync after a cancel, a termination or a one-sided correction. Ask: „в АЙПАЛ е анулирана, а в ИНСИС не", „не мога да я анулирам", „периодът в печата е една година". Evidence: STATUS-DESYNC 4 + POLICY-SYNC 4 + PERIOD-DESYNC 2 + CURRENCY 1 = 11 (3 %), plus two inside TRANSFER-STUCK; SD-1991 (28.07), SD-2003 (03.08), SD-2033 / 2035 (04.08), SD-2139 (17.08), SD-2153 (18.08), SD-2176 / 2194 (26.08). Mechanism: a two-phase cancellation cut between INSIS and IPAL (KI-024, KI-025); reverse desync (IPAL cancelled, INSIS live); ConvertApplication never refreshes INSR_BEGIN/END (KI-021); Bulstrad corrects INSIS first and IPAL's nine date layers are aligned partially (SD-2139, KI-041). Fix shape: the taxonomy query, then an IPAL header/annex repair or an INSIS GEN_INSTALL reversal — often an INSIS-side step by Bulstrad IT. Verification: both states agree; the printed period. Walk: S1 → S3 memory → S2 when the desync class is new → S4 → S5 → S6 → S8. Coverage: ipal_insis_status_desync, insis_period_desync_convert_application, policy_sync_compare_checklist.
DC-14 — „Куха полица" (4710 ГФ / GFIRM timeout). Ask: „куха полица BG/03/…, моля за синхронизиране". Evidence: 2 Jira (SD-1773 15.06, SD-1846 29.06) + 7 mail threads (1.17, 1.18, 1.20, 1.27 ↔ SD-1882, 1.28, 1.29, 1.33) + HDesk 00101947, 00101951, 00100274 = 12 across streams. Mechanism: a GFIRM SOAP timeout inside GEN_APPL_PKG.CONVERT; INSIS holds a normal state-0 policy (or the real one is a sibling row) while IPAL sits at INT_TRNSF_FAIL pointing at the orphan; three layers to reconcile — the C_POLICIES header, the period hierarchy (POL_ANNEXES, POL_OBJECTS, POL_COVERS), the SRD_INTEGR caches. Fix shape: IPAL-only three-layer UPDATE (both Jira rows were left proposed). Verification: the IPAL search shows the BG/03 number ACTIVE; ГФ status. Walk: S1 (origin OTRS, deduped on the OTRS number) → S3 memory fast path → S4 → S5 shape A → S6 → S8. Coverage: Case 10 (the mirror only); kuha_polica_gfirm_timeout, kuha_polica_sync_full_surface.
DC-15 — ГФ / ЕИСОУКР status, duplicate MTPL, green card and sticker validity. Ask: „ЕИСОУКР връща грешка", „има ли действаща ГО за това МПС", „периодът на СЗК е извън полицата". Evidence: 6 (1.7 %) + mail 1.5, 1.19; SD-1479 (26.03), SD-1684 (15.05), SD-1738 (02.06), SD-2076 (05.08), SD-2114 (10.08), SD-2152 (18.08). Mechanism: INTRF_EISOUKR_LOG codes (C007-PL-VH18 duplicate, C003-GC01 one-day GC/period desync), the MTPL status service, a blank taken by another channel (KI-047). Fix shape: an answer (5 of 6) or a one-row INSIS period reconcile. Verification: ГФ returns OK; the policy issues. Walk: S1 → S3 memory → S4 (the answer) → S6 the customer confirms → S8. Coverage: eisoukr_response_codes, gc_period_insis_gf_desync.
DC-16 — Commission and self-retention. Ask: „комисионът не е пренесен", „трансферът пада — няма ставка за посредника". Evidence: 6 (1.7 %); SD-1542 (09.04), SD-1628 (05.05), SD-1676 (13.05), SD-1871 (03.07), SD-1961 (22.07), SD-2006 (03.08). Mechanism: INSIS POLICY_COMMISSIONS / GEN_AGENT_COMMISSIONS against IPAL AGENT ATTRC2/3; the only-up predicate in INS_BOF.sPolComm; a missing rate makes POLICYG.SETUP_GEN_AGCOMM fail (rule table CFG_AGENT_GEN_COMMISSION_RULES). Fix shape: INSIS-side UPDATE (INSIS 2, proposed 3) or a configuration row → Configuration. Verification: recomputed amounts. Coverage: ipal_agent_commission_prefill, cfg_agent_gen_commission_rules_gap.
DC-17 — The print is right, the data is wrong. Ask: „документът не излиза / излиза празен / с грешен офис / без курс". Evidence: ≈ 8 of the 19 PRINT tickets; SD-1720 (27.05, missing CNY rate), SD-1736 (02.06), SD-1759 (09.06), SD-1917 (10.07), SD-1969 (23.07), SD-2068 (05.08), SD-2144 (18.08), SD-2159 (18.08). Mechanism: BI Publisher reads INSIS only; a missing GEN_RISK_LIMITS row (KI-030, fifth sighting), the session office on debit notes (KI-043), PARAMS.Get_One_Currency_Rate for future installments, the MYR register race. Fix shape: INSIS INSERT/UPDATE (INSIS 5) or regenerate; template and gate cells → Configuration (5 of 19); BI-template defects → external owner (4 of 19). Verification: the exact document re-produced (/print-policy). Walk: S1 → S3 skill, invocation-first → S2 printing investigator if the engine ran → S4 → S5 → S6 the document → S8. Coverage: the module page's § 2 sample covers the configuration half only; policy_print_recipe, bipublisher_direct_runreport_probe.
DC-18 — Master-data adds: BSO ranges, vehicle make/model, LOV and pricing-factor values, авариен комисар, НКИД. Evidence: 15 (4.3 %); SD-1446 (24.03 НКИД), SD-1591 (23.04 BSO), SD-1593 (23.04), SD-1627 (05.05 PAYMENT_FREQUENCY 12), SD-1740 (03.06 make/model), SD-1814 (22.06), SD-1944 (16.07 BSO), SD-2036 (04.08), SD-2183 (25.08); HDesk 00080821, 00090023, 00081358. Mechanism: CFG_BLANK_NUMBERS, PR_PRICING_FACTOR_VALUES (+ _DEPENDENT), INSIS P_OTHERS for the average agent. Fix shape: INSERT (IPAL 8). Verification: the LOV is visible; the blank is accepted at issuance. Walk: S1 master data → S3 skill (/add-bso, /add-car) → S4 → S5 → S6 → S8. Coverage: skills exist for BSO and car; the LOV add is a Configuration S3 skill.
DC-19 — Validation threshold relax and revert — the desk-executed configuration cell. Ask: „вдигнете лимита за ЗС по 3615 за клиент X", „МПС от 1930 г. не минава". Evidence: 15 of the 34 CONFIG tickets; SD-1570 / 1571 (20.04), SD-1577 (21.04), SD-1584 (22.04), SD-1592 (23.04), SD-1614 (29.04), SD-1669 (12.05), SD-1764 (12.06), SD-1903 (08.07), SD-2199 (27.08, PR_OPERATIONS). Mechanism: CFG_FLD_VALIDATION / CFG_ABC_FLD_VALIDATION / PR_OPERATIONS rows; relax → the operator transfers → revert to baseline; ENABLED is a live switch with no audit. Fix shape: a time-boxed configuration write in IPAL or ABC_ACCESS, reverted (IPAL 6; proposed 14 across CONFIG). Verification: the operator's transfer succeeds, then the baseline is restored. Walk: S1 configuration change → the route: temporary → this module, S3 memory → S4 → S5 (two writes, a held revert) → S6 → S8; permanent → Hd Configuration. Coverage: validation_threshold_temporary_relaxation, field_validation_frameworks, pr_operations_check_pipeline.
DC-20 — Customer master duplicate and person data. Ask: „два записа за ЮЛ, коректният ЕИК е …", „телефонът не минава проверка". Evidence: 4 (1.2 %) + mail 1.32; SD-1757 (09.06), SD-1817 (22.06), SD-1935 (14.07), SD-1999 (30.07). Mechanism: C_CUST / C_COMPANY / C_PERSON duplicates on a typo (KI-005); an INSIS merge leaving an IPAL mirror; MOBILE_CHECK_2215. Fix shape: IPAL delete or merge under the 5-step protocol (proposed 2). Verification: replay pas_ccust_seek. Coverage: Case 2; verify_ipal_footprint_before_mirroring_insis_merge.
DC-21 — Routine transfer and backlog reconciliation. Ask: „моля прехвърлете предложението", „45 стари полици в очакване". Evidence: 2 + SD-1754 + mail 1.15 (22 policies). The desk supplies the underwriter's second signature or classifies a backlog into four classes. Fix shape: UI action, no SQL. Coverage: none; DC-01's no-fault variant.
DC-22 — Answers from memory: how-to, cannot reproduce, explanation, lookup. Evidence: QUESTION 8 + PRICING-EXPLAIN 5 + ЕИСОУКР answers 5 + REPORT 1 ≈ 19 (5.5 %); SD-1599 (24.04), SD-1606 (28.04), SD-1619 (04.05), SD-1745 (04.06), SD-1826 (23.06), SD-1942 (16.07), SD-2200 (27.08). Fix shape: none; verification is a staleness re-check plus the customer's confirmation (D49). Walk: S1 → S3 memory → S4 the drafted answer → gated send → Pending. Coverage: Case 6; /person-policies.
DC-23 — Repair after a Beth-executed change. Evidence: 5 (1.4 %); SD-1719 (27.05), SD-1870 (03.07), SD-1976 (24.07), SD-1982 (27.07), SD-2185 (25.08). Mechanism: BETH_OPERATIONS_VALUES batches skip a step (annex print, commission period) — restore the skipped value and re-fire. Coverage: beth_annex_print_regen, beth_assistant.
DC-24 — Aftermath of an infrastructure incident. Evidence: OUTAGE 3 + CAMUNDA 3; SD-1937 / 1941 (15.07, ORA-00257 archiver → ten half-written policies), SD-1965 / 1970 / 1993 (23–29.07, stuck Camunda instances), SD-2177 (24.08). The module gets the per-policy cleanup after the incident is closed; verification is per policy. Coverage: insis_aud_buffer_busy_outage, ipal_camunda_midflow_halt.
Not on this list because they are not this module's: CODE-DEFECT 39 (Development — Development module — typical cases), CR 7, product configuration 19 and the CFG_PRINT_DOCS and BI-template fixes (Configuration module — typical cases).
Census challenges
What the real cases ask of the module page and its stage pages. Each is a challenge to a written rule, with the rule the cases suggest; the design disposition is recorded below.
- Census finding Writes are a minority ending, and „proposed" has no case state. 42 % of cases end in a write the desk executed, 23 % as SQL left to Bulstrad IT, an operator or a held batch, 6 % in a UI action, 29 % in no write. Stage Solution Take § 1 has an external-owner step and Stage Application and Verification § 1 has held batches; nothing joins them into a case state with an age the desk and the customer can see. Suggested rule: a first-class ending proposed → executed by an external owner / the customer's operator → evidence returns, with age, next to S5.
- Census finding INSIS-side writes are two different things. 51 cases (15 %) write INSIS: per-policy DML Ablera runs itself under the support grant (commission,
GEN_RISK_LIMITS,MYR_POLICY,PREM_INST) and operations only Bulstrad IT performs (revive −30 → −2, INSIS Forms issuance,P_AGENTSand offices, the blank registry, „INSIS-first" corrections that then need IPAL alignment — DC-05, DC-13). Theoracle-insiswrite connector covers the first; the second is the external-owner step. Suggested rule: name both on Data and Information Module § 0.2 and say which shapes take which. - Census finding The customer as executor. In SD-1675, SD-1602, the siblings of SD-1554 and the routine transfers the fix is a UI step the customer's operator performs on instruction. Stage Application and Verification § 1 names three acting identities — platform actor, test identity, the operator's own account — and none is „the customer, instructed". Suggested rule: a gated send plus a verification that waits for their action.
- Census finding The 5-step write is per statement; the recurring failure is partial family repair. MYR (N periods × IPAL + INSIS +
MYR_POLICY), cargo (6–11 date layers plus a cache), куха (three layers), VIN (the wholeOBJ_CARchain), installments (six date columns in two tables). SD-2139 aligned four of nine layers; OTRS 00102807 needed three passes; SD-1642 came back after four revert cycles. Suggested rule: „replay the consuming query" becomes „assert the family invariant" (ipal == insis == myr; all date layers equal; COMPARE = 0), and the packet's expected counts are per layer. - Census finding Investigators profiled by symptom miss the two family domains. The knowledge that decides DC-02 and DC-05 … DC-07 is per product family — multi-year motor, cargo 110x — not per symptom (transfers, pricing, printing). Suggested rule: the transfers investigator carries two named sub-domains with their invariants and checklists, or the eval corpus grades it on the wrong axis.
- Census finding The recurrence that matters is the trigger, not the fix signature.** At least 28 cases start with „Върни в предложение" / „Отказана оферта" / a re-pressed transfer (the MYR cascade, restores,
TransferAlreadyStarted, cargo loops, annex duplication). The ladder of Stage Precipitation § 2 counts fix signatures — mechanism id plus object class; a trigger counter would have raised the Development escalation („a revert must not cascade", „the second signature is idempotent") months before any single fix signature reached three. - Census finding The temporary configuration cell has no boundary rule. Fifteen desk-executed validation relax/revert writes are this module's work by practice — time-boxed, reverted, on PROD — while permanent product configuration is Configuration's. The page says „configuration cells (shared with Configuration S5)". Suggested rule: temporary with a standing revert → here; permanent → Hd.
- Census finding The OTRS notification-mail stream carries whole shapes. VIN corrections 6 Jira against 12 threads; „куха полица" 2 against 7 threads and 3 HDesk; ИП offices 9 against 4 threads. Intake from the „Ablera" queue is configuration by default (D143); the notification mail is support, and it is where DC-11 and DC-14 live. Suggested rule: the eval corpus and the shape census include
emails/; canonical precedents older than the archive (SD-1014, SD-517, SD-407, SD-1237) are seeded from the memory pages, not from analyses.
Contract side — no challenge. The CR boundary (7 CRs; INSIS code is a CR) and the § 1.5.3 downgrade appear in the analyses exactly as Stage Classification § 3 states them.
Architecture disposition — 07.09.2026
P The case journeys and wire/protocol specification answer the census questions without expanding the module charter. The interactive walkthrough traces every case on this page through requests, records, prompts, messages, gates, execution, reversal and next-request learning. These are design decisions and offline acceptance criteria, not proof of deployed behaviour.
| Census question | Design disposition |
|---|---|
| Proposed/external work and the customer as executor | Existing parked tasks carry typed external obligations; the response API records evidence and resumes verification. Instructions-only completion and operational completion differ. |
| INSIS writes versus owner-only operations | The current connector scope covers permitted data corrections; Bulstrad IT/Forms work stays an attributed external dependency. No blanket INSIS scope is added. |
| Partial family repair | Membership and assertion matrices are required before planning and at result; mapped relationships and every required layer must pass. |
| Symptom profiles versus product families | Retain the existing investigators; multi-year/cargo expertise is tagged skill/evidence under the transfers owner and available by consult. |
| Trigger recurrence | Keep fix-shape counting and add an evidenced trigger relation; mirrors/subcases do not inflate either independent proof or clean executions. |
| Temporary configuration boundary | A bounded relax/action/restore chain is Support work; a permanent rule change recruits Configuration. Shared impact is determined from the real row audience. |
| OTRS/mail and older precedents | All authenticated channels use one canonical request identity. Held-out evaluations include these source forms and compatible seeded precedents; no source is accepted as current without recheck. |