AISA v2.0 / Technical documentation / Frequent AISA operations

Frequent AISA operations

F verified factP decided planC open challenge

P This is the complete bounded inventory for the reviewed workspace corpus: recurring request families, reusable operational steps and important evidence-backed variants. It covers all 68 existing case studies, the archived operational-shape catalogue, the current skill set and relevant memory. It is not a claim to enumerate every possible insurance operation or to have implemented one agent/tool per row.

P Each row states what starts the work, the evidence needed, the result that must be proved, the existing profile/procedure to reuse and a bounded automation opportunity. A method can use LLM judgment and optional executable source/binary helpers. Connector calls, workflow state changes, permission checks and external actions are runtime operations, not invented tool packages. All outcomes below are proposed completion criteria; reading this inventory authorises no action.

F Recurrence basis. Measured figures are copied only from Operational Method Evidence, with its historical sample/row named. “Tickets asked / analyses used” are different, overlapping archive samples and must not be summed. A family total is not assigned to each variant. Qualitative rows state that no independent frequency was measured; low-volume but established procedures and required fallbacks remain visible. No new time, price, ROI or current incident count is inferred.

P Unknown or no matching experience. Start at fresh evidence investigation. A domain hint chooses an investigator, not a diagnosis. Missing/stale/contradictory experience means establish the mechanism from current observations; return unknown with the next separating evidence when it cannot be established. A search miss, a failed query or a superficially similar ticket is not a conclusion.

The machine-readable inventory carries the same records. The detailed homepage should show three illustrative operations and link here; it should not display this whole inventory as agent boxes.

Operation inventory

Transfer and synchronization

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Resolve a stuck or failed transfer `op.transfer.stuck` TransferAlreadyStarted after a revert, although no new transfer reached PL/SQL. Treat it as a discriminator to test, not an assumed diagnosis.	Read the policy/annex state, transfer request and MIGR_LOG together; discriminate validation failure, stale request, lost link and infrastructure outage. The backend rejects equal policy substatus and requested substatus; PAS_POLICY_ID being non-null is not the guard. The note timeline has the failed retransfer but no corresponding MIGR_LOG pipeline entry. Prove: Mapped policy ids and states agree across IPAL and INSIS; the intended policy prints. Reconcile a timed-out transfer before retry.	Profile: `support.investigator.transfers` Method: Reuse check-transfer and the transfer-path procedure. Repair only the proven stale state, then perform the authorised UI transfer; a validation exception uses the temporary-change path. Helper: Package the note/MIGR_LOG/state comparison into one read-only diagnostic that identifies the branch and emits the bounded evidence set. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 112 / 160, Operational Method Evidence row 2 (retransfer / return-to-application / stuck transfer); overlapping historical samples, not current incidence or a variant count. DC-01 source case family; DC-01 representative discriminators and proof; transfer already started idempotency guard; skill; Archived recurrence method and row 2
Repair owner, lessee or beneficiary propagation `op.transfer.participants` The print shows the wrong party, or a participant change leaves two active owners. Treat it as a discriminator to test, not an assumed diagnosis.	Compare participant roles, ownership shares, bank linkage, source ids and annex propagation across both systems. POLCLM_PARTICIPANTS and INSIS POLICY.CLIENT_ID/O_OBJECT_OWNERS/O_OBJECT_CREDITED are different consuming relationships. A second active owner can leave 200% ownership even if one name prints correctly. Prove: Policy and debit note show the intended parties; ownership does not exceed the expected total and obsolete active links are absent.	Profile: `support.investigator.transfers` Method: Reuse participant/ownership-annex reconciliation. Correct only the authorised participant relationships, using the appropriate annex or guarded row change. Helper: Package the participant/ownership/bank comparison as a deterministic diff with explicit missing source mappings. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 31 / 25, Operational Method Evidence row 9 (ownership/lessee/beneficiary annex); overlapping historical samples, not current incidence or a variant count. DC-08 source case family; DC-08 representative discriminators and proof; insis object participant tables; pholder swap ipal only propagation gap; Archived recurrence method and row 9
Restore a mistakenly cancelled policy `op.transfer.restore-cancelled` A mistaken cancellation closes a policy or its downstream multi-year periods. Treat it as a discriminator to test, not an assumed diagnosis.	Determine intended application/active state, regulatory ties, payments and whole-family cancellation effects. Return-to-application followed by rejection can leave IPAL CLOSED/CANCELLED and INSIS negative states. The multi-year variant may cancel downstream periods, not just the selected row. Prove: The intended business state is consistent across the family and both systems; the relevant customer action/print succeeds.	Profile: `support.investigator.transfers` Method: Reuse the restoration path selected by payments, claims and regulatory state. Choose the permitted restoration path; where Bulstrad IT must revive INSIS, send a scoped instruction and wait for evidence. Helper: Automate the cancellation-footprint and recovery-precondition comparison before a person selects the authorised path. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 12 / 25, Operational Method Evidence row 22 (mistaken-cancellation restoration); overlapping historical samples, not current incidence or a variant count. DC-12 source case family; DC-12 representative discriminators and proof; cancelled policy restoration paths; Archived recurrence method and row 22
Reconcile one-sided cancellation or period changes `op.transfer.state-period` A cancellation or period correction lands on one side and leaves the other system or printed hierarchy stale. Treat it as a discriminator to test, not an assumed diagnosis.	Classify direction of status/period drift and enumerate all affected header, annex and date layers. Cancellation can fail between the INSIS and IPAL phases in either direction. ConvertApplication does not necessarily refresh INSR_BEGIN/END. Prove: Mapped states and periods agree on both sides and on the printed document, with every declared layer checked.	Profile: `support.investigator.transfers` Method: Reuse both-system state/period comparison. Have the designated owner correct its system, then apply the approved counterpart reconciliation; preserve the original evidence. Helper: Build a state/date taxonomy query that returns the divergent layer and its consuming surface. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 16 / 74, Operational Method Evidence row 15 (cancel/termination propagation; period-only variants not separately counted); overlapping historical samples, not current incidence or a variant count. DC-13 source case family; DC-13 representative discriminators and proof; ipal insis status desync; insis period desync convert application; Archived recurrence method and row 15
Recover a hollow-policy state after registry timeout `op.transfer.hollow-policy` A 'hollow policy' remains failed in IPAL after a registry timeout, while a real policy exists in INSIS. Treat it as a discriminator to test, not an assumed diagnosis.	Deduplicate the OTRS/mail/Jira aliases; identify the real INSIS policy versus its sibling/orphan after GFIRM timeout. GFIRM can time out inside conversion even when INSIS created the policy. IPAL may reference an orphan or sibling instead of the real active policy. Prove: IPAL search shows the intended active policy, all three layers agree and the required registry status is evidenced.	Profile: `support.investigator.transfers` Method: Reuse GFIRM/INSIS-existence discriminators and complete IPAL synchronization. Reconcile the IPAL header, period hierarchy and integration caches to the proven master, or deliver the scoped external packet. Helper: Automate target-policy candidate discovery and the header/hierarchy/cache diff; do not count channel mirrors as independent learning. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DC-14 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DC-14 source case family; DC-14 representative discriminators and proof; kuha polica gfirm timeout; kuha polica sync full surface
Partition and reconcile a transfer backlog `op.transfer.backlog` A backlog contains routine signatures mixed with real transfer exceptions. Treat it as a discriminator to test, not an assumed diagnosis.	Classify each backlog item as routine second signature, active transfer, validation failure or outage residue. Some items only need the second signature; others have an active transfer or validation failure. Already-completed target effects must be reconciled before retry. Prove: Per-item transfer and target-policy proof; already-completed items are not transferred again.	Profile: `support.investigator.transfers` Method: Reuse per-item transfer checks with batch classification, not blanket retry. Ask the authorised operator to perform routine UI transfers; isolate exceptions into their appropriate repair path. Helper: Automate the backlog classifier and per-item reconciliation matrix; count learning by independent request, not by each row. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DC-21 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DC-21 source case family; DC-21 representative discriminators and proof; int trnsf pend steady state not outage
Compare policy state across both administrations `op.transfer.whole-policy-compare` One field looks fixed but other annex/object/cover/participant/payment surfaces may disagree.	Current policy and annex state, participants, objects, covers, plans and mapping Same-lifecycle peer and requested invariant; distinguish independent splitters Prove: A scoped difference report and, when requested and authorised, proof of the full repaired invariant rather than one row.	Profile: `support.investigator.transfers` Method: Reuse analyze-policy and the living comparison checklist. Helper: Existing narrow source seed: sql/ref/srd_integr_compare_ipal_insis_car.sql for vehicle comparison only. A full-family comparator remains a candidate, not implied coverage.	Operational Method Evidence row 7: 42 requests / 31 analyses used for sync comparison; historical overlapping samples. skill; policy sync compare checklist; srd integr compare ipal insis car; Operational Method Evidence
Separate a number collision from a process halt `op.transfer.number-collision` Allocated number conflicts with another policy; retry shows TransferAlreadyStarted but does not prove a second user click.	Current policy number versus own internal id and the owning row Number-allocation log, uniqueness error, sequence/office path and exact timing Prove: Correctly classified collision and approved owner action; current identities refreshed before any safe reattempt.	Profile: `support.investigator.transfers` Method: Use check-transfer and number-collision/sentinel procedures, not a generic state flip. Helper: Candidate: read-only allocation/ownership collision report; sequence advance or issuance is a separately authorised effect. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Recorded recurring operation or discriminator in the cited family; no separate occurrence count measured. manual policy no preconsumes sequence collision; policy no eq sr policy id post transfer
Reconcile a cancellation that timed out `op.transfer.cancel-timeout` IPAL says cancelled or returns a timeout while INSIS/regulator state may still be active.	Cancellation annex and transfer log with actual commit boundary Current INSIS and regulator states; related payments/claims and operation identity Prove: Known landed cancellation effects, remaining owner action and independently verified consistent status; no blind replay.	Profile: `support.investigator.transfers` Method: Reuse cancellation transfer/confirmation-gap discrimination. Helper: Candidate: state/journal comparison with typed unknown/partial output. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Recorded recurring operation or discriminator in the cited family; no separate occurrence count measured. ipal cancel transfer timeout insis live; ipal cancel confirm double transfer gap

Multi-year policies

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Classify and repair a multi-year family `op.myr.family-repair` Period /5 is blank in a five-year policy document even though that period already exists in INSIS. Treat it as a discriminator to test, not an assumed diagnosis.	Enumerate periods 1…N in IPAL, INSIS and MYR_POLICY. Compare states, original ids, register completeness and object pointers; select the evidenced variant. All five INSIS POLICY records and the missing period's object, risk, installment and commission data exist. C_CAR.MYR_POLICY contains /1–/4 but no row_id=5 for the current master; BI Publisher enumerates this register. Prove: Every period has the required mapped policy/register/object relationships and prints as required; preserve cancelled history and unaffected periods.	Profile: `support.investigator.transfers` Method: Reuse MYR family verification and the selected variant, not one universal repair. Apply the smallest variant-specific repair in ordered system-local operations; any revive owned by Bulstrad IT becomes an external obligation. Helper: Build one family-inventory tool returning policy/register membership, null fields, object links and document timing, plus assertions that distinguish those branches. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 25 / 39, Operational Method Evidence row 11 (whole MYR family); overlapping historical samples, not current incidence or a variant count. DC-02 source case family; DC-02 representative discriminators and proof; multiyear policy verification checklist; myr policy missing last row pattern; Archived recurrence method and row 11
Restore a missing or gutted MYR register row `op.myr.missing-register` Real renewal POLICY/children exist but the corresponding MYR row is absent or its pointers/values are null.	Compare complete real period data with MYR row coverage and current identity; missing renewal policies exclude this remedy. Current family length and boundaries derive from this request, not a previous example. Prove: Only the verified missing/gutted registry scope repaired; all required periods and fresh print agree.	Profile: `support.investigator.transfers` Method: Variant of the existing MYR method; it does not justify another agent profile. Helper: Candidate: captured-snapshot member/registry/value/timing checker with unsupported-variant output. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Variant inside the measured MYR family; individual frequency is not measured and the family count is not copied to this row. myr policy missing last row pattern; multiyear policy verification checklist
Regenerate a MYR document after complete data `op.myr.stale-document` All current registry rows and values are correct but the saved PDF predates their population.	Compare current family/register proof with document timestamps and source-data change evidence. Current family length and boundaries derive from this request, not a previous example. Prove: A newly generated correct document; no unnecessary data correction.	Profile: `support.investigator.transfers` Method: Variant of the existing MYR method; it does not justify another agent profile. Helper: Candidate: captured-snapshot member/registry/value/timing checker with unsupported-variant output. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Variant inside the measured MYR family; individual frequency is not measured and the family count is not copied to this row. myr policy missing last row pattern; multiyear policy verification checklist
Recover a MYR family whose renewals were never created `op.myr.uncreated-periods` Empty MYR register accompanies absent real renewal policies or a placeholder/early-return transfer.	Reconstruct current C_POLICIES linkage, transfer branch/notes and actual INSIS period existence. Current family length and boundaries derive from this request, not a previous example. Prove: Approved family recovery creates/links actual members; no invented POLICY_IDs to fill a registry.	Profile: `support.investigator.transfers` Method: Variant of the existing MYR method; it does not justify another agent profile. Helper: Candidate: captured-snapshot member/registry/value/timing checker with unsupported-variant output. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Variant inside the measured MYR family; individual frequency is not measured and the family count is not copied to this row. myr silent failure and placeholder shape; multiyear policy verification checklist
Restore an affected cancelled renewal chain `op.myr.cancelled-chain` A revert/cancel changed downstream periods, sometimes preserving old register pointers.	Read all downstream states, user notes/audit, fresh policy identities and payment/regulatory restrictions. Current family length and boundaries derive from this request, not a previous example. Prove: Only the approved chain restoration with refreshed mappings and full family proof.	Profile: `support.investigator.transfers` Method: Variant of the existing MYR method; it does not justify another agent profile. Helper: Candidate: captured-snapshot member/registry/value/timing checker with unsupported-variant output. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Variant inside the measured MYR family; individual frequency is not measured and the family count is not copied to this row. myr fix return to application; multiyear policy verification checklist
Repair renewal object pointers `op.myr.renewal-object` Renewal points to a stale object snapshot after an owner/registration change.	Trace SR_OBJECTS/POL_OBJECTS lineage across every required period and counterpart object. Current family length and boundaries derive from this request, not a previous example. Prove: All affected periods point to the correct verified snapshot without overwriting unrelated history.	Profile: `support.investigator.transfers` Method: Variant of the existing MYR method; it does not justify another agent profile. Helper: Candidate: captured-snapshot member/registry/value/timing checker with unsupported-variant output. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Variant inside the measured MYR family; individual frequency is not measured and the family count is not copied to this row. myr renewal pol object stale pointer; multiyear policy verification checklist
Correct a MYR period value without copying a historic ratio `op.myr.period-premium` Each period exists but registry premium/amount repeats the master or wrong period instead of its own approved value.	Compare per-period gross/cover/installment meaning, registry values, currency and actual pricing source. Current family length and boundaries derive from this request, not a previous example. Prove: Each period and print has its own approved value; no hardcoded five-period count or historic premium ratio.	Profile: `support.investigator.transfers` Method: Variant of the existing MYR method; it does not justify another agent profile. Helper: Candidate: captured-snapshot member/registry/value/timing checker with unsupported-variant output. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Variant inside the measured MYR family; individual frequency is not measured and the family count is not copied to this row. myr policy missing last row pattern; multiyear policy verification checklist

Accounts and identities

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Create, repair or deactivate an account `op.access.account-lifecycle` An account-creation request names an uncertain office code, but the person already owns the single permitted IPAL account. Treat it as a discriminator to test, not an assumed diagnosis.	Resolve the person handle across LDAP, customer master and login layers; check the one-account constraint, branch and lock state. The request’s office code differed from the LDAP relationship and required customer confirmation. The person already held the one permitted IPAL account, idle since 2023; a second linked account would violate uniqueness. Prove: Correct account/branch/role mapping and a successful customer login; no duplicate person account or credential sharing.	Profile: `support.investigator.access` Method: Reuse the account template and separate master/login/authentication checks. Perform authorised IPAL provisioning; ask the designated customer to log in in their own session. LDAP work outside scope waits on its owner. Helper: Automate the LDAP → person → account → office → role inventory and one-account check; leave the business choices to the person. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 38 / 62, Operational Method Evidence row 6 (account lifecycle); overlapping historical samples, not current incidence or a variant count. DC-03 source case family; DC-03 representative discriminators and proof; bulstrad employee account; ipal user layer separation; Archived recurrence method and row 6
Provision an agent, broker or office `op.access.agent-office` The intermediary is created but still cannot issue for the intended office or product. Treat it as a discriminator to test, not an assumed diagnosis.	Compare approved office/agent setup with INSIS agent/office records, IPAL branch/account roles and numbering prerequisites. INSIS agent/office records and IPAL account/branch records are separate provisioning layers. Product roles and office numbering prerequisites are not created merely by adding the account. Prove: Broker appears under the intended office and product; numbering/issuance proof uses separately authorised effects.	Profile: `support.investigator.access` Method: Reuse add-agent and the office provisioning checklist. Wait for Bulstrad IT's missing INSIS or sequence step; then apply scoped IPAL provisioning and exact role assignments. Helper: Create a provisioning-diff tool that reports missing relationships and sequences without granting roles or consuming numbers. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 35 / 38, Operational Method Evidence row 8 (agent/broker/office setup); overlapping historical samples, not current incidence or a variant count. DC-04 source case family; DC-04 representative discriminators and proof; skill; ipal new office provisioning checklist; Archived recurrence method and row 8
Resolve a duplicate customer master safely `op.access.customer-duplicate` A duplicate company appears in the picker after its INSIS counterpart was already removed. Treat it as a discriminator to test, not an assumed diagnosis.	Read the full customer footprint and consuming seek query; distinguish a real duplicate from a harmless INSIS mirror. In SD-1757, the obsolete registration value had one extra digit; that similarity alone was not authority to delete it. The footprint scan covered 18 FK children and found no policies, participants or accounts on the obsolete IPAL record. Prove: The consuming search returns the right business entity and no dangling references or unintended deletions remain.	Profile: `support.investigator.access` Method: Reuse footprint-first duplicate/identity resolution. Propose the minimal authorised merge/delete only after dependency counts and survivor identity are proved. Helper: Package dependency counts and the exact seek query into a comparison report that refuses an unexplained footprint change. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DC-20 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DC-20 source case family; DC-20 representative discriminators and proof; verify ipal footprint before mirroring insis merge; db change 5step commit last

Cargo

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Extend a cargo framework period `op.cargo.extend-framework` The extended cargo framework still does not appear in the child-policy selector. Treat it as a discriminator to test, not an assumed diagnosis.	Inventory framework dates across INSIS, IPAL's six layers and cache; establish the approved new end date and selector window. The desired new end date must be confirmed; 'synchronise' does not say whether to extend, duplicate or repoint. INSIS, IPAL header/annex/cover/premium layers and the integration cache can hold different periods. Prove: Every required date relationship holds, the framework appears in the selector, and the declared child-issue proof is obtained under its own authority.	Profile: `support.investigator.transfers` Method: Reuse the framework date-layer extension procedure. Obtain the INSIS owner's change when required, then reconcile each IPAL layer in declared order; refresh the cache through a registered effect. Helper: Automate a six-layer-plus-cache comparison that identifies each stale layer and the exact missing predicate. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 14 / 13, Operational Method Evidence row 18 (framework extension); overlapping historical samples, not current incidence or a variant count. DC-05 source case family; DC-05 representative discriminators and proof; cargo framework extension workflow; Archived recurrence method and row 18
Synchronize the correct framework for child issuance `op.cargo.sync-framework` The request names a fresh cargo proposal, but the existing mapped framework already has 36 certificates and the fresh proposal is a duplicate. Treat it as a discriminator to test, not an assumed diagnosis.	Identify migration-import versus fresh-proposal variant, the authoritative INSIS master, covers, rate dimensions and duplicate applications. In SD-1841, the existing mapped framework already supported 36 certificates; it was not a missing transfer. The new proposal had PAS_POLICY_ID equal to its own source id and a different cover set: ICC_UNLOAD versus ICC_STR_RUBB. Prove: Header, annex, covers, participants, rate triad and cache satisfy the framework checklist; authorised child issuance works.	Profile: `support.investigator.transfers` Method: Reuse sync-framework and full family comparison. Repoint the approved IPAL family to the confirmed master; stop for the owner's decision on any duplicate. Do not force another transfer. Helper: Automate the framework identity/dimension inventory and return a candidate comparison for the owner's decision. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 13 / 9, Operational Method Evidence row 20 (framework sync for a child); overlapping historical samples, not current incidence or a variant count. DC-06 source case family; DC-06 representative discriminators and proof; skill; cargo 1101 family sync; Archived recurrence method and row 20
Correct a cargo statement or certificate `op.cargo.correct-statement` A cargo premium/certificate correction loops on 'application rejected' after an earlier transfer. Treat it as a discriminator to test, not an assumed diagnosis.	Clarify proposal versus issued policy; inspect claim/payment locks, premium currency, FX basis and transfer status. Issued policy versus application is a business choice, not an interchangeable state. Payments or a claim can block the normal correction path. Prove: Requested amounts with currency reconcile on both sides; original dates/state are restored as required and the exact document reprints.	Profile: `support.investigator.transfers` Method: Reuse the cargo correction variant selected by state, currency and accounting footprint. Choose the authorised correction/recalculation sequence or external-owner step; record temporary state flips and their restoration. Helper: Automate the state/payment/claim/FX preflight and post-operation identity refresh, leaving the authorised effect to its registered operation. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DC-07 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DC-07 source case family; DC-07 representative discriminators and proof; cargo policy update; cargo 1102 premium change retransfer
Correct cargo text verbatim across its consumers `op.cargo.text-correction` Approved wording is wrong in the policy or document; do not reinterpret customer-supplied text.	Exact approved text and scoped policy/object/annex Current POL_OBJECT_VALUES and INSIS additional-text consumer plus print engine Prove: Exact approved wording in the promised stores and a fresh document, with unrelated text untouched.	Profile: `support.investigator.transfers` Method: Reuse cargo text correction with the verbatim rule. Helper: Candidate: exact Unicode/value comparison and prepared bounded packet; no new LLM text-rewriting step. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Operational Method Evidence row 23: 12 requests / 5 analyses used; historical samples. customer text apply verbatim; cargo policy update; Operational Method Evidence
Correct cargo currency or historical FX inputs `op.cargo.fx-correction` A foreign-currency correction risks recalculating from the wrong date or overwriting USD values.	Approved currency/rate date, lifecycle/accounting state and original foreign amounts Current IPAL/INSIS values; fresh ids if retransfer occurred Prove: Approved totals and schedule reconcile in explicit currencies; required date/temporary state restored and original foreign amount preserved.	Profile: `support.investigator.pricing` Method: Reuse cargo FX/recalculation sequencing, not a generic currency conversion. Helper: Candidate: per-currency invariant and pre/post-state comparator. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Operational Method Evidence row 28: 9 requests / 19 analyses used for currency/FX corrections; no separate count for each execution variant. cargo 1102 historical fx rate override; cargo products foreign currency native; Operational Method Evidence

Pricing and billing

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Correct installment structure or due dates `op.billing.installments` INSIS installments change but IPAL still shows the old schedule or due dates. Treat it as a discriminator to test, not an assumed diagnosis.	Read independent IPAL splitting and INSIS PREM_INST/PREM_INST_FRACT dates, payment state and residual annexes. IPAL POL_PPLAN is an independent splitter, not a projection of INSIS. CHANGE_INSTALLMENTS writes the INSIS side only. Prove: Amounts sum to the premium in its currency; all required dates align, paid items are preserved and the payment-plan screen works.	Profile: `support.investigator.pricing` Method: Reuse installment comparison and the selected change-installments procedure. Apply the approved installment operation and any required counterpart update; protect paid installments and enumerate all date columns. Helper: Automate the independent-schedule comparison, including paid-item exclusions and the complete date-field inventory. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 30 / 75, Operational Method Evidence row 10 (installment plan and due dates); overlapping historical samples, not current incidence or a variant count. DC-09 source case family; DC-09 representative discriminators and proof; billing and installments; pol pplan not a mirror; Archived recurrence method and row 10
Explain or correct a policy premium component `op.pricing.policy-components` A reported 'missing discount' is diagnosed from a result field instead of the factors sent for rating. Treat it as a discriminator to test, not an assumed diagnosis.	Reconstruct the fed factors, rating output, loading/discount and recorded premium; replay the current rating request. POL_PREM_RATE stores a rating result; it is not the original ABACUS input factor. The fed factor, cover definition and recorded loading/discount must be reconstructed separately. Prove: Expected premium and currency reconcile with the actual factors; a correction also requires the affected print/surface.	Profile: `support.investigator.pricing` Method: Reuse fed-factor versus applied-result diagnosis. Deliver a checked explanation when the result is correct; otherwise branch to a scoped data correction or Configuration handover. Helper: Build a request-versus-result comparator that preserves per-cover arithmetic and flags a missing or transformed factor. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 40 / 77, Operational Method Evidence row 5 (policy discount/loading/deductible); overlapping historical samples, not current incidence or a variant count. DC-10 source case family; DC-10 representative discriminators and proof; premium ld applied vs fed factor; currency and rates; Archived recurrence method and row 5
Correct policy commission or self-retention `op.billing.policy-commission` The policy has a missing or wrong commission even though the intermediary exists. Treat it as a discriminator to test, not an assumed diagnosis.	Compare IPAL agent attributes, INSIS commission rows, rate rules and the relevant update predicate. IPAL AGENT ATTRC2/3, POLICY_COMMISSIONS and GEN_AGENT_COMMISSIONS carry different parts of the result. INS_BOF.sPolComm can update only in one direction, leaving an old value. Prove: Recomputed commission/self-retention amounts with currency match the approved rule and affected policy records.	Profile: `support.investigator.pricing` Method: Reuse effective participant/commission-source reconciliation. Apply authorised policy-specific commission correction or wait for the owning party; a permanent rule gap goes to Configuration. Helper: Automate the effective-rule/attribute/commission comparison and report the exact failing propagation edge. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 16 / 45, Operational Method Evidence row 17 (policy commission/self-retention); overlapping historical samples, not current incidence or a variant count. DC-16 source case family; DC-16 representative discriminators and proof; ipal agent commission prefill; commission hold transfer comparator gap; Archived recurrence method and row 17
Replay and explain selected-cover pricing `op.pricing.replay` A rate, loading or premium differs from expectation; determine wrong input versus wrong rule versus wrong persisted output.	Exact calling path, current factor payload, selected covers, template/version/date and expected oracle Current per-cover/loading/tax response and applied rows with currency/dimension Prove: A refutable component comparison and confirmed ownership of the discrepancy; no summing all offered covers or inventing expected rates.	Profile: `support.investigator.pricing` Method: Reuse Configuration rating verification and the getRates recipe. Helper: getRates is a connector call, not a new learned binary. Candidate: captured payload/selected-component comparator. Credential acquisition must not disguise a mutating SQL function as a read.	Operational Method Evidence row 12: 27 requests / 62 analyses used; shared with Configuration S2, not additive to its cases. abacus getrates direct call; abacus rates presentation; Operational Method Evidence
Cancel a blocking bill through its authorised office flow `op.billing.cancel-blocking-bill` Revert-to-application is blocked because issued INSTALL_DOC bills still exist.	Current bills, bill-office ownership and policy state Available operator office rights and exact UI/INSIS error, especially ERR-03-03 Prove: The authorised office operator cancels the blocking bill through IPAL Сметки (Bills) UI; verify current bill state before separately retrying the requested revert.	Profile: `support.investigator.pricing` Method: Reuse bill-blocks-revert procedure; INSIS accounting authority does not mean Bulstrad-IT-only or direct DB deletion. Helper: Candidate: read-only blocker/office-rights report. UI cancellation is an effect, not a diagnostic helper.	The procedure cites multiple recurring tickets, including SD-612, SD-1434 and SD-1975; no new frequency count asserted. bill blocks revert to application; billing and installments
Generate the missing bill print for its actual origin `op.billing.print-bill` Bill is visible but has no local document; distinguish INSIS-origin manual printing from IPAL auto-generation.	Bill identity/origin and current INSTALL_DOC / local SR_DOCS relationships Requested BILL-stage engine/template and existing output state Prove: The correct bill document is generated once through the supported path; no fabricated missing-policy repair.	Profile: `support.investigator.printing` Method: Reuse bill-origin/print procedure and print-policy where applicable. Helper: Existing document extraction helper aisa-blob can retrieve stored evidence; generation remains an effect.	Recorded recurring operation or discriminator in the cited family; no separate occurrence count measured. document generation; cfg print docs template configuration; README
Coordinate first-month due-premium reversal `op.billing.first-month-reversal` Cargo correction requires undoing premium accounting without simply cancelling the policy.	Actual installment/accounting period, reversal rows, office authority and business intent Dependent commissions, reinsurance, GL and bill effects Prove: Authorised accounting-owner action and complete accounting/residual proof; a row reset is not called reversal.	Profile: `support.investigator.pricing` Method: Reuse INSIS first-month reversal procedure under the actual owner/UI authority. Helper: Candidate: read-only accounting footprint and reversal-evidence report; the accounting operation is not a pure tool.	Recorded recurring operation or discriminator in the cited family; no separate occurrence count measured. insis first month due premium reversal; insis premium reversal first month

Master data and BSO

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Correct vehicle data across its version chain `op.master.vehicle-correction` A vehicle correction changes the latest row but the policy still consumes an earlier wrong version. Treat it as a discriminator to test, not an assumed diagnosis.	Resolve the vehicle handle across every OBJ_CAR version, SR_OBJECTS mapping and INSIS O_CAR; exclude plate-keyed grafts. OBJ_CAR versions are connected through SR_OBJECTS and the INSIS object mapping. Plate-based matching can graft a different vehicle; plate equality is not identity. Prove: The chain-aware IPAL/INSIS comparison has zero relevant differences and the requested print/registry outcome is evidenced.	Profile: `support.investigator.master_data` Method: Reuse chain-aware VIN/registration/subtype checks. Apply a chain-scoped correction or the authorised annex path; treat any registry update as separately owned work. Helper: Wrap the chain traversal and field comparison in one reusable read-only vehicle diagnostic. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 29 / 16, Operational Method Evidence row 16 (vehicle corrections; request count includes the HelpDesk mail correction); overlapping historical samples, not current incidence or a variant count. DC-11 source case family; DC-11 representative discriminators and proof; vin update chain aware; insis ipal car sync invariant; Archived recurrence method and row 16
Resolve MTPL duplicate or regulator/document status `op.master.regulator-status` A green-card/registry request is rejected despite a policy that appears valid locally. Treat it as a discriminator to test, not an assumed diagnosis.	Decode the actual registry response and compare MTPL/green-card/sticker periods and current status. C003-GC01 can identify a one-day period mismatch; C007-PL-VH18 denotes a different duplicate-policy problem. Local policy dates do not establish current registry validity. Prove: The answer reflects current registry evidence; operational resolution requires the promised issue/status outcome.	Profile: `support.investigator.transfers` Method: Reuse response-code and cross-system policy/certificate checks. Send a supported explanation or owner instruction; a necessary period correction branches to its exact gated operation. Helper: Automate code decoding and the scoped current-status comparison, preserving observation time. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 17 / 81, Operational Method Evidence row 14 (duplicate-policy / regulator status); overlapping historical samples, not current incidence or a variant count. DC-15 source case family; DC-15 representative discriminators and proof; eisoukr response codes; gc period insis gf desync; Archived recurrence method and row 14
Add only missing free BSO numbers `op.master.bso-range` A blank batch may overlap existing, reserved or used ranges, or belong to another office/domain.	Approved ranges, format/domain/owner and current FREE/USED/allocated set Duplicate/overlap checks and requested consumption test scope Prove: Only the authorised missing set provisioned; used numbers and owners preserved; exact count reconciles.	Profile: `support.investigator.master_data` Method: Reuse add-bso; covers CF-22 and the BSO part of DC-18. Helper: Candidate: pure range/overlap/format checker from snapshots. Current evidence is add-bso procedure and SQL guidance, not a published v2 package.	Operational Method Evidence row 31: 5 requests / 32 analyses used; CF-22 and DC-18 overlap this shape and are not added. skill; bso format; Typical Cases; Typical Cases; Operational Method Evidence
Add a missing vehicle make or model `op.master.vehicle-catalogue` A dropdown miss may be a true three-nomenclature gap or a mismatched external code.	Make/model meaning, current IPAL/INSIS/EISOUKR keys and existing duplicates Correct parent make and exact requested product path Prove: The correct nonduplicate value is available and maps through the promised transfer path.	Profile: `support.investigator.master_data` Method: Reuse add-car; this is the vehicle-catalogue part of DC-18, not a new generic master-data agent. Helper: Candidate: exact/normalised key comparison and duplicate report. Current evidence is the existing procedure; no general catalogue-merger binary.	Operational Method Evidence row 34: 2 requests / 2 analyses used. Low measured volume; existing useful procedure, not evidence for another permanent profile. skill; eisoukr brand nomenclature; Typical Cases; Operational Method Evidence
Replace, cancel or invalidate an issued GC/sticker `op.master.bso-after-issue` A blank is already attached; initial-issuance and post-issue correction use different paths and current policy/certificate timing.	Current policy/certificate/blank state, issue/begin dates, owner and reason code Actual configured service contract and regulatory eligibility; current response codes Prove: Only the permitted correction/cancel/invalidation sequence; old/new blank states and certificate validity independently reconciled.	Profile: `support.investigator.transfers` Method: Reuse the recorded post-issue decision tree; verify present contract before using historical timing rules. Helper: Existing C# SOAP adapter is an integration seed; optional decision-tree/precondition checker. SOAP changes remain authorised external effects.	Recorded post-issue GC/sticker operation family and correction cases; historical specification must be revalidated, no new frequency count. bso post issue maintenance sequences; mtpl doc attach flow

Documents and printing

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Separate wrong source data from wrong print configuration `op.printing.source-data` The requested document is wrong even though the template itself can render correctly. Treat it as a discriminator to test, not an assumed diagnosis.	Prove the print engine was invoked; inspect exact parameters, INSIS data, currency rate, register readiness and template version. Invocation and exact parameters must be proved before blaming template configuration. BI Publisher reads INSIS data; a missing limit/rate/register value can produce a plausible but incomplete document. Prove: Reproduce the exact requested document, with the expected limit/office/rate and no unintended extra documents.	Profile: `support.investigator.printing` Method: Reuse invocation, engine, data-source and artifact-age diagnosis. Repair the proven data gap; configuration registration goes to Configuration and an external BI template stays with its owner. Helper: Build an invocation/data-readiness/document-age probe that chooses repair versus reprint without repeated manual queries. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DC-17 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DC-17 source case family; DC-17 representative discriminators and proof; document generation; cfg print docs template configuration
Explain or correct the office on a debit note `op.printing.office-source` Printed office differs from policy office; first determine whether the template intentionally receives session office.	Actual print parameters/engine and operator CURRENT_BRANCH resolution Policy office, account-to-IC_USERS resolution and required business outcome Prove: Correctly attributed office source and only the approved session/record correction; no claim that another IC_USERS row is inherently wrong.	Profile: `support.investigator.printing` Method: Reuse the debit-note parameter and OfficeGetter procedures. Helper: Candidate: parameter/source comparison using current read snapshots. Candidate helper only; cited procedure/query/source is evidence, not a published v2 executable package.	Operational Method Evidence row 24: 12 requests / 11 analyses used for office/issuer-code requests; scope includes policy and debit-note variants. document generation; office getter transfer office chain; Operational Method Evidence
Generate or retrieve the required policy document `op.printing.generate-document` The requested PDF may be absent, stale, a wrong copy variant or produced by a different engine.	Policy state/current data, operation type, chosen engine/template/parameters and document chain Expected document content/copy semantics and existing artifact identity Prove: Correct requested document with new/retained artifact identity and observed content; a batch HTTP 200 does not hide a failed document.	Profile: `support.investigator.printing` Method: Reuse print-policy, the engine-first recipe and per-document response checks. Helper: Actual source/binary seed: tools/aisa-blob retrieves stored document bytes. print-policy documents the current generation procedure; the remote render remains an effect.	Operational Method Evidence row 3: 50 requests / 87 analyses used for printing/template fixes; not a separate count for every variant. skill; policy print recipe; sr docs chain; README; Operational Method Evidence

Configuration

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Apply a temporary rule exception and restore it `op.configuration.temporary-exception` An operator needs one blocked policy through a validation rule, then the normal rule restored. Treat it as a discriminator to test, not an assumed diagnosis.	Identify the actual blocking IPAL/ABACUS rule and its full audience, including existing bypasses. The blocking rule can be on IPAL, ABACUS or both. A row changed 'for one policy' can affect every policy that consumes it. Prove: The intended action succeeds and the original baseline is restored; verify the twin rule and any shared impact.	Profile: `support.resolution` Method: Reuse the Support/Data relax-action-restore procedure. Persist and review the relax/action/restore chain before applying; await the operator's authorised transfer and restore under H7. Helper: Automate rule/twin/consumer inventory and due-obligation checks; a timer can queue review but cannot authorise the write. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 18 / 41, Operational Method Evidence row 13 (temporary validation relaxation/restoration); overlapping historical samples, not current incidence or a variant count. DC-19 source case family; DC-19 representative discriminators and proof; validation threshold temporary relaxation; Archived recurrence method and row 13; CF-01 is this same temporary operation, not a new permanent configuration workflow
Configure or explain a permanent control `op.configuration.permanent-control` A control row is installed but the requested condition is not actually enforced. Treat it as a discriminator to test, not an assumed diagnosis.	Export the affected rule and test the requested condition against existing code capability, IPAL, ABACUS and INSIS behaviour. A control row that is installed but still OFF cannot enforce the requested rule. Conditional or computed behaviour may need code rather than another configuration value. Prove: Positive and negative examples prove when the rule fires; the requested target and all declared twins pass.	Profile: `configuration.ipal.builder` Method: Reuse CFG_FLD_VALIDATION / PR_OPERATIONS / declared twins. Change the relevant existing control; computed logic recruits Development and INSIS-owned work becomes an external dependency. Helper: Automate a rule-capability/twin audit that detects OFF, unconsumed or missing counterpart rules. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-02 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-02 source case family; CF-02 representative discriminators and proof; Configuration Work Procedures
Change bypass rules or product visibility `op.configuration.bypass-audience` An exception or product route grants access to more identities than the request authorised. Treat it as a discriminator to test, not an assumed diagnosis.	Resolve approved identity/group handles and compare effective bypass/visibility rights across both validation systems and product routes. Per-user, per-agent and group overrules are different rights surfaces. IPAL and ABACUS overrule groups may not resolve to the same effective audience. Prove: The intended identity can do the permitted action; an unlisted identity cannot, and unrelated roles remain unchanged.	Profile: `configuration.ipal.builder` Method: Reuse rule/group scope plus S5 visibility; account assignment remains with identity owner. Apply the explicit role/bypass delta under shared-impact and target gates; external identity administration stays with its owner. Helper: Automate effective-audience expansion and positive/negative role checks before a shared rights change. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-03 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-03 source case family; CF-03 representative discriminators and proof; Configuration Work Procedures
Refresh an existing tariff version `op.configuration.tariff-refresh` A new tariff version exists, but pricing still selects an older deployed version. Treat it as a discriminator to test, not an assumed diagnosis.	Read the current tariff versions, effective dates, requested rates/limits and any consuming INSIS catalogue obligations. ABACUS selects DEPLOYED versions, not merely newly created rows. Template and effective date determine which version is priced. Prove: Worked examples at rate/effective-date boundaries pass for every changed template; downstream limits match where in scope.	Profile: `configuration.abacus.builder` Method: Reuse abacus configure and version-asserting rating verification. Create the selected version delta, compile under its declared effects and release only the requested target set. Helper: Automate the template/version selection matrix and compare rating results against the approved worked examples. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-04 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-04 source case family; CF-04 representative discriminators and proof; Configuration Work Procedures
Configure a broker or channel template `op.configuration.partner-template` The partner templates compile, but the caller can still silently receive the default tariff. Treat it as a discriminator to test, not an assumed diagnosis.	List the exact broker/channel template keys, selectors, role visibility, effective dates and current rating/offer relationships. Offer-to-template resolution falls through TemplateOfferCode, OfferCode and LB_OFFER_PRICING_RULE to configured/default fallback. KOLHIDA_EUR and MAXO_EUR are named template examples in the configuration census; this replay combines the documented template and selector mechanics. Prove: Every selected template is exercised by its intended caller; default and unrelated callers keep their expected prices and visibility.	Profile: `configuration.abacus.builder` Method: Reuse separate template leaves, caller selector, effective version and role scope. Fan out S2 work by template using single-template leaf specifications; join offer/role dependencies and compile/release each required item. Helper: Build a selector-probe tool that records resolved template/version for intended, unknown/default and excluded callers; reuse it after every promotion. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-05 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-05 source case family; CF-05 representative discriminators and proof; Configuration Work Procedures
Change a discount, loading or deductible rule `op.configuration.loading-rule` Only part of a discount/loading/deductible rule is installed across the three systems. Treat it as a discriminator to test, not an assumed diagnosis.	Reconcile the requested discount/loading/deductible across IPAL definitions, ABACUS rules and INSIS types/effective dates. An INSIS HT_DISCOUNT_TYPE entry alone is not the operative discount rule. IPAL definitions and ABACUS loading logic may use different codes or dates. Prove: The same authorised scenario produces the intended amount, limit and deductible on every requested surface.	Profile: `configuration.abacus.builder` Method: Reuse rating-rule and definition reconciliation across required systems. Apply the stage delta and tracked INSIS-owner work; coordinate any code dependency before activating the rule. Helper: Automate code/date/rule coverage checks and replay the approved pricing boundary examples. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-06 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-06 source case family; CF-06 representative discriminators and proof; Configuration Work Procedures
Add a factor value or dependent choice `op.configuration.factor-value` A new factor value can be selected but maps to the wrong code or dependent choice. Treat it as a discriminator to test, not an assumed diagnosis.	Export factor values/dependencies, global versus product scope, labels and INSIS/ABACUS codes. PR_PRICING_FACTOR_VALUES and _DEPENDENT have different business-key scopes. GLOBAL values and shared labels may affect more than the requested product. Prove: The value appears under the intended dependent selection and is correctly priced/transferred.	Profile: `configuration.ipal.builder` Method: Reuse factor/value/dependency mapping and current downstream codes. Apply only the approved business-key additions and labels, with shared scope gates; obtain any external twin from its owner. Helper: Automate factor/label/external-code comparison and generate the missing-key plan from the diff. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 11 / 42, Operational Method Evidence row 26 (pricing-factor / LOV addition); overlapping historical samples, not current incidence or a variant count. CF-07 source case family; CF-07 representative discriminators and proof; Configuration Work Procedures; Archived recurrence method and row 26
Change the registered document set `op.configuration.print-registration` A print registration change produces the wrong document set or extra copies. Treat it as a discriminator to test, not an assumed diagnosis.	Inspect the document registration, code selector, exact template parameters and external BI template version. CFG_PRINT_DOCS, its evaluator and the BI template are separate dependencies. NULL/zero or an unknown selector token can be treated as enabled on a fail-open path. Prove: The intended document set and copy counts appear; invalid/negative selectors produce no extra documents.	Profile: `configuration.serdica.builder` Method: Reuse registration, evaluator and external template compatibility. Change the declared registration/document set; coordinate Development or BI-owner changes where the template contract differs. Helper: Automate a document-selection matrix that records emitted document ids/counts and rejected selectors. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-08 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-08 source case family; CF-08 representative discriminators and proof; Configuration Work Procedures
Configure product/office/year numbering `op.configuration.numbering` The office/year has numbering rows but cannot allocate a usable policy number. Treat it as a discriminator to test, not an assumed diagnosis.	Read office/product/year numbering rows, current sequence state, grant and synonym existence; identify the authorised sequence owner. CFG_POLICY_NO_SEQ does not establish that the INSIS sequence, synonym and grant exist. The executing principal must see the correct sequence through the expected name. Prove: The correct principal can allocate a unique number for the requested office/product/year under an approved effect test.	Profile: `configuration.serdica.builder` Method: Reuse numbering rows, actual sequence, grant, synonym and executing principal. Coordinate row changes with the separately authorised DDL or external-owner sequence step; never reset an existing counter casually. Helper: Automate the non-consuming numbering preflight and collision inventory; reserve allocation tests for explicit authority. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 6 / 14, Operational Method Evidence row 29 (numbering configuration); overlapping historical samples, not current incidence or a variant count. CF-09 source case family; CF-09 representative discriminators and proof; Configuration Work Procedures; Archived recurrence method and row 29
Change a cover limit, deductible or sublimit `op.configuration.cover-limit` A limit or deductible update copies an incomplete definition set over valid target values. Treat it as a discriminator to test, not an assumed diagnosis.	Compare current cover/deductible/sublimit definitions on every affected product and the requested INSIS counterpart. TEST and PROD may contain different legitimate cover/deductible definitions. A sublimit belongs to a particular cover and effective scope. Prove: Boundary quotes and requested target views enforce the intended limits while unaffected cover definitions remain.	Profile: `configuration.ipal.builder` Method: Reuse per-cover definitions, current target-only values and effective scope. Apply the approved existing-product delta with explicit per-cover scope and external dependencies. Helper: Automate the cover-definition diff and boundary-case generation without deciding which environment is authoritative. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-10 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-10 source case family; CF-10 representative discriminators and proof; Configuration Work Procedures
Correct a label, message or translation `op.configuration.wording` The message row is corrected but the operator still sees the old or wrong-language text. Treat it as a discriminator to test, not an assumed diagnosis.	Resolve the message key, language, current texts, consumers and target cache behaviour. The message key and language identify the changed value. Shared consumers may use the same key in several screens/products. Prove: The affected screen/document shows the intended text after refresh; unrelated consumers remain valid.	Profile: `configuration.serdica.builder` Method: Reuse exact approved text, key/language and consuming cache. Apply the exact shared-label delta and authorised cache refresh, preserving unrelated language and product keys. Helper: Automate key-to-consumer tracing and post-refresh visible-text comparison. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 12 / 27, Operational Method Evidence row 25 (labels/translations/messages); overlapping historical samples, not current incidence or a variant count. CF-11 source case family; CF-11 representative discriminators and proof; Configuration Work Procedures; Archived recurrence method and row 25
Add a clause or cover to an existing product `op.configuration.new-cover` A new clause prices correctly but cannot be selected, transferred or printed completely. Treat it as a discriminator to test, not an assumed diagnosis.	Map the new clause through catalogue, tariff, offer, limits, print and INSIS seam; establish which dependencies already exist. Catalogue, rating, offers, limits, print and INSIS mappings form a dependency chain. A new cover can require code or an externally owned INSIS definition. Prove: The clause can be selected, priced, transferred and printed on the declared target with the correct limits and LD.	Profile: `configuration.ipal.builder` Method: Reuse selected rating/catalogue/package/wiring and external seam dependencies. Run only affected stages and tracked external/Development work; join their signed results before target release. Helper: Automate dependency coverage and the same clause's selection/rating/transfer/print assertion set. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-12 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-12 source case family; CF-12 representative discriminators and proof; Configuration Work Procedures
Change an insurance package and selection rules `op.configuration.package` A package's happy path works, but a forbidden cover combination is still selectable. Treat it as a discriminator to test, not an assumed diagnosis.	Read the existing offer, covers, selection constraints and dependency rules; identify the required pricing baseline. LB_OFFERS and cover-definition rules govern selection, defaults and constraints. Mandatory, optional, conflict and limit rules must be tested as combinations. Prove: Selection, mandatory/optional covers, conflicts and limits work for allowed and forbidden combinations.	Profile: `configuration.offer.builder` Method: Reuse M/R/O extents, limits, dependencies, conflicts and negative combinations. Apply the approved package/offer delta while preserving unrelated packages and resolving any required tariff input from fresh evidence. Helper: Generate and run the bounded combination matrix from the declared offer constraints. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-13 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-13 source case family; CF-13 representative discriminators and proof; Configuration Work Procedures
Add a questionnaire answer or object field `op.configuration.questionnaire` The new question exists in INSIS but is ignored by IPAL or the rating request. Treat it as a discriminator to test, not an assumed diagnosis.	Map the question/answer or field to its INSIS-native definition, IPAL factor and ABACUS consumption, with effective dates. INSIS-native question/answer codes, IPAL factors and ABACUS input are distinct mappings. Requiredness may depend on another answer and need a real evaluator capability. Prove: The field/question is usable on every promised surface, mandatory conditions fire and rating receives the intended answer.	Profile: `configuration.ipal.builder` Method: Reuse native question owner, IPAL factors and rating-consumption mapping. Track INSIS-owner work and the affected IPAL/rating delta as separate obligations in the same requested delivery. Helper: Automate the mapping comparison and capture actual outgoing factor values for the question examples. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-14 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-14 source case family; CF-14 representative discriminators and proof; Configuration Work Procedures
Change an IPAL-to-INSIS mapping `op.configuration.integration-map` A new IPAL-to-INSIS mapping row is present but the transfer consumer never reads it. Treat it as a discriminator to test, not an assumed diagnosis.	Export the actual covers/objects/LD/field seam and compare both system code sets and consuming transfer code. Covers, objects, loadings and fields use different mapping keys. A configuration entry cannot implement a code capability that is absent. Prove: Representative transfer values map correctly, including negative/unmapped inputs and unaffected siblings.	Profile: `configuration.ipal.builder` Method: Reuse actual business keys and confirmed consuming transfer code. Apply the approved mapping delta; a missing code capability recruits Development rather than adding an inert mapping. Helper: Automate mapping coverage and consumer-capability checks, then replay representative transfer assertions. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-15 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-15 source case family; CF-15 representative discriminators and proof; Configuration Work Procedures
Create a product variant from a donor `op.configuration.product-variant` The product rows are cloned, but the variant still uses the donor's process, numbering or routes. Treat it as a discriminator to test, not an assumed diagnosis.	Inventory the donor and requested differences across the applicable parts; verify actual process reuse instead of assuming a complete clone. A donor's structures are not all reusable for the new product. The census’s 3606-from-3635 example required a product process/BPMN change as well as copied configuration rows. Prove: The variant's own codes, rating, route, process, transfer and documents work on its target; donor behaviour stays intact.	Profile: `configuration.ipal.builder` Method: Reuse donor/delta interpretation and actual process fit; no blind clone. Clone only approved structures, build affected stage deltas and recruit Development for required process/user-task changes. Helper: Automate a donor/variant dependency diff that flags embedded product ids, shared files and process/numbering reuse. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-16 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-16 source case family; CF-16 representative discriminators and proof; Configuration Work Procedures
Coordinate an INSIS-native product request `op.configuration.insis-native` ABACUS is ready, but the INSIS-native product is still unusable. Treat it as a discriminator to test, not an assumed diagnosis.	Record an INSIS-native objective: INSIS product/rules, ABACUS rating and only the required IPAL seam; do not invent an IPAL sales catalogue. The requested sales path belongs to INSIS, not an invented IPAL sales catalogue. ABACUS rating and any IPAL interface seam are separate deliverables. Prove: The INSIS-native sales flow receives correct rating and any promised seam behaviour; no false IPAL issuance claim.	Profile: `configuration.abacus.builder` Method: Reuse native-owner work plus only requested rating/interface parts. Coordinate the INSIS owner's product setup with selected rating/seam work; keep each target obligation visible until evidence returns. Helper: Automate native-request-to-rating/seam checks and flag missing external-owner evidence at the join. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-17 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-17 source case family; CF-17 representative discriminators and proof; Configuration Work Procedures
Reconcile changed product material `op.configuration.source-revision` A changed specification reaches one stage while another still consumes an older approved revision. Treat it as a discriminator to test, not an assumed diagnosis.	Correlate related source requests and versions, preserve contradictions, and identify which approved requirement changed. Re-uploaded files can amend or contradict earlier requirements. An old H3 or preview signature binds the old artefact, not the new values. Prove: All outputs consume the current approved requirement revision; superseded values no longer drive the target.	Profile: `configuration.normalizer` Method: Reuse source interpretation, revision comparison and dependency invalidation. Publish the amended S1 delta with H1a, invalidate dependent evidence and rerun affected stages/tests; retain valid prior work. Helper: Automate input-revision dependency tracing and report exactly which tests/sign-outs must be rerun. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-18 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-18 source case family; CF-18 representative discriminators and proof; Configuration Work Procedures
Configure and retire a time-limited campaign `op.configuration.campaign` A campaign works at launch but has no durable stop-offering or safe retirement plan. Treat it as a discriminator to test, not an assumed diagnosis.	Define campaign dates, eligibility, computed duration, offer behaviour and what happens to already issued policies. Start/end dates and eligibility must be tested at their boundaries. Stopping new sales is different from deleting definitions used by issued policies. Prove: Boundary dates and eligibility pass; after expiry new sales stop as intended while issued policies retain their valid terms.	Profile: `configuration.ipal.builder` Method: Reuse eligibility/date semantics, selected stage work and durable expiry. Coordinate code, rating, offer and labels; create durable stop-offering and later removal obligations with H7 before delivery. Helper: Automate boundary-date probes and due-obligation checks, with a historical-consumer test before removal. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-19 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-19 source case family; CF-19 representative discriminators and proof; Configuration Work Procedures
Change product route visibility `op.configuration.role-visibility` The product menu is hidden for an excluded role, but the backend still accepts access. Treat it as a discriminator to test, not an assumed diagnosis.	Read effective route/product roles in each target and the approved intended audience. Routes and product roles differ across targets. Menu visibility is only one access surface. Prove: Intended customer/agent roles see the product and an excluded role cannot access it; backend checks agree.	Profile: `configuration.serdica.builder` Method: Reuse intended/excluded actor checks across navigation and backend. Apply the exact visibility delta under the full shared-role/target authority and refresh the relevant projection/cache. Helper: Automate effective-audience expansion and paired navigation/backend probes. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-20 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-20 source case family; CF-20 representative discriminators and proof; Configuration Work Procedures
Reconcile a replacement nomenclature `op.configuration.nomenclature-reload` A nomenclature reload changes the meaning of keys already used by pricing or historical policies. Treat it as a discriminator to test, not an assumed diagnosis.	Compare old/new nomenclature business keys, pricing dependencies, labels and historical consumers across systems. Business keys are consumed by tariffs, labels and external mappings. A new catalogue may rename or regroup meanings rather than merely add rows. Prove: New selections price and transfer correctly, old policies remain interpretable and shared labels resolve.	Profile: `configuration.ipal.builder` Method: Reuse old/new business-key meaning, tariff dependencies and historic consumers. Apply only a reviewed compatible reload/mapping plan; unresolved tariff semantics become a business question, not a blind replacement. Helper: Automate the old/new key diff with consumer references and unresolved semantic changes. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-21 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-21 source case family; CF-21 representative discriminators and proof; Configuration Work Procedures
Change an effective commission rule set `op.configuration.commission-rule` A commission expression fixes the requested product but changes historical or unrelated calculations. Treat it as a discriminator to test, not an assumed diagnosis.	Read the effective commission rule set, product/agent scope, dates and dependent policy calculations. The rule's product/agent scope and effective date determine its audience. A policy-specific commission repair is different from changing a rule set. Prove: Representative effective-date and participant cases produce the expected commission with currency; unaffected scopes stay unchanged.	Profile: `configuration.ipal.builder` Method: Reuse CFG_COMMISSION_EXP / SRD_PR.CF_COMM_PRODUCTS and unaffected-scope examples. Apply the approved rule delta and declared external counterpart; keep policy-specific repairs separate. Helper: Automate rule-consumer expansion and a versioned commission example matrix. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-23 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-23 source case family; CF-23 representative discriminators and proof; Configuration Work Procedures
Register a process or contract type `op.configuration.process-registration` CONTRACT_TYPE or a process registration is deployed but empty or never consumed. Treat it as a discriminator to test, not an assumed diagnosis.	Map contract-type/process registration to real schema support, configuration values, BPMN and code consumers. A schema column, populated values and the consumer capability are separate release components. BPMN/product registration must select the intended process. Prove: The declared process/contract type is populated and actually selected by the target workflow, with an authorised test instance.	Profile: `configuration.ipal.builder` Method: Reuse schema presence, populated values and actual workflow consumption. Coordinate the Configuration and Development results; deploy compatible schema/code before activating rows where required. Helper: Automate capability/value/consumer checks and record the selected process version for the test instance. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-24 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-24 source case family; CF-24 representative discriminators and proof; Configuration Work Procedures
Compare selected environment configuration `op.configuration.environment-reconciliation` A delta built from TEST assumes columns or definitions that do not exist on PROD. Treat it as a discriminator to test, not an assumed diagnosis.	Compare only affected source/target groups in both directions, including columns, current rows, effective versions and consuming code. UI_REQUIRED is a documented TEST-only column; target schema must be checked before packet construction. The census also finds legitimate PROD-only deductible/rule data and differing effective versions. Prove: The report accounts for every selected difference, or the applied delta passes its target assertions while preserving accepted target-only work.	Profile: `configuration.normalizer` Method: Reuse directional schema/row/version reconciliation; report-only when requested. Produce a reviewed reconciliation delta or a report-only result as requested; do not synchronise environments wholesale. Helper: Automate a target-aware four-layer diff of schema, data, effective versions and consuming code. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	CF-25 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. CF-25 source case family; CF-25 representative discriminators and proof; Configuration Work Procedures

Desk and investigation

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Answer a how-to or lookup from checked experience `op.desk.answer` A transferred policy received a neighbouring policy's internal identifier as its displayed number. Treat it as a discriminator to test, not an assumed diagnosis.	Retrieve the relevant active precedent and check the current system/version and the exact customer question. The numbering sentinel regenerates only when POLICY_NO equals that policy's own SR_POLICY_ID. A different policy's identifier in that field does not trigger the intended generation path. Prove: The answer's current factual basis is retained; action requests additionally require the declared outcome evidence.	Profile: `support.resolution` Method: Reuse experience retrieval and current applicability; investigate when the answer is not supported. Deliver the checked answer through the send gate; if a customer action is required, persist its waiting/proof obligation. Helper: Build an identity/number/transfer comparison that supplies safe equality facets and refuses a neighbouring-id shortcut. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DC-22 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DC-22 source case family; DC-22 representative discriminators and proof; Experience Strategies
Correlate request delivery and linked current work `op.desk.arrival-correlation` A poll/webhook/mail/Jira mirror may repeat one source revision or refer to a related open case.	Verified tenant/source/revision identity and explicit mirror mapping Authorised current-case metadata; related object alone is not a duplicate Prove: One durable arrival/case correlation for duplicate delivery; independent occurrences remain separate and related work stays visible.	Profile: `support.root` Method: Use intake software and current registry; triage classifies the business request afterwards. Helper: Existing executable seeds: aisa-jira, aisa-mail and aisa-hdesk CLIs. Poll cursors, origin dedup and case wake-up are runtime mechanics, not a new agent or learned tool.	Cross-channel intake is an existing standing operation; frequency is not counted here. Intake; README; README; README
Classify a request and calculate its clocks `op.desk.classification` The request type, contract position or authority route is unclear; do not derive a mechanism from its title.	Original requested result, current contract/calendar and authenticated customer scope Related current cases and reviewed routing summaries Prove: Correctable class, urgency/clocks and selected route with unresolved facts retained.	Profile: `support.root` Method: Root uses classify-ticket and the classification experience strategy in the same case brief as routing; support.triage is an optional adviser for ambiguity. Helper: Clock calculation and case lookup are runtime operations. The classification judgment remains LLM/domain work.	Recurring desk operation; Operational Method Evidence describes classification in the archived ticket corpus without a new frequency estimate. skill; Experience Strategies; Stage Classification
Investigate without a matching experience or known mechanism `op.investigation.fresh-evidence` No relevant experience; retrieved pattern is stale/contradicted; or the symptom does not yet identify a domain.	Restated desired outcome and observed symptom, exact actor/surface/time/environment, expected versus actual result Source evidence and current read scope; negative search coverage and what would distinguish competing explanations Prove: Evidence-led mechanism with layer and provenance, separating checks, rejected hypotheses and an independent verdict—or explicit unknown with the next evidence needed. No fabricated familiar pattern.	Profile: `support.investigator` Method: Root dispatches the read-only bootstrap investigator when no domain is known. Reuse the matching existing domain investigator in fresh-evidence mode when known; hand over established evidence and domain recommendation without losing context. Helper: Reuse existing channel/log/DB/source readers as runtime access. A bounded extraction/comparison helper may emerge from evidence; do not invent a confident pattern-matching executable.	Required fallback for every recurring family, not a claim that an unknown symptom is itself a measured frequent category. Stage Investigation; Experience Strategies; verify dont guess; failed probe is not a finding
Correlate the actual request and failure trace `op.desk.trace-evidence` UI text or HTTP status is ambiguous, or logs without the exact invocation suggest a misleading cause.	Request id/object handle and tight time/environment window Per-operation logs including events whose message omits the policy id Prove: Attributed invocation/response chain and explicit log gaps; a failed probe is not evidence of absence.	Profile: `support.resolution` Method: Selected domain investigator follows invocation-first and cross-channel evidence discipline. Helper: Existing log connector access; optional normaliser/correlation script only for a proven log shape. No new permanent tracing agent.	Operational Method Evidence row 4: 45 tickets asked / 45 analyses used for Kibana tracing; historical, not current incidence. kibana log access; kibana batch response printdocs array; insis tablespace exhaustion transfer halt; Archived trace-operation recurrence, row 4
Draft and communicate a sourced result or question `op.desk.communicate-result` The customer needs clarification, a verified result, owner instructions or an offer/decision response.	Original objective, current verified facts/open obligations and intended audience Actual approved values/terms, recipient/source mapping and exact content revision Prove: Audience-appropriate draft and permitted delivery evidence; remaining acceptance/waiting is explicit.	Profile: `common.communicator` Method: Reuse common communication; root retains customer and execution authority. Helper: Existing source/binary CLI seeds: aisa-jira, aisa-mail and aisa-hdesk. Sending is a gated connector effect, not implied by successful drafting.	Operational Method Evidence records 330 tickets with a customer conversation phase; this is the historical phase count, not a count of sent messages. README; README; README; customer reply on point; Conversation phase denominator
Find a person or company policies and requested records `op.reporting.person-policies` A lookup/export asks for scoped policy relationships rather than a repair.	Authorised person/company handles, requested role/systems/time coverage Current source tables and inclusion/exclusion semantics Prove: Complete scoped lookup/export with provenance and limits; no guessed missing relationships or raw PII retained as shared memory.	Profile: `support.resolution` Method: Reuse person-policies; distinguish role lookup from arbitrary report SQL. Helper: Existing executable SQL seed: sql/templates/person_policies_json.sql. CSV/XLSX rendering is optional mechanical output; access filtering remains enforced.	Operational Method Evidence rows 32 and 33 each record 5 requests; categories may overlap and are not summed. skill; person policies json; Operational Method Evidence

Operational recovery

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Reconcile an interrupted Beth or automation action `op.recovery.partial-automation` An earlier Beth automation stopped after some effects had already landed. Treat it as a discriminator to test, not an assumed diagnosis.	Inspect the Beth operation batch, completed steps and missing downstream work; determine what already landed. Beth operation batches can contain successful and missing downstream steps. A repeated whole batch can duplicate a document, registration or annex. Prove: The promised annex, print or commission result exists; earlier successful steps were not duplicated.	Profile: `support.investigator.transfers` Method: Reuse the underlying domain procedure after establishing actual landed effects. Repair only the missing step under its own permission; replay nothing merely because the earlier automation stopped. Helper: Automate a batch-to-target receipt comparison and emit only the unresolved action set. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	Archived tickets asked / analyses used: 14 / 24, Operational Method Evidence row 19 (Beth-failure triage; individual landed-effect variants not separately counted); overlapping historical samples, not current incidence or a variant count. DC-23 source case family; DC-23 representative discriminators and proof; beth assistant; Archived recurrence method and row 19
Repair business residue after infrastructure recovers `op.recovery.business-residue` Infrastructure is healthy again but some policies or workflows remain half-written. Treat it as a discriminator to test, not an assumed diagnosis.	Confirm infrastructure recovery through its owner and classify per-policy partial effects from the outage. A healthy service probe proves availability, not consistency of the interrupted work. An outage can leave different items before dispatch, after a target effect or before checkpointing. Prove: Every declared item has policy/workflow and customer-surface proof; service health alone does not satisfy it.	Profile: `support.investigator.transfers` Method: Reuse incident evidence plus per-policy/workflow reconciliation. Wait for healthy dependencies, then repair each affected policy/workflow using current preconditions and its own effect identity. Helper: Automate a journal-versus-target recovery inventory, keeping uncertain calls distinct from safe retries. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DC-24 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DC-24 source case family; DC-24 representative discriminators and proof; microservice topology; orphaned dblink session transfer backlog
Diagnose and recover an orphaned database-link backlog `op.recovery.dblink-backlog` Work waits on dead @insis sessions while the remote system may be healthy.	Both ends of the link, current session waits/ASH, locks and actual service workers Per-policy backlog and actual landed state, not a cumulative FAIL count Prove: Attributed link failure, authorised infrastructure-owner action and per-item business reconciliation afterwards.	Profile: `support.investigator.transfers` Method: Reuse the relevant domain investigation and explicit infrastructure/external-owner coordination; recovery effects remain separately authorised. Helper: Candidate: bounded symptom/trace/landed-state report. Restart, session termination, storage changes or process operations are connector effects, not a new recovery binary.	Recurring incident family or known discriminator retained in the referenced operational record; no new occurrence total asserted. orphaned dblink session transfer backlog; Failure and Recovery
Separate broker/channel recovery from business retry `op.recovery.broker-channel` Oversized response or closed channel leaves repeated empty/error responses after the initial request.	Exact request/response size, broker close reason, service channel state and gateway result Affected callers and scoped records; infrastructure and business residues separated Prove: Owner-permitted recovery plus actual healthy request proof; shared generic fixes become Core requests, not immediate AISA implementation.	Profile: `support.investigator.transfers` Method: Reuse the relevant domain investigation and explicit infrastructure/external-owner coordination; recovery effects remain separately authorised. Helper: Candidate: bounded symptom/trace/landed-state report. Restart, session termination, storage changes or process operations are connector effects, not a new recovery binary.	Recurring incident family or known discriminator retained in the referenced operational record; no new occurrence total asserted. pas notes unbounded reply amqp channel kill; Failure and Recovery
Recover a genuinely halted process `op.recovery.camunda-halt` A policy appears pending but could be a process halt, underwriting block or number collision.	Definition/instance/task state and the gPolicyNo / TransferPolicy.Start trace boundary Current target policy existence, exact business error and effect journal Prove: Correct branch and approved owner recovery; no resetting a healthy workflow or repeating a completed effect.	Profile: `support.investigator.transfers` Method: Reuse the relevant domain investigation and explicit infrastructure/external-owner coordination; recovery effects remain separately authorised. Helper: Candidate: bounded symptom/trace/landed-state report. Restart, session termination, storage changes or process operations are connector effects, not a new recovery binary.	Recurring incident family or known discriminator retained in the referenced operational record; no new occurrence total asserted. ipal camunda midflow halt; Failure and Recovery
Recognise storage exhaustion behind a data-shaped error `op.recovery.storage-exhaustion` A missing-data UI message masks ORA-01653/01654 in a differently keyed log event.	Tight complete error window without assuming every message contains the policy id Actual storage/object failure and current partial transfer/questionnaire evidence Prove: Infrastructure-owner escalation with attributed evidence, then proof/recovery of the affected business state.	Profile: `support.investigator.transfers` Method: Reuse the relevant domain investigation and explicit infrastructure/external-owner coordination; recovery effects remain separately authorised. Helper: Candidate: bounded symptom/trace/landed-state report. Restart, session termination, storage changes or process operations are connector effects, not a new recovery binary.	Recurring incident family or known discriminator retained in the referenced operational record; no new occurrence total asserted. insis tablespace exhaustion transfer halt; Failure and Recovery
Diagnose a frozen agent/reference replica `op.recovery.replica-freeze` New agents or default commissions disappear while direct transfer can still resolve live INSIS data.	Source and replica business keys/current rows, batch log and uniqueness failure Actual consumers: replica reads versus live remote lookup Prove: Correctly scoped sync/consumer diagnosis and authorised correction, with fresh missing-agent and commission proof.	Profile: `support.investigator.transfers` Method: Reuse the relevant domain investigation and explicit infrastructure/external-owner coordination; recovery effects remain separately authorised. Helper: Candidate: bounded symptom/trace/landed-state report. Restart, session termination, storage changes or process operations are connector effects, not a new recovery binary.	Recurring incident family or known discriminator retained in the referenced operational record; no new occurrence total asserted. insis p agents replica sync; Failure and Recovery

Development and delivery

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Change a customer product process `op.source.product-process` A product's process code is updated, but Camunda still runs the old BPMN version or the wrong product path. Treat it as a discriminator to test, not an assumed diagnosis.	Pin the product's actual process, user-task code, deployed BPMN and both repository lineages; identify the Configuration dependency. Core restart/upload behaviour is part of the BPMN release, not just the image build. The customer's process files and user-task code can live at different paths from master. Prove: The target serves the expected process version and an authorised test instance reaches the requested stage; old in-flight instances are accounted for.	Profile: `source.camunda_developer` Method: Reuse source-specific process authoring and running-instance review. Implement and test the process change, review the commit series, deploy the declared Core image/BPMN set and record the job identity. Helper: Automate source/BPMN/target-version comparison and capture the test instance's stage transitions. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-01 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-01 source case family; DV-01 representative discriminators and proof; Components
Deliver a customer print-contract change `op.source.print-contract` The bank-beneficiary print change is only half-promoted: the selector is enabled before its evaluator and data dependencies are ready. Treat it as a discriminator to test, not an assumed diagnosis.	Separate print-registration rows, C# selection, shared library, POLQRY and externally owned BI template behaviour. SD-1863's archived PROD review found missing configuration rows and an empty POLQRY.gINSIS_CREDITED_OBJ_IDS body. The unknown print token failed open, producing unwanted documents rather than safely suppressing them. Prove: The exact document and parameters are correct on target; negative selectors do not produce unwanted documents and the deployed package is not a stub.	Profile: `source.planner` Method: Reuse complete C#/PLSQL/row/template compatibility; separate new shared-Core requirements. Use coordinated Configuration/Development work and external template obligations; release in the compatibility order of the exact components. Helper: Automate a print-release manifest plus positive/negative document-selection probes, including a stored-code-body capability check. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-02 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-02 source case family; DV-02 representative discriminators and proof; Components
Change a customer product calculation `op.source.product-calculation` A premium-rule library is released, but an active consumer still computes the old result. Treat it as a discriminator to test, not an assumed diagnosis.	Reproduce the product-family premium/cover rule and inspect plugin versus shared-service placement on each actual lineage. The rule may belong to a customer plugin or a shared service on the actual lineage. Publishing a NuGet version does not rebuild its consumers. Prove: Worked quotes cover affected products, boundaries and unchanged siblings; ABACUS and INSIS reconcile with the intended rule.	Profile: `source.planner` Method: Reuse customer-rule placement, paired consumers and component pricing tests. Implement at the approved seam; package changed libraries and rebuild all declared consumers with companion rows where needed. Helper: Automate package-to-serving-consumer version checks and replay the per-product arithmetic matrix. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-04 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-04 source case family; DV-04 representative discriminators and proof; Components
Harden a partner registration contract `op.source.partner-registration` RegisterPolicy returns success, but the partner's policy later fails transfer or printing. Treat it as a discriminator to test, not an assumed diagnosis.	Pin the partner request contract, registration plugin, identity-client configuration and required database schema. The registration plugin, identity client and database schema form one contract. Repeated requests and supplied policy numbers need declared idempotency/validation behaviour. Prove: The approved staging contract examples register, transfer and print; invalid and repeated requests follow the declared behaviour.	Profile: `source.implementer.serdica-backend` Method: Reuse bounded partner-plugin and interface contract work. Implement the bounded API change with its schema/identity dependencies; deploy only to the explicitly requested partner target. Helper: Automate request replay and downstream policy/transfer/print correlation, with credentials and customer identifiers excluded from retained fixtures. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-05 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-05 source case family; DV-05 representative discriminators and proof; Components
Repair a customer party-data contract `op.source.party-contract` The UI accepts party data that the active backend rejects or transfers differently. Treat it as a discriminator to test, not an assumed diagnosis.	Reproduce customer/party validation in UI and backend, including LDAP and INSIS propagation; map the actual code paths. Customer fields pass through UI validation, backend rules and INSIS propagation. custPid, optional addresses and account-related fields have distinct source/format rules. Prove: Create/edit the test customer on target and verify transferred participant data; check the prior valid cases still work.	Profile: `source.planner` Method: Reuse client/server/identity/source-of-truth contract; classify any shared-Core requirement separately. Implement the approved pair of changes plus identity dependencies and deploy them in the declared compatibility order. Helper: Automate the UI-request-backend-target field comparison using sanitised fixtures. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-06 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-06 source case family; DV-06 representative discriminators and proof; Components
Repair agent/office/commission code integration `op.source.commission-contract` The participant/commission UI reaches production while its required backend half remains on staging. Treat it as a discriminator to test, not an assumed diagnosis.	Reproduce participant search/office/commission behaviour and establish which backend and UI halves are actually deployed. The participant search and commission default depend on both UI and backend behaviour. The catalogue's SD-1709 example specifically exposes a missing backend promotion. Prove: Target participant search and commission defaults work together with the approved agent/office rules.	Profile: `source.planner` Method: Reuse paired customer UI/backend release and current consumer proof. Implement and review the bounded feature or defect across its consumers; keep each target's missing half as a release obligation. Helper: Automate a serving-capability/version check before the participant and commission regression probes. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-07 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-07 source case family; DV-07 representative discriminators and proof; Components
Repair or promote a customer object screen `op.source.object-screen` The requested object-dialog behaviour already exists in source but the target serves an older version. Treat it as a discriminator to test, not an assumed diagnosis.	Check whether the object dialog feature is absent, defective or simply not deployed; record target browser behaviour and serving revision. Feature absence, a bug and a missing promotion require different work. The description/dialog history includes changes that did not reach production. Prove: The actual dialog opens, edits, validates and persists as requested; repeated navigation and relevant fields work.	Profile: `source.implementer.serdica-ui` Method: Reuse actual target UI evidence; an already-implemented feature may need only a scoped promotion. Implement or promote only the needed approved UI change, including labels and data-contract dependencies. Helper: Automate the target-version check and a small dialog interaction/persistence regression. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-10 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-10 source case family; DV-10 representative discriminators and proof; Components
Deliver a customer framework-contract change `op.source.framework-contract` A framework contract-type column exists, but required values are NULL or never selected by the process. Treat it as a discriminator to test, not an assumed diagnosis.	Pin FRAME/contract-type schema, plugin, workflow and shared Annexes behaviour plus the expected configuration values. Schema, configuration values, code/plugin and workflow are separate dependencies. Cargo FRAME/group-policy behaviour may touch shared Annexes consumers. Prove: The target can create the declared child under the correct framework; contract-type values are populated and consumed.	Profile: `source.planner` Method: Reuse schema/value/plugin/process compatibility; shared-Core work is separately referred. Coordinate code, schema and Configuration rows in a dependency graph; record both repository heads and all consumer images. Helper: Automate schema/value/consumer checks and capture the framework/child linkage in the smoke test. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-11 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-11 source case family; DV-11 representative discriminators and proof; Components
Change a customer motor-product flow `op.source.motor-flow` A motor-flow change handles one subtype but retries an ambiguous partner timeout or breaks a sibling product. Treat it as a discriminator to test, not an assumed diagnosis.	Reproduce the motor-flow rule with product/subtype, partner service response and process version; distinguish a waiting backlog request. Product/subtype and process version determine which rule executes. A timeout may follow a completed external effect. Prove: The affected flow works for the requested subtype and relevant sibling products; external effects are separately permitted.	Profile: `source.implementer.serdica-backend` Method: Reuse subtype-specific plugin/service behavior and external-timeout reconciliation. Implement the scoped plugin/service/riskmodel change or keep Next Release waiting with its explicit trigger. Helper: Automate subtype/response replay with explicit unknown-outcome checks instead of a blanket retry script. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-12 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-12 source case family; DV-12 representative discriminators and proof; Components
Change a customer pricing filter `op.source.rating-filter` A routine port restores a pricing filter that was deliberately reversed on production. Treat it as a discriminator to test, not an assumed diagnosis.	Read the Python riskmodel pre/post-filter, chosen template and current target revision, including PROD-only reversals. Python riskmodel pre/post-filters choose or transform rating inputs/results. Target-only reversals are part of the intended target state until reviewed. Prove: Current get_rates inputs produce expected per-cover premiums and template selection; unaffected cases remain valid.	Profile: `source.implementer.serdica-backend` Method: Reuse backend-repository Python method with target-specific reversal history. Use the backend repository's Python toolchain; implement and test the filter, then deploy the declared anl-risk-model artifact. Helper: Automate per-cover filter regressions and compare the proposed port with recorded target-only reversals. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-13 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-13 source case family; DV-13 representative discriminators and proof; Components
Deliver a caller and stored-code transfer change `op.source.transfer-contract` The C# caller is promoted but the live PL/SQL still implements the old transfer/revert contract. Treat it as a discriminator to test, not an assumed diagnosis.	Reproduce the C# caller/PLSQL contract and transfer/revert behaviour; snapshot the live stored code and effect history. Stored code may not be versioned in the repository alongside its caller. A return-to-application sequence can affect an entire multi-year family. Prove: The intended transfer/revert works on target without duplicate effects; the family invariants still hold after the sequence.	Profile: `source.planner` Method: Reuse paired C#/PLSQL contract, signature and real operation proof. Deliver the caller and stored-code change in the compatible order; gate DDL and reconcile external effects after timeouts. Helper: Automate caller/package capability checks and the journal-backed transfer/revert assertion sequence. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-14 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-14 source case family; DV-14 representative discriminators and proof; Components
Join control code, activation and messages `op.source.control-activation` The new validation library builds successfully, but no enabling row or Bulgarian message reaches the target. Treat it as a discriminator to test, not an assumed diagnosis.	Identify the generic code capability, its enabling configuration and message keys, across published package and serving consumers. The generic Operations library, configuration activation and SR_MESSAGES are separate components. A package version is not enough if a consumer was not rebuilt. Prove: Trigger the control on target; required invalid input is blocked, valid input passes and the Bulgarian message resolves.	Profile: `source.planner` Method: Reuse existing capability first; configuration activation may be enough; new shared generic code is Core referral. Implement/release the library and explicitly deliver its required rows through Configuration or the scoped owner. Helper: Automate capability/activation/message completeness checks and replay the invalid/valid operator examples. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-15 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-15 source case family; DV-15 representative discriminators and proof; Components
Reconcile and port an accepted change between branches `op.source.branch-port` A cross-branch port matches a commit subject but loses target-only behaviour or lands on the wrong layout. Treat it as a discriminator to test, not an assumed diagnosis.	Pin source and target heads, actual layouts, target-only fixes and semantic correspondence; detect non-fast-forward history changes. Source and target paths can differ substantially. Target-only fixes and reversals must be preserved explicitly. Prove: Target tests and explicit equivalence evidence cover the intended change; source subject matching is insufficient.	Profile: `source.deployer` Method: Reuse current heads, semantic delta, target-only settings and target tests. Reapply the reviewed semantic change in the requested direction without discarding target-only work; review the resulting target diff. Helper: Automate head/path/patch correspondence and flag target-only or rewritten-history conflicts for review. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-17 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-17 source case family; DV-17 representative discriminators and proof; Components
Repair a customer build or deployment dependency `op.source.toolchain` The image is published after a tooling change, but a clean build or the actual deployment job still fails. Treat it as a discriminator to test, not an assumed diagnosis.	Identify the failing build/runtime boundary, actual dependency graph, pipeline identity and generated outputs affected. CI configuration, runtime dependencies, lockfiles and generated schemas can change together. The job identity and target environment must be explicit. Prove: A clean reproducible build and the declared runtime/job checks pass; image publication alone is not deployment proof.	Profile: `source.planner` Method: Reuse actual failing runtime/toolchain/job boundary and reproducible target build. Make the scoped tooling/dependency/pipeline change; review lockfiles, generated schemas and instruction files as relevant changes. Helper: Automate a pinned clean-build/job/artifact verification run and report the exact failing boundary. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-18 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-18 source case family; DV-18 representative discriminators and proof; Components
Correct environment-specific service settings `op.source.environment-settings` An appsettings reset overwrites an environment-specific route or secret reference. Treat it as a discriminator to test, not an assumed diagnosis.	Compare environment-specific appsettings and runtime consumption; separate intended configuration from accidental local reset. The active service may read values from a different source than the edited local file. Environment-specific routes are intentional differences until reviewed. Prove: The active service reads the intended route/setting and required integration works on its target.	Profile: `source.deployer` Method: Reuse minimal target setting delta and actual runtime consumption. Apply only approved target values through the declared config/image release; keep secrets in the existing secret store. Helper: Automate a redacted target-setting diff and a focused consumption probe, showing references rather than secrets. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-19 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-19 source case family; DV-19 representative discriminators and proof; Components

Assessment and referrals

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Assess and refer a reinsurance programme `op.source.programme-reinsurance` A request for a reinsurance capability is treated as one small fix despite programme-scale scope. Treat it as a discriminator to test, not an assumed diagnosis.	Record the reinsurance capability request and programme owner; distinguish a bounded defect from the ongoing module stream. The catalogue describes facultative, treaty, claims and reporting work across many plugins and services. No single generic 'done' test can establish that entire capability. Prove: An attributable programme referral and explicitly bounded requested scope; no claim that the programme was implemented. Any later customer-specific slice is separately scoped and authorised.	Profile: `source.planner` Method: Reuse programme scope/referral, not an implemented small fix. Return an explicit programme referral with accountable ownership; accept only separately scoped implementation cases under the current charter. Helper: Use a read-only component/dependency inventory to support scope assessment; do not invent an execution tool for an unapproved programme. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-03 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-03 source case family; DV-03 representative discriminators and proof; Components
Assess and refer a currency changeover programme `op.source.programme-currency` The BGN-to-EUR programme is compressed into one case and legacy-currency behaviour is lost. Treat it as a discriminator to test, not an assumed diagnosis.	Record the cross-product currency programme, affected seams and accountable coordination owner; identify any requested bounded slice. The change spans plugins, shared models, rating filters, printing and UI interpretation. The history contains reverts and restoration of conversion behaviour. Prove: An attributable programme referral and explicitly bounded requested scope; no claim that the programme was implemented. Any later customer-specific slice is separately scoped and authorised.	Profile: `source.planner` Method: Reuse programme scope, owner and bounded follow-on requests. Refer the programme within the current charter; scoped currency fixes use ordinary source/configuration cases with explicit dependencies. Helper: Automate a slice-specific quote/transfer/print comparison with explicit currency and conversion basis. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-08 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-08 source case family; DV-08 representative discriminators and proof; Components
Assess a shared numeric-input correction `op.source.shared-number-input` A Bulgarian number field looks correct but submits a different numeric value after parsing or blur. Treat it as a discriminator to test, not an assumed diagnosis.	Reproduce the exact Bulgarian input gesture, field validator and locale parsing on the active UI lineage. The relevant path includes toNumberParser, form validation and the actual outgoing payload. Comma/dot entry, blur and reopening exercise different transitions. Prove: Source-grounded Core classification, assessed request and actual owner-supplied offer/delivery terms communicated; missing terms remain pending. Acceptance grants no implementation or deployment.	Profile: `commercial.assessor` Method: Reuse assessment and offer preparation with source-domain read-only consultation. Shared Core behavior is a request/offer/delivery communication outcome, never an AISA implementation pipeline. Helper: Optional captured-workload or UI-input comparison to make the request reproducible; no implementation/release automation within the Core request. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-09 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-09 source case family; DV-09 representative discriminators and proof; Components
Assess a shared paging or robustness correction `op.source.shared-robustness` A robustness patch exists but the affected query still scans, truncates useful results or leaks the wrong error. Treat it as a discriminator to test, not an assumed diagnosis.	Use incident evidence to reproduce the bounded clamp/index/error defect and identify all consuming services. The original boundary workload determines whether the clamp/index fix is valid. An index's existence does not prove the query uses an appropriate predicate. Prove: Source-grounded Core classification, assessed request and actual owner-supplied offer/delivery terms communicated; missing terms remain pending. Acceptance grants no implementation or deployment.	Profile: `commercial.assessor` Method: Reuse assessment and offer preparation with source-domain read-only consultation. Shared Core behavior is a request/offer/delivery communication outcome, never an AISA implementation pipeline. Helper: Optional captured-workload or UI-input comparison to make the request reproducible; no implementation/release automation within the Core request. Current executable evidence: the cited case/procedure supplies a method, not a published implementation of this proposed helper.	DV-16 documents a recurring family or repeated source/intake work; no separate operation-frequency measurement is asserted. DV-16 source case family; DV-16 representative discriminators and proof; Components

Health reports and claims

Operation and current discriminator	Evidence → required result	Reuse and automation	Recurrence and source
Review a provider report and its actual decisions `op.health.report-review` A loaded report has rejected lines, wrong person/claim linkage or unexplained amounts.	Original file and current HLT_IMP_FILES/HLT_IMP_DATA/HLT_INVOICES identities on the actual environment Insured/claim linkage, per-line pipeline outcomes and expected business rule Prove: A source-to-line-to-claim explanation with correct/incorrect/unknown outcomes and scoped next action, not a claim that file upload completed processing.	Profile: `support.investigator.health` Method: Reuse health investigation / review-ao-report and the actual current feature contract; minimise special-category data. Helper: Candidate: scoped file/line/claim/arithmetic or repeated-call comparator. Existing referenced procedures/source are seeds; runtime reads, reprocessing and payments are not generic learned tools.	Repeated health report/claim work documented in the referenced procedure or run series; variant frequency is not independently counted. skill
Correct and resume the right health report/claim scope `op.health.report-correction` An imported line is corrected but downstream claims or processing state may still reflect the old input.	Current report/line/claim relation, actual correction capability and concurrency state All lines sharing the affected claim; force-reparse/resume behavior and existing downstream effects Prove: Approved correction and coherent reprocessing scope with fresh claim/amount proof; changing a line alone is not called repaired processing.	Profile: `support.investigator.health` Method: Reuse health investigation / review-ao-report and the actual current feature contract; minimise special-category data. Helper: Candidate: scoped file/line/claim/arithmetic or repeated-call comparator. Existing referenced procedures/source are seeds; runtime reads, reprocessing and payments are not generic learned tools.	Repeated health report/claim work documented in the referenced procedure or run series; variant frequency is not independently counted. hlt report line correction paths; skill
Reconcile health evaluations, amounts and payments `op.health.amount-reconciliation` Report/claim aggregates agree but the approved amount or state may be overwritten by another pipeline step.	Current evaluations, requested/approved/detail amounts and exclusion/type semantics Actual pipeline order, claim status and payment footprint Prove: A per-component arithmetic/state verdict and authorised correction scope; agreement between wrong aggregates is not proof.	Profile: `support.investigator.health` Method: Reuse health investigation / review-ao-report and the actual current feature contract; minimise special-category data. Helper: Candidate: scoped file/line/claim/arithmetic or repeated-call comparator. Existing referenced procedures/source are seeds; runtime reads, reprocessing and payments are not generic learned tools.	Repeated health report/claim work documented in the referenced procedure or run series; variant frequency is not independently counted. health claim pipeline step14 overwrites step13; skill
Coordinate a health payment confirmation or undo `op.health.payment-confirm-undo` An invoice batch is to be paid or undone; HTTP 200 may carry blockers and partial handling would violate batch semantics.	Current whole-batch invoice/report/line/claim states and actual endpoint contract Office/actor authority, blocker list, dry-run flag and paid/exported state Prove: Only an authorised eligible batch action with per-line result and payment/reversal proof; default dryRun=false never becomes an inspection.	Profile: `support.investigator.health` Method: Reuse health investigation / review-ao-report and the actual current feature contract; minimise special-category data. Helper: Candidate: scoped file/line/claim/arithmetic or repeated-call comparator. Existing referenced procedures/source are seeds; runtime reads, reprocessing and payments are not generic learned tools.	Repeated health report/claim work documented in the referenced procedure or run series; variant frequency is not independently counted. hlt ao payment confirm undo; skill
Diagnose repeated rating work during report processing `op.health.import-call-repetition` Processing is slow although HTTP returned; repeated per-claim rating calls may dominate.	Exact import/time/claim correlation and current call counts/durations Identical semantic inputs, involved callers and current pipeline state Prove: Measured redundant work and bounded reuse proposal without removing required independent checks or claiming import completion from HTTP.	Profile: `support.investigator.health` Method: Reuse health investigation / review-ao-report and the actual current feature contract; minimise special-category data. Helper: Candidate: scoped file/line/claim/arithmetic or repeated-call comparator. Existing referenced procedures/source are seeds; runtime reads, reprocessing and payments are not generic learned tools.	Repeated health report/claim work documented in the referenced procedure or run series; variant frequency is not independently counted. hlt ao import abacus call amplification; skill

Helper consolidation

P Every row above names a helper candidate of its own. Read together they collapse into eight bounded helpers; the table names the operations each would serve, the catalogued method it extends and the source it is seeded from. A helper is built only after its input/output and falsifying cases are established (how a row becomes retained capability); until then it is a proposal, and the machine-readable inventory carries the same list under helper_consolidation. Helpers with real source today — the channel CLIs, aisa-blob, the person-policies SQL template, the vehicle comparator and the product-model validator — are catalogued under their methods on the agent and method subpage. The complete inventory of what the v1 memory could still become — every tool, skill and article with its seeds, owner and evidence — is Memory-derived capabilities.

Helper	Method it extends	Serves	Seeds
Both-administration policy and family comparator `helper.policy-family-compare`	`data.skill.policy-compare`	`op.transfer.whole-policy-compare`, `op.myr.family-repair`, `op.myr.missing-register`, `op.myr.uncreated-periods`, `op.myr.cancelled-chain`, `op.myr.renewal-object`, `op.myr.period-premium`, `op.transfer.state-period`, `op.transfer.participants`, `op.transfer.hollow-policy`, `op.transfer.cancel-timeout`, `op.cargo.sync-framework`, `op.cargo.extend-framework`	srd_integr_compare_ipal_insis_car.sql; policy_sync_compare_checklist.md; multiyear_policy_verification_checklist.md
Transfer trace: MIGR_LOG, notes and the log window in one read `helper.transfer-trace`	`data.skill.transfer-diagnosis`	`op.transfer.stuck`, `op.transfer.backlog`, `op.desk.trace-evidence`, `op.recovery.storage-exhaustion`, `op.recovery.dblink-backlog`, `op.recovery.business-residue`	kibana_log_access.md; transfer_already_started_idempotency_guard.md; transfer_pipeline.md
getRates request-versus-result comparator per cover, loading and tax `helper.rating-replay`	`configuration.skill.rating-verification`	`op.pricing.replay`, `op.pricing.policy-components`, `op.configuration.tariff-refresh`, `op.configuration.loading-rule`, `op.configuration.partner-template`	abacus_getrates_direct_call.md; abacus_rates_presentation.md; premium_ld_applied_vs_fed_factor.md
Identity → account → office → role inventory and effective-audience expansion `helper.access-inventory`	`data.skill.access-diagnosis`	`op.access.account-lifecycle`, `op.access.agent-office`, `op.configuration.bypass-audience`, `op.configuration.role-visibility`	identity_server_ldap_authentication.md; ipal_routes_product_access.md; ipal_user_layer_separation.md; skill.md
Invocation, registration, data-readiness and artefact-age probe `helper.print-probe`	`data.skill.print-diagnosis`	`op.printing.source-data`, `op.printing.generate-document`, `op.printing.office-source`, `op.billing.print-bill`, `op.configuration.print-registration`, `op.myr.stale-document`	document_generation.md; cfg_print_docs_template_configuration.md; README.md; policy_print_recipe.md
Target-aware configuration diff: schema, rows, effective versions, consuming code `helper.config-diff`	`configuration.skill.catalogue-build`	`op.configuration.environment-reconciliation`, `op.configuration.cover-limit`, `op.configuration.factor-value`, `op.configuration.nomenclature-reload`, `op.configuration.commission-rule`, `op.configuration.wording`, `op.configuration.permanent-control`	Configuration Work Procedures.md; note_incidental_config_diffs_dont_normalize.md; config_key_uniqueness_map.md
Non-consuming numbering preflight: rows, sequence, grant, synonym, principal, collisions `helper.numbering-preflight`	`configuration.skill.wiring-build`	`op.configuration.numbering`, `op.transfer.number-collision`	policy_no_generation.md; manual_policy_no_preconsumes_sequence_collision.md; seq_polno_office_script_superset.md
Report line → claim → evaluation → payment comparator `helper.health-line-compare`	`data.skill.health-report-review`	`op.health.report-review`, `op.health.report-correction`, `op.health.amount-reconciliation`, `op.health.payment-confirm-undo`, `op.health.import-call-repetition`	skill.md; hlt_invoice_aggregate_formulas.md; health_claim_pipeline_step14_overwrites_step13.md

C The seven operational-recovery rows — database-link backlog, broker channel, process halt, storage exhaustion, replica freeze, interrupted automation, business residue — are homed with support.investigator.transfers because their symptom usually arrives as a stuck transfer, so the infrastructure articles they draw on live in the transfers domain. Whether the first ten incident cases justify an operations investigator of their own — a seventh symptom domain beside the six of D11 — is decided on those cases (Stage Investigation § 2), not by this inventory.

Profile granularity

Reuse the existing symptom-domain investigators for transfer/MYR/cargo, pricing/billing, printing, access, health and master data. The listed variants require different evidence and procedure branches, not a permanent agent per operation.
When the symptom domain is known but no experience matches, use that existing investigator in explicit fresh-evidence mode. It must test current facts and return unknown rather than forcing a familiar precedent.
When no domain can yet be selected, use the read-only support.investigator bootstrap profile: triage cannot investigate, solution selection is not independent mechanism discovery, and the validator must remain independent. Reuse support/methodologies with no new owned memory domain, withhold guessed domain conclusions and return evidence plus candidate domain or unknown. The selected domain investigator receives the evidence and context when the domain becomes clear; this does not create an agent per new symptom.
Keep billing-specific procedures and evidence under the existing pricing investigator for now. Authoritative money/accounting boundaries and office-authorised UI actions need explicit method sections, but this inventory alone does not establish a separate billing profile or owner.
Configuration uses its existing domain planners and corresponding validators; methods are selected by requested delta. Overall proof belongs to configuration.integration.validator. No new normalizer per document format, agent per template or tool-package profile is needed.
Customer-specific source work reuses repository implementers, planner, test runner, validator and deployer. New shared Core behavior goes to assessment/offer/owner communication only. Programme-scale requests remain scoped referrals.
Actual source/binary helpers are retained under their calling methods. Evidence exists for the AISA channel CLIs, aisa-blob, person_policies_json.sql, the narrow car comparator and product-model validator. A query recipe, reference procedure or illustrative package manifest is not a published helper. Implement a new helper only after its bounded input/output and falsifying cases are established.

How a row becomes retained capability

P First reuse the existing method and check the current source, environment, lifecycle and requested meaning. If no method fits, investigate rather than creating a plausible new name. Retain the successful and failed discriminators with provenance. Only a demonstrated repeated mechanical step becomes an executable-helper candidate: exact inputs, deterministic or explicitly bounded behavior, expected outputs, unsupported cases and regression evidence. The domain owner keeps the method; a code-capable task can implement the helper without a new permanent agent. Publication, invocation and target authority remain separate.

P Three useful diagram examples are stuck transfer, partner-template selection, and blocking-bill cancellation. They demonstrate different method/ownership/effect boundaries. They are examples, not an asserted frequency ranking.

PreviousData & Manipulation — agents and methods NextOperational method evidence