Support Module — case studies against real tickets

Ten case studies over twelve tickets from jira_tickets/, replayed through the Support root and the Data and information module as the wiki specifies them today: Support Module, Data and Information Module, the five stage pages, Gating, Agents, Agent Runtime § 11, Agents Memory and Skills (Parts I–II), Trust and Data and Failure and Recovery. Each case states what v1 did, then walks the v2 stages in the order D83 fixes — S1 → S3, and S2 only where the take found no ready solution — with the concrete mechanics, and names where the wiki has no rule, a contradictory rule, or an unrealistic one. Gaps are numbered G-1 … G-19 of this page — this page's gap ids, not the G-nn requirements of the Requirements Register — and collected in the table at the end. Sources are the analysis HTMLs and JSON snapshots in each ticket directory; memory articles are cited by path.

F Reading status. Re-read against the shape census of 07.09.2026 (Typical cases § 1): Cases 1, 5 and 8 are typical as written, and the shape behind Case 3 is typical (its two-masters edge is not); Cases 3, 6 and 10 recur in another form; Cases 2, 7 and 9 are architecture tests — real once, chosen to stress the design; Case 4 is a Configuration and Development case. Read these walks for what they test, and the typical-cases page for how often each shape occurs and what it touches.

Case 1 — SD-1717 · stuck IPAL→INSIS transfer after revert (TransferAlreadyStarted)

The case. „Моля за трансфер на 3607261430000046." A policy (3607, Трудова злополука) transferred on 21.05, was reverted to application on 26.05 12:09:08, approved 12:09:23, and the retransfer 29 seconds later failed with TransferAlreadyStarted. v1: operator Georgi flipped C_POLICIES → OPEN/APPROVED/APL and POL_ANNEXES → OPEN/REG by direct UPDATE at 16:55 and re-ran „Подпиши и трансферирай" from the IPAL UI as the abl_underwriter service account; the same INSIS POLICY_ID 100028107497 was reused. Public reply „прехвърлена е" at 16:56:34, Pending at 16:56:39. Ticket opened 16:24 → fixed 16:55: 31 minutes. AISA's first root cause („pas_policy_id non-null after revert") was corrected after reading ConvertApplicationToPolicyService.cs:129-133 — the guard is an idempotency check on PolicySubstatus == model.Substatus, not on the mapping.

Walk through v2. - S1: connector jira normalizes; type = incident, transfers domain. Contract: § 1, Sev 3 (workaround exists → § 1.5.3). Dedup: no sibling. Precedent: symptom signature „TransferAlreadyStarted after revert" hits the state-flip article memory/reference/cargo_recalc_alternative_to_unk0103.md → outcome 2, related precedent as hypothesis. Gate H1 answered by the operator. - S3 — the take's first question: is there a ready solution? The precedent is a related article, not an operation that covers this case: the state-flip shape is known, this policy's mechanism is not. No ready solution → the case leaves S3 by that edge and S2 starts from the precedent set. - S2: profile support.investigator.transfers, grants PROD/IPAL/read + PROD/INSIS/read. Mechanic 0 cross-channel scan (mailbox ± 2 h, MIGR_LOG): finds no TR_POLICY row for 12:09:52 — the failure is above the PL/SQL pipeline. Mechanic 1 decodes 301001321323 / 100028107497. Mechanic 2 invocation-before-configuration: SR_USER_NOTES seven rows are the evidence. Mechanic 5 both systems: INSIS POLICY.policy_state=0. Lateral consult to source.serdica-backend on the guard's semantics — answered from the C# source, labelled evidence. Verifier: re-derives „idempotency guard on substatus equality" from the note timeline plus the code excerpt. Agreement recorded. - Back at S3: kind skill — Data and Information Module § 0.2 #2 „Retransfer / stuck transfer", classification branch zombie state. Fix-signature counter: this is not the first state-flip (the article exists) → the counter says repeats → the packet must additionally propose the development path (guard should clear on revert). Packet: two UPDATEs with expected count 1 each, revert = the pre-state values, replay = the UI retransfer. - S4: H2 + H3 by the operator in one action (Trust and Data § 3: approval is a permission). - S5: gate H5 (PROD write). Grant PROD/IPAL/SRD_CUST/write bound to the two statement hashes, expiring at close. Shape A for the UPDATEs. Then the retransfer itself — a UI_ACTION by the platform actor aisa.ui.PROD, or the operator in their own browser as a gated task where the actor lacks the role (Stage Application § 1: three acting identities, never impersonation) — not a DB statement, and not v1's shared abl_underwriter account. - S6: symptom on the customer's surface = INSIS policy active, MIGR_LOG TransferPolicy.END. Communicator drafts the BG reply; gated send; the platform moves the ticket to Pending (= resolved); the customer's confirmation completes it (D49). - S8: experience entry (mandatory). Ladder: the state-flip shape is at least the 3rd occurrence → the skill exists; this sighting counts towards the 7th. Finding to source/serdica-backend: „guard does not self-clear on revert" as a request record.

Handled well. The precedent-as-hypothesis rule is exactly what corrected AISA's first root cause. The Finding message to the Development domain carries the CR suggestion out of the ticket without an automatic escalation.

Where it breaks or is silent. - G-3 Verifier cost. Status: closed — Stage Investigation § 3 tiers the verifier; the residual is measuring verifier time on half-hour tickets. - G-10 UI-driven application. Status: closed — Stage Application § 1 defines UI_ACTION; the residual is the role-impersonation policy. - G-4a Two SLA clocks. Jira SLA on this ticket is 4 h response / 8 h resolution; the contract says Sev 3 = 3 days / 30 days. Stage Classification § 3 assumed one contract clock „counted from the ledger". The channel clock is the one the customer sees.

Proposals. Tier the verifier by publish surface (Stage Investigation § 3). Add a „UI action" application kind with actor identity and a screenshot/SR_USER_NOTES row as its write-log record (Stage Application § 1). Carry both channel SLA and contract SLA as case fields and warn on the tighter (Stage Classification § 3).

Case 2 — SD-1757 · duplicate company record, 5-row orphan delete (the 5-step write)

The case. „За ЮЛ ГРЕЙНСТОР БЪЛГАРИЯ АД има два записа … коректния номер на ЕИК е 203674807. В ИНСИС е коригирано." v1: AISA found the duplicate C_CUST 201001481761 (ЕИК 2036748073, one extra digit), scanned 18 FK children (0 policies, 0 participants, 0 accounts), confirmed INSIS MAN_ID 6004216388 deleted on 04.06 via HIST_P_PEOPLE, and executed an atomic PL/SQL block: five DELETEs (mapping row, C_ADDRESSES, SR_ADDRESSES, C_COMPANY, C_CUST), SQL%ROWCOUNT = 1 each, else ROLLBACK. Verified by replaying the real pas_ccust_seek query captured from Kibana (totalCount 2 → 1). Public reply 11:23, Pending. Created 10:43 → done 11:23: 40 minutes, ~2 h of analysis. The 5-step protocol article was written from this ticket after the first attempt committed before verifying.

Walk through v2. - S1: type = data correction; § 1, Sev 3 (workaround: pick the green row). Precedent: memory/feedback/verify_ipal_footprint_before_mirroring_insis_merge.md and insis_p_people_auto3p_duplicate.md hit → outcome 2. - S3 — the take's first question: is there a ready solution? A skill would be ideal but none exists — Data and Information Module § 0.2 has no „merge/orphan customer" entry, and #6 is accounts — and memory answers the shape, not this record's footprint. No ready solution → S2. - S2: master-data investigator. Mechanic 3 introspect-first (18 FK children from the catalogue). Mechanic 5 both systems (HIST_P_PEOPLE@insis). Mechanic 6 verify-don't-guess: the „ИНСИС е коригирано" claim is content — re-checked, not believed (Trust and Data § 1 rule 1). Verifier agrees: orphan mirror of a deleted INSIS subject. - Back at S3: with the mechanism verified, the packet is not a skill run but a fix packet: 5 statements, expected 1 row each, revert = re-INSERT from a pre-image captured into the write log, replay = the pas_ccust_seek CTE. Effect class: transactional. - S5: H5 grant PROD/IPAL/{SRD_CUST,SRD_INTEGR}/write bound to the block hash. Shape A: the PL/SQL block already is apply + verify + commit-or-rollback in one connector call — the v1 artefact is literally the shape A implementation. Pre-commit same-session replay of the consuming query is allowed by Failure and Recovery § 1 because it is the UI's SQL, not the UI. - S6: post-commit — the operator's actual picker, which needs the browser connector; otherwise „the row is correct" is the level reported (CR-3). - S8: 3rd-or-later sighting of the „mirror cleanup after INSIS merge" shape (OTRS 00101210, SD-1653, SD-1757) → the ladder says create the skill.

Handled well. Shape A maps one-to-one onto the v1 block. The replay of the Kibana-captured query is precisely the „consuming query" the wiki asks for.

Where it breaks or is silent. - G-1 Handles on structured identifiers. Status: closed — Components § 6 exposes structural facets; residual comparisons stay connector-computed. - G-19 Exemption test. Failure and Recovery § 5 requires simulation unless all five hold, the first being „a single row". This fix is five rows in four tables on one logical object. Taken literally it must be simulated on QA, where the orphan does not exist. The v1 evidence (per-statement expected counts, atomic block) is stronger than a QA rehearsal would be. - Grants across two schemas. Trust and Data § 2 scopes a grant by „environment × system × schema/target × mode". The block touches SRD_CUST and SRD_INTEGR in one transaction; whether that is one grant or two, and whether shape A may span schemas under one grant, is not stated.

Proposals. Handles expose structural facets (length, prefix, checksum validity, edit distance to another handle) as connector-computed predicates, and comparison operations between handles are connector calls (Trust and Data § 4). Replace „a single row" with „a single logical object, every statement carrying an asserted expected count" (Failure and Recovery § 5). State that a grant's target may be a set of schemas within one system when the statement set is one atomic artefact (Trust and Data § 2).

Case 3 — SD-1841 · cargo framework 1101251235 „синхронизиране" with a duplicate application

The case. „Моля за синхронизиране на договор 1101251235 в АЙПАЛ, регистрирано е предложение 301001347685." v1: the framework already worked in IPAL (301001141194, mapped to INSIS 100022507967, 36 certificates issued); the new application was a duplicate with self-sentinel PAS_POLICY_ID = SR_POLICY_ID and the wrong cover set (ICC_UNLOAD vs ICC_STR_RUBB). Precedent SD-1617 (G-3 shape) — correctly not applied as a repoint. Operator applied a 7-layer IPAL←INSIS sync on the existing record (C_POLICIES, POL_ANNEXES, POL_COVERS ×2, POL_OBJECTS, POL_PREM_RATE ×2, POLCLM_PARTICIPANTS PHOLDER, REPORT_POLICIES_PC cache), then asked the customer what to do with the duplicate. 13:38 → 15:08 Pending: 90 minutes. The duplicate's fate remains the customer's decision.

Walk through v2. - S1: type = data correction / sync; § 1, Sev 3 (§ 1.5.3, the framework works). Dedup: none. Precedent: SD-1617 + cargo_1101_family_sync.md + the LIVING sync checklist § 0 → outcome 2. - S3 — the take's first question: is there a ready solution? The sync-compare skill exists, but which of two IPAL masters to sync and in which direction is not something it decides — and that is the whole case. No ready solution → S2, starting from the SD-1617 precedent as a hypothesis. - S2: transfers investigator, cargo sub-domain. Mechanic 4 peer baseline — the existing record's 36 children are the same-state peer that proves the framework is functional. Mechanic 1 decodes the self-sentinel. Verifier agrees: two IPAL masters for one INSIS framework; the drift is metadata (zero-premium master, percentage covers). - Back at S3: kind skill — Data and Information Module § 0.2 #20 „Framework 1101 sync for a child" (four holders with ≥ 2 tickets). Packet: 7 UPDATEs with expected counts, direction INSIS→IPAL, explicit override of the extension procedure's „latest date wins" default. Plus a question to the customer about the duplicate — the customer-question step type (Stage Solution Take § 1), a step type beside the five kinds, added after this case. - S5: H5, shape A. Cache row REPORT_POLICIES_PC is a downstream consumer — the exemption test fails on criterion 4, so simulation is required by Failure and Recovery § 5. - S6: the customer's surface is „a new certificate issues from the framework" — the certificate-issue test is exactly the policy test skill of the configuration catalogue (Configuration Module § 0.2), but on PROD it would consume a number (gPolicyNo → 1101251235149): an irreversible effect. - S8: entry; checklist § 0 extension „two masters for one INSIS framework: sync the mapped one, never the sentinel one".

Handled well. Peer baseline and precedent-as-hypothesis produce the right non-obvious answer (do not repoint). The high bus-factor flag on #20 is confirmed.

Where it breaks or is silent. - G-16 Customer decisions are content. The duplicate's fate needs a business decision from Bulstrad. Trust and Data § 1 says content never authorizes, and gates are answered by internal role holders (§ 3). The customer's „да, откажете го" arrives as a Jira comment — content. The wiki implies the operator converts it into a gate answer but never says so; nor does it say that a case may end a stage on a question to the customer (Agent Runtime § 11 covers questions to the human operator only). - G-11 Verification consumes a number. S6 on PROD would issue a real certificate. Stage Application § 2 wants the customer's own action re-checked; Failure and Recovery § 2 names consumed numbering as irreversible. - G-4b SLA across Pending. Status: closed — Stage Classification § 3 says both clocks pause on Pending and resume on reply.

Proposals. Add „customer question" as a legitimate S3 outcome with a gated send and a parked task; record the customer's reply as content and the operator's gate answer as the authority (Stage Solution Take § 3, Trust and Data § 1). S6 states which surface was exercised and forbids number-consuming actions on PROD without an explicit irreversible-effect approval (Stage Application § 2). Define clock pause/resume on Pending (Stage Classification § 3).

Case 4 — SD-1863 · print of „Добавък 2 в полза на банка" per object — a Problem that became a Master CR

The case. „…как можем да извикаме конкретен обект, който е в полза на банка? … по полица 22002617520000019 … не разбираме на какъв принцип се генерират само „Стоки" в печата." v1: two months (02.07 → 21.08+). Classified § 2 Personalizations P2 (new factor CREDIT_AMOUNT, new print-DSL gate OBJECT_CREDITED(Y|N), PL/SQL transfer change in INS_DM.object_credited_r, BI template by Bulstrad's Деси). SD-1860 merged as duplicate. Ten test rounds on TEST, accepted 21.08. Then the PROD check found a half-promotion done backwards: CFG_PRINT_DOCS already carried the new token and the PL/SQL chain was on PROD, but the 14 config rows were missing, POLQRY.gINSIS_CREDITED_OBJ_IDS was an empty stub (ORA-06503), and the PROD backend did not know the token → enforced=false → 58 unwanted documents on 58 policies since 23.07. Four numbered PROD scripts sit in the ticket dir (00_stopgap, 01_config, 02_polqry_body, 03_verify), not applied. A „blocked by SD-1861" link was later found to be wrong.

Walk through v2. - S1: type = question → reclassified to configuration change request → CR. Stage Classification § 2 („the platform always classifies… the correction rate is the metric") handles the flip. § 2 P2, offer deadline 7 bd. - S3 — the take's first question: is there a ready solution? No skill covers a print-DSL gate on a new factor, and memory carries no precedent for OBJECT_CREDITED. No ready solution → S2. - S2: printing investigator runs invocation-first: CheckReportConditions per PolObjectId, the gate vocabulary (IsYearPolicy, POV, ParticipantRole, ChkCover). Mechanic 5 across TEST and PROD is what found the inverted promotion. The verifier, given only the PROD/TEST object diff, would have refused the „blocked by SD-1861" claim — the link is content from a Jira field. - Back at S3: kind combination: configuration (14 rows, CFG_PRINT_DOCS gate) + development (POLQRY body, backend token) + external owner (BI template). Two Hd handovers: to Configuration root and the Development module (id source) root, as sub-cases inside one case. Handover scope includes the mandatory order data + POLQRY before backend. - S5: the TEST work is the simulation (Failure and Recovery § 5). Promotion packet = simulation evidence + gate confirmations. The four PROD scripts are a held batch with age (Stage Application § 1) — they have been visible-with-age for twelve days in v1 only because a person remembers them. - S6: fix shape „configuration" → the operator path as the customer's role; fix shape „code" → runtime verification of which commit serves (the stub is exactly „a VALID DB object can still be a stub"). - S7: the 58 documents are generated effects — compensable, not reversible. - S8: article in configuration/serdica on print-DSL tokens and the enforced=false failure mode; KI register entry.

Handled well. Combination kind + two Hd sub-cases + held batch describe this case faithfully. „A VALID DB object can still be a stub" is quoted from the wiki and is literally what happened.

Where it breaks or is silent. - G-12 Cross-module ordering. Stage Solution Take § 2 says each handed-over module „runs its own stages and gates; the result returns". Here the Configuration deployment must precede the Development deployment, and the config gate row already on PROD is the live defect. The residual is the bounded iteration grant, not the cross-module owner. - G-4c Clock re-basing on reclassification. Status: closed — Stage Classification § 3 closes the old clock with CORRECTION and opens the new class. - G-13 Third-party owner. The BI template is Bulstrad IT's. Stage Solution Take § 4 covers CRs and INSIS code; there was no kind for „external owner does step N", and Failure and Recovery § 4 turns an unsupported operation into a capability gap — which is the wrong verdict; it is a dependency, not a gap. - Held batch preflight. Stage Application § Challenges asks for sampling rules on large batches; this batch is four scripts with ordering constraints, where sampling is wrong and order is the preflight.

Proposals. Handover scope carries dependencies between sub-cases and the support root sequences their H5 gates (Stage Solution Take § 2). Reclassification closes the old clock with a CORRECTION ledger record and opens the new one (Stage Classification § 3). Add an „external owner" step type with request record, expected evidence on return, and its own age in the held-batch view (Stage Solution Take § 1, Stage Application § 1). Held batches carry an explicit order; preflight is ordinal, sampling applies only to unordered sets (Stage Application § 1).

Case 5 — SD-1729 · IPAL access for as_brokers@abv.bg, „код 185163"

The case. „моля за създаване на достъп на потребител as_brokers@abv.bg с код 185163 в АЙПАЛ." v1: LDAP row found (OSB_LINK.LDAP_USERS, CONTRACT_ID 18513 — the code in the request had a typo), person already held the only allowed IPAL account (USER_ACCOUNTS.SR_CUST_ID unique; account 1226 idle since 2023). Three clarifying questions posted publicly 31.05 — the operator's variant included the person's ЕГН and IPAL id in the public comment. Reporter answered 01.06 09:58; soft-decouple of 1226 + new account 36262 with IC_USERS on 18513–18516, roles UR_AGENT+UR_EXCLUSIVE_AGENT, „Enable login" from the admin UI; confirmation 10:57. 29.05 → 01.06: ~3 days, 1 h of work.

Walk through v2. - S1: type = access/accounts; § 1 Sev 4. Precedent: bulstrad_employee_account.md, ipal_user_layer_separation.md, SD-1613/1616/1710 → outcome 1, known shape. - S3 — the take's first question: is there a ready solution? Yes. The account skill (Data and Information Module § 0.2 #6) covers the operation, so the case never enters S2 — this is precedent outcome 1 working as designed. The skill's own read set is the diagnostic pack it runs first: LDAP → P_PEOPLE → C_CUST → USER_ACCOUNTS → IC_USERS → USER_ROLES; and „185163" is not an office — the nearest is 18513, which the skill states as a hypothesis and never as a conclusion (mechanic 6, carried as one of the skill's assertions). Kind skill, with three open questions (code, scope of offices, fate of the old account): the packet is a question to the customer — the customer-question step type (Stage Solution Take § 1) — and then the skill. - S4/S5: H5 grant PROD/IPAL/SRD_SYS/write; INSERTs into USER_ACCOUNTS, IC_USERS ×4, USER_ROLES ×2, UPDATE on 1226 (SR_CUST_ID→NULL, mangled email), C_CONTACTS reclass. „Enable login" is a UI action (G-10 again). - S6: the customer's surface is a successful login — only the customer can exercise it. Closure via Pending is correct. - S8: 3rd+ sighting → skill exists (#6) → 7th-pass refinement candidate.

Handled well. The routing table sends access straight to the account skills; the „ask before provisioning" step is a natural S3 question.

Where it breaks or is silent. - G-2 Re-identification in customer-visible output. Trust and Data § 4: re-identification „appears in the gate packet as what will be revealed to whom". The v1 operator revealed an ЕГН in a public Jira comment. The communicator profile drafts in handle space; the gate must show the resolved values and their audience (portal-visible vs internal). Stage Application § 1 „customer-visible output" mentions register rules, not personal-data review. - G-1 again. The person is «ph-1»; the request names an email that is also the LDAP username and the future USER_EMAIL. Emails are personal data and identifiers at once; the connector must substitute them yet the INSERT needs the literal. Handles-as-parameters (create_account(«ph-1».email)) work only if the account skill is a connector operation, not agent-assembled SQL. - Uniqueness constraint discovered by reasoning. SR_CUST_ID uniqueness was proven by a GROUP BY … HAVING COUNT(*)>1 query. Mechanic 3 introspect-first covers names, not constraints; the assertion form in a skill would carry it.

Proposals. Every customer-visible draft passes a re-identification gate listing each resolved datum and its audience; public comments default to handles until approved (Trust and Data § 4, Stage Application § 1). Account operations are connector skills taking handles, never agent-written INSERTs (Data and Information Module § 0.2 #6).

Case 6 — SD-1675 · policy transferred with POLICY_NO = 301001314673 (answered from precedent)

The case. „Трансферирала се е полица с номер 301001314673. Моля за корекция." v1: the operator replied at 13:59 from knowledge — „върнете в предложение, сложете номер = ID (301001315109), трансферирайте" — and the reporter did it herself at 14:05–14:06; new number 4704261300000561 from SEQ_POLICY_NO_4704_1300_26. Completed 14:07: 36 minutes, L1, no DB write. AISA's post-facto analysis found the mechanism (UI session-state leak of a neighbour's SR_POLICY_ID into the POLICY_NO field; the transfer sentinel regenerates only when POLICY_NO == own SR_POLICY_ID) and the precedent SD-517 (2025-08, „Коригирана е").

Walk through v2. - S1: type = incident; § 1 Sev 3. Precedent lookup on signature „POLICY_NO equals a 12-digit 3010… id after transfer" → SD-517 → outcome 1, known shape, known fix. - S3: kind memory — the recovery instruction, its source, and the staleness check (Stage Solution Take § 1). The staleness check is real: SD-517's closure claims the defect was fixed in 2025; a recurrence means the memory's „fixed" claim is stale. - S4/S5: no write. Communicator sends the instruction; H-gate on the send only. - S6: fix shape „answer" → the platform moves the ticket to Pending (= resolved); the customer's confirmation completes it (D49). Here the customer confirmed within 8 minutes. - S8: second sighting → experience entry; but the entry must carry „SD-517's fix claim is stale" — a correction to an existing article, not a new one.

Handled well. The memory kind with a staleness check is exactly right, and the 36-minute total is what the economics page promises.

Where it breaks or is silent. - G-1 Handles hide equality. Status: closed — Components § 6 gives equality facets; residual type-tag detail stays with Trust and Data. - G-6 State changed by the customer mid-case. The reporter fixed it herself before the case reached S5. Agent Runtime § 11 and Failure and Recovery § 3 cover resume and poisoned build state, not „the symptom disappeared because someone else acted". S6 would report „fixed" without knowing who fixed it. - G-14 Ladder vs correction. Status: closed — Stage Precipitation § 2 says the ladder governs creation, not correction.

Proposals. Handle assignment is by value, not by field type — equal digit strings get one handle regardless of which column produced them, and the connector may return type-tags on a handle (Trust and Data § 4). Preflight before S3/S5 re-reads the symptom and records „changed outside the case" as a ledger event with actor if known (Stage Application § 1). The ladder governs creation of skills and new articles; corrections to existing wrong claims are allowed at any count (Stage Precipitation § 2).

Case 7 — SD-1721 · 65-month promo shows 60 months in IPAL: Cannot Reproduce → Sev 2 → a single policy

The case. „Издадена е полица 2215260200019391 по промоционалните условия, но валидността не се визуализира правилно — трябва да е 27-10-2031г. В печата … е както трябва." v1: ServiceDesk could not reproduce and closed Canceled / Cannot Reproduce at 17:28 the same day. AISA's next-day analysis concluded the campaign was half-deployed (IPAL side TR_LIB_PROP.campaign_dur on TEST only), reclassified to Sev 2, and projected 1 000–3 000 affected policies with a DB promotion + back-fill plan. § 9 (29.05) retracted it: ALL_OBJECTS.LAST_DDL_TIME had been read on the TEST connection only; on PROD both packages were deployed 26.05, two minutes apart. The real defect: a silent EXCEPTION WHEN OTHERS THEN NULL on one policy → back-fill one row, Sev 3. Spec parent SD-1524 / HDesk #00098747; a 15-message mail thread on the deploy.

Walk through v2. - S1: type = incident; § 1. Dedup: same policy id in the mail thread (deploy troubleshooting) and SD-1524 — Stage Classification § 4 links them. Precedent: the campaign feature article docs/abacus_promo_65_months_2214_2215.md. - S3 — the take's first question: is there a ready solution? The campaign article describes the feature, but no skill covers „validity shows 60 where the tariff says 65" and memory does not answer it. No ready solution → S2. - S2: transfers/pricing investigator. Mechanic 0 cross-channel finds the deploy thread. Mechanic 5 both systems finds IPAL 60 vs INSIS 65 months. Lateral consult to configuration.abacus on OnCovert_2215 — evidence. Verifier: given only the tool envelopes, it sees every LAST_DDL_TIME envelope carries origin TEST/IPAL and none PROD/IPAL; the claim „not on PROD" has no PROD evidence → disagreement → back to investigation with „what evidence separates half-deployed from single-policy exception". This is the retraction the architecture exists to prevent, and the envelope's origin field (Agent Runtime § 2 rule 3) is the mechanism that makes it checkable. - Back at S3: kind combination: data fix (back-fill 1 policy: END_DATE on C_POLICIES/POL_ANNEXES/POL_OBJECTS/POL_COVERS + RENEWAL_DATE) + development (Hd to source/db-plsql: replace the silent exception with a trace row, add the RENEWAL_DATE update the procedure lacks). Config-toggle vs CR rule (config_toggle_vs_cr_classification.md): the code exists and runs; this is a defect fix under § 1, not a CR. - S5: H5 shape A on the back-fill; the Development sub-case runs its own gates. - S6: the customer's surface = the IPAL header showing 27-10-2031. - S8: article: „verify PROD object state on the PROD connection" — v1 wrote exactly that memory.

Handled well. The verifier design with provenance-carrying envelopes is the direct countermeasure to this exact failure. „The platform always classifies … the correction rate is the metric" absorbs the Sev 3 → 2 → 3 walk without drama.

Where it breaks or is silent. - G-9 Environment provenance. Status: closed — Stage Investigation § 1 mechanic 8 requires environment-origin evidence. - G-15 Channel-closed, case-open. The ticket was Canceled by the channel while the case (in v2 terms) has an unverified mechanism. Stage Application § 4 lists what closes a case; nothing says what happens when the channel closes first, or who may reopen a customer's ticket and on what evidence. - G-5 HelpDesk lineage. The requirement lives in HDesk #00098747, mirrored as SD-1524 (in Pending since April with 43 unimported articles per the backlog memory). Dedup by „same policy id / same symptom" does not link an incident to its specification ticket on another channel.

Proposals. Add mechanic 5a „environment provenance": the verifier rejects any environment claim whose supporting envelopes come from another environment (Stage Investigation § 1, § 3). A channel closure that precedes case closure raises a task „channel disagrees with case" for the operator; reopening is a gated send (Stage Application § 4). Intake links a case to its specification lineage (HDesk id, spec ticket) as case material, not by dedup (Stage Classification § 1/§ 4).

Case 8 — SD-1554 · multi-year 4704 policies lose period 3 after „Върни към предложение"

The case. „След връщане и коригиране на предложения по многогодишни полици … не излиза 3-ти период … Не излизат периодите по двете полици в Инсис." v1: known pattern SD-1014. IPAL revert of an active MYR master cascades INSIS periods 2 and 3 to state −30 and renames their POLICY_NO to the POLICY_ID; the retransfer recreated only period 2. Fix: return the master to application (cascade clears children and C_CAR.MYR_POLICY), edit, recalc, retransfer. Then four correction rounds on 15–16.04: tariff numbers 1.80 %/2.10 % („коригирани" → „не са коригирани" → depreciation had been changed instead → fixed), then „отстъпка за липса на щети" removed via the UI, with the customer repeating the procedure for three siblings. Customer 16.04 12:20: „Всичко се записа коректно, но умишлено не исках да правя корекцията, заради изчезващите 3-ти периоди." Completed. ~1 day, 7 public comments.

Walk through v2. - S1: incident; Sev 2 → Sev 3 by § 1.5.3 (SD-1014 procedure is the workaround). Precedent SD-1014 → outcome 2. - S3 — the take's first question: is there a ready solution? The MYR repair skill exists, and SD-1014's procedure is the workaround — but what the IPAL revert does to the INSIS periods is a mechanism this case has to establish before the repair can be trusted. No ready solution → S2. - S2: transfers investigator, MYR sub-domain; multiyear_policy_verification_checklist.md; Data and Information Module § 0.2 #11 (three holders with ≥ 2 tickets). Mechanic 5: IPAL two rows / INSIS six rows, MYR_POLICY register intact. Verifier agrees: IPAL revert treats MYR children as annexes of one policy. - Back at S3: this is the second sighting of an identical fix (SD-1014, SD-1554) → Stage Solution Take § 1 „it repeats": correct the instance and propose the development path (IPAL revert must not cascade MYR periods) as a combination, Hd to Development. The fix itself is a UI sequence with operator decisions between steps (return master → edit factors → recalc → transfer): Failure and Recovery § 1 shape B by structure, but it is not a DB transaction at all. - S5: four rounds. Under Trust and Data § 2 each round is a different artefact → the grant re-opens each time → four H5 gates in one afternoon. - S6: „periods 1..N print" is the customer's surface (checklist rule). The customer's own reluctance („умишлено не исках") is the signal S6 must record. - S8: skill #11 exists; refinement pass.

Handled well. The recurrence counter forces the development proposal that v1 only mentioned in prose. The MYR checklist maps to a skill with assertions („periods 1..N exist and print").

Where it breaks or is silent. - G-17 Iteration grants. Four same-object corrections in one day, each a new bound grant. Trust and Data § 2 „Bound … a material change re-opens the gate" is right for PROD writes and unusable for an interactive correction series. No page offers a bounded iteration grant. - G-10 UI sequences as application. Status: closed — Stage Application § 1 defines UI_ACTION; iteration grants remain residual G-17. - G-7 Fix signature. Status: closed — Stage Solution Take Challenges defines mechanism id + object class.

Proposals. Define an iteration grant: same case, same object set, same day, per-iteration preflight and expected-count assertion, any new table or object re-opens the gate (Trust and Data § 2). Add a UI-sequence application kind whose write log records the operator action, actor identity and the SR_USER_NOTES rows it produced (Stage Application § 1, Failure and Recovery § 1). Fix signature = mechanism id from the experience index + affected object class, with table/column as attributes (Stage Solution Take § Challenges).

Case 9 — SD-1627 / SD-1636 / SD-1651 · the three retraction cycles

The cases. - SD-1627 „Моля за вдигане на ограниченията за издаване на полици 3615 на 12 вноски … при дадена роля UR_12_INSTALLMENTS потребителите нямат възможност." v1 first pass checked CFG_DURATION_PFREQUENCY and CFG_FLD_VALIDATION (0 rows) and concluded „no product-level restriction; middle-tier only" — wrong tables. The user corrected it; the real gate is the LOV row in SRD_IPROD.PR_PRICING_FACTOR_VALUES with ATTR3='UR_12_INSTALLMENTS' (peer 4704 row id 40731). One INSERT (id 46028), 22 policies issued the same day. Five historical 3615+12 policies had been read as evidence of a working channel — a red herring. Three memory files written/corrected. - SD-1636 „моля за прехвърляне на предложение 1101260502RT9545728 … отказано …" v1 read „прехвърляне" as transfer to policy; abl_underwriter retransferred at 15:50 and created a third INSIS row in state 0, then cancelled it. Customer 16:33: „не трябва да е полица, а предложение". Bulstrad-IT revived INSIS 100027814285 to state −2 with the right number (Option A) at 17:09–17:17. Three INSIS rows for one certificate; an orphan remains. - SD-1651 „ПРОКРЕДИТ БАНК … e въведен с анекс … но в Инсис не се прехвърля." v1 pattern-matched SD-1606 („operator looks in the wrong INSIS tab") and drafted a KB reply. The parallel mail thread (Lyubomir → Georgi → Desislava) showed the real symptom: the BI template BST4704_03A rendered an empty БЕНЕФИЦИЕНТ block; Desislava fixed it at 16:05; the second print used the Latin address (ADDRESS_TYPE='WE'). Internal note went v1 → v2 → v3.

Walk through v2 — what prevents each. - SD-1627: mechanic 3 introspect-first plus mechanic 4 peer baseline (the 4704 row is the same-state peer) reach the LOV table; the verifier, given the two 0-row envelopes and the symptom, cannot derive „no restriction exists" — absence of rows in tables A and B is not evidence about table C → disagreement → „what evidence separates no-gate from gate-elsewhere". The five historical policies are content, not authority (Trust and Data § 1). S3: kind configuration — one LOV row; Solution Take § 4 config-toggle-vs-CR keeps it § 1. - SD-1636: the mechanism was found correctly (PAS_POLICY_ID → cancelled INSIS row); the intent was wrong. No mechanic addresses intent. S3 packet „revert path" would have listed the retransfer's irreversible effect (a new INSIS POLICY_ID, a consumed registration) — Failure and Recovery § 2 — which flags the risk but not the misreading. - SD-1651: mechanic 0 cross-channel scan (mailbox ± 2 h) is mandatory with a required output; the thread was in tmp/ at the time. „Ran, found the Lyubomir thread" changes the symptom before any root cause. Dedup (§ 4) attaches the mail to the case.

Handled well. Two of three cycles are stopped by mechanics that are phases, not advice: introspection + verifier for SD-1627, cross-channel scan for SD-1651.

Where it breaks or is silent. - G-8 Intent restatement. SD-1636 is a goal error. Stage Investigation § 1 carries nine mechanics, one of them intent restatement; the residual case evidence remains the third INSIS policy and external revive. - G-13 External actor executed the fix. Option A was applied by Bulstrad-IT on INSIS; the platform's grants (Trust and Data § 2) cannot cover a system it does not write to. The case must model „requested from external owner, evidence of completion observed at 17:17:59" as a step — the same gap as SD-1863's BI template. - G-14 again. Status: closed — Stage Precipitation § 2 separates creation from immediate correction. - G-3 tension. The verifier's value is proven by these three; its cost on the 40-minute SD-1627 is the same as on a two-day case.

Proposals. Add mechanic 7 „intent restatement": the requested end-state written in system terms (policy_state, POLICY_TYPE, document) and confirmed with the customer when the phrase admits two readings — the confirmation is a gated send, and its absence is recorded, never inferred (Stage Investigation § 1, Stage Classification § 2). External-owner steps as in G-13. Split the ladder: creation counts for skills/new articles; corrections to existing claims fire on evidence (Stage Precipitation § 2 vs § 4).

Case 10 — SD-1846 · HelpDesk #00102234 „Кухи полици" — a mirror ticket completed in six minutes

The case. HDesk article: „BG/03/126002148193 - през Инсис · 471026176021747936, - през Сердика · Моля за визуализиране · Кухи полици." Transferred to Jira as SD-1846 (reporter = ServiceDesk, internal tag Mira) at 11:25:57 and Completed at 11:31:19 — the Jira row is a transfer record, not a worked request. AISA's read-only analysis: two unrelated references; the Serdica generated number already materialized as BG/03/126002147841 (IPAL 301001343098, INSIS 100028669172); the INSIS-origin policy 100028669311 has no C_POLICIES header (channel INSIS, correct) but stale cache rows in REPORT_POLICIES_MOTOR (POLICY_NO=100028669311, state 0) and INSIS_POLICY. Four UPDATEs proposed, not executed; scope guard: no INSERT into C_POLICIES. The HDesk backlog memory shows 39 of 51 mirrored issues never/stale-imported for twelve weeks.

Walk through v2. - S1: connector hdesk normalizes the OTRS article; the case's origin id is 00102234; the Jira row is a second channel of the same case. Type = data correction (cache). § 1 Sev 3. Dedup: the two ids inside the request are decoded (mechanic 1) — 4710261760… is a getID.gPolicyNo generated number, BG/03/… an INSIS official number. - S3 — the take's first question: is there a ready solution? No cache-refresh skill exists in the catalogue, and memory carries the „double-stale cache" model as a shape but not this policy's state. No ready solution → S2. - S2: transfers investigator; MIGR_LOG for the generated number; POLICY@insis for the official one; cache tables. Verifier agrees: stale reporting cache, INSIS-only policy, nothing missing in the transfer. - Back at S3: kind skill? The catalogue has no cache-refresh skill; REPORT_POLICIES_PC staleness recurred in SD-1834 and SD-1841 (the „double-stale cache" model). Third sighting of „reporting cache does not self-refresh" → the ladder says create the skill. - S5: the four UPDATEs are a held batch awaiting an owner's confirmation that these rows feed the missing view. - S6: the customer's surface is the „кухи полици" screen — the browser connector again. - S8: KI entry „reporting caches do not self-refresh"; index line in connectors/oracle-ipal.

Handled well. Id decoding before any claim is the whole case. The held-batch concept names the state the four UPDATEs are in.

Where it breaks or is silent. - G-5 Dual arrival. Status: closed by the dedup rules in Stage Classification § 4. - G-15 Channel status ≠ case status. Status: closed by the dedup rules in Stage Classification § 4. - Held-batch owner. Status: closed for G-18 — Stage Application § 1 names proposed and approved states. - Skill catalogue gap. Status: closed by D23 — Candidate 36 enters at the third occurrence in Components § 5.

Proposals. Connector agents stamp an origin key (hdesk:00102234) and dedup keys on origin first, then on ids and signature (Stage Classification § 1, § 4). One channel per case is authoritative for status; mirrors are projections, and their transitions are gated sends from the case, not inputs to it (Stage Application § 4, Agent Runtime § 11). Add a held-batch state „proposed — question outstanding" with the question and its owner (Stage Application § 1). Add skill #36 „reporting-cache refresh" (Data and Information Module § 0.2).

Gap table

Two smaller items outside the numbered set: grants spanning two schemas in one atomic artefact (case 2, Trust and Data § 2), and constraint introspection (uniqueness proven by query rather than catalogue) as part of mechanic 3 (case 5, Stage Investigation § 1).

Coverage

Exercised by at least one case. S1 all four questions incl. „platform always classifies" with correction (cases 4, 7); dedup positive (7) and negative (10); precedent outcomes 1 (5, 6), 2 (1, 2, 3, 8, 9), 3 (none cold). S2 mechanics 0 (1, 7, 9-1651), 1 (1, 3, 10), 2 (1, 4), 3 (2, 9-1627), 4 (3, 9-1627), 5 (all), 6 (2, and inside case 5's account skill as one of its assertions); lateral consult as evidence (1, 7); isolated verifier as the countermeasure (7, 9). S3 kinds: skill (1, 3, 5, 10), memory (6), configuration (9-1627), development via Hd (4, 7), combination (4, 7, 8); recurrence rule „it repeats → propose the path" (1, 8); config-toggle vs CR (7, 9-1627); CR path § 2 (4). S4/H2/H3 by an operator holding the role (all). S5 shape A (1, 2, 3, 7); 5-step write literal (2); held batches approved-not-applied (4) and proposed (10); customer-visible output gated (all). S6 by fix shape: data (2), configuration (4), code — stub detection (4), answer (6). S8 experience entry (all), article (7), skill creation at 3rd sighting (2, 10), KI register (4, 10), checklist extension (3), ladder correction rule (6, 9). Hd handover to Configuration and Development in one case (4) and to Development (7). Trust boundary: content not authority (2, 9-1627), re-identification (5), grants bound to statement (1, 2). Failure and Recovery: irreversible effects named (3, 4, 9-1636), simulation as TEST acceptance (4), exemption test (2). Agent Runtime § 11: papers, plan reconciliation implied by the correction trail (4, 7).

Never exercised. H6 dead end (no case ended without a mechanism); H7 reversal executed by the platform under a standing revert (SD-1636's revive was a reversal performed by Bulstrad IT outside the platform); shape B leased transaction (no case had an agent decision between statements inside one DB transaction — the SD-1554 sequence is UI, not SQL); impact-key collision between two cases; budget thresholds 80/100 %; worker death / poisoned resume; the summarizer auto-creating a domain node; the dreaming/consolidation pass; the eval-set re-run on precipitation; simulation with verified restoration on QA (no case rehearsed a PROD fix on a non-production copy); cold-start precedent outcome 3 (every case had a neighbour); the 20th-occurrence refinement pass; ledger CORRECTION records are untested by this case set; the design is Stage Precipitation § 6. Added after D112, D143 and D147, and exercised by no case here: the route at H2 as a recorded decision — every walk above reaches S3 through a classification, none through a route the operator answered and the ledger kept; the waiting outcome — cases 3 and 5 park on customer questions but neither names a trigger, a clock treatment and an age the way a waiting case must, and no case waits on a deferred wish or on an external owner's return; HW-approve and the draft shape (D112) — no walk carries a first instance of a new write operation whose person-confirmed decisions train a draft into an approved shape; and H5-SIM — no case rehearsed anything on production under the simulation gate.