Data & Manipulation module — typical cases

Proposed AISA v2 replay grounded in the archived SD-1717 investigation and resolution. The dated archive is not a current environment observation.

Customer request

The policy has not reached the other system.

Specific failure illustrated

TransferAlreadyStarted after a revert, although no new transfer reached PL/SQL.

Initial solution take

The symptom matches earlier stuck-transfer incidents, but an active transfer and a stale substatus need different treatment.

The state-flip procedure is only a candidate. Check the active request, note timeline and MIGR_LOG before choosing it.

Evidence to establish — investigation or the known skill’s preflight

1. The backend rejects equal policy substatus and requested substatus; PAS_POLICY_ID being non-null is not the guard.
2. The note timeline has the failed retransfer but no corresponding MIGR_LOG pipeline entry.
3. The existing INSIS policy remains active, so another target policy must not be created.

Return to solution take

Reset only the proved stale IPAL policy/annex state, then run the authorised transfer against the existing INSIS policy.

Reject this shortcut: A REQUESTED row is still active: refuse a blind state flip or second transfer.

Confirmation and application

1. Re-read the failed request, current substatus and active-transfer records; stop if a request is still running.
2. Bind the two state corrections to their before images and expected count of one each.
3. After the permitted correction, have the authorised actor sign and transfer once.

Verification

1. IPAL and INSIS retain the same intended mapping.
2. MIGR_LOG records TransferPolicy.END for the new attempt.
3. The policy opens and the required document prints.

Recovery

Before any committed correction, retain both old states. Reconcile a timed-out transfer before considering a compensating state change; do not transfer twice.

What is retained

Memory: The guard checks substatus equality; a non-null mapping alone does not explain the refusal.

Skill: Split the stuck-transfer procedure into active request, validation, stale-state and infrastructure branches.

Tool candidate: Package the note/MIGR_LOG/state comparison into one read-only diagnostic that identifies the branch and emits the bounded evidence set.

Next request: Fetch current transfer evidence before selecting the known branch; do not reset a still-running request.

Source basis: Case 1 / SD-1717: guard semantics, two state changes and verified retransfer — aisa-next/10 Architecture/40 Support/Case Studies.md

SD-1598 is the primary historic example: five periods, four register entries, an externally applied one-row repair, then database and print confirmation. Other MYR cases are separating counterexamples. This is a proposed v2 replay, not a new live execution.

Customer request

Period 5 exists in INSIS, but its section in the policy document is empty.

Specific failure illustrated

Period /5 is blank in a five-year policy document even though that period already exists in INSIS.

Initial solution take

The customer sees an empty fifth-year section. The archive contains missing-register, gutted-register, old-PDF and uncreated-renewal variants. The same printed symptom does not identify the repair.

Do not copy a previous INSERT or retransfer. First count and join the policy periods, register entries and document timestamps for this family.

Evidence to establish — investigation or the known skill’s preflight

1. All five INSIS POLICY records and the missing period's object, risk, installment and commission data exist.
2. C_CAR.MYR_POLICY contains /1–/4 but no row_id=5 for the current master; BI Publisher enumerates this register.
3. The earlier “Application updated” action refreshed policy data but did not populate the missing register entry.

Return to solution take

Restore the single missing /5 register entry; do not retransfer five already-existing policy periods.

Reject this shortcut: The last period remains absent although the master prints: the family is not verified.

Confirmation and application

1. Re-read the complete five-period family and validate the missing-row discriminator and approved values.
2. Send the guarded, expected-one-row INSERT packet to Bulstrad IT; preserve /1–/4 and the existing POLICY records.
3. Record the owner's execution receipt, re-read the register and regenerate the requested document.

What the archive actually records

The SD-1598 archive records Bulstrad IT applying the missing /5 INSERT at 10:27:05 on 27.04.2026. ServiceDesk confirmed the fifth period on print at 10:31:23, and the post-fix check found five matching register rows.

Verification

1. Five POLICY periods match five MYR_POLICY entries under the current master.
2. No existing period, cancellation history, dates or cover data was rewritten.
3. The regenerated fifth-year section contains its data instead of empty headings.

Recovery

Retain the inserted key and before-state absence. A compensation may remove only that new row after current dependency checks and H7; never delete or recreate the policy family.

What is retained

Memory: A blank period is not necessarily a failed transfer: absent register row, gutted row, old PDF and missing renewal policies need different remedies.

Skill: Select the repair only after the family inventory; preserve separate branches for INSERT, repopulate, reprint and recovery of uncreated renewals.

Tool candidate: Build one family-inventory tool returning policy/register membership, null fields, object links and document timing, plus assertions that distinguish those branches.

Next request: Run the retained family-inventory tool first and derive N from the new request, not SD-1598’s five periods. A missing register entry with all N policies complete permits the reviewed narrow path; zero/gutted rows, missing renewals or an older PDF choose another branch. Fresh authority and document verification still apply.

Source basis: SD-1598: absent /5 registry row and the distinct A–F failure variants — memory/reference/myr_policy_missing_last_row_pattern.md; DC-02: whole-family proof and documented MYR cases — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

This employee cannot sign in.

Specific failure illustrated

An account-creation request names an uncertain office code, but the person already owns the single permitted IPAL account.

Initial solution take

The existing account skill can perform the inventory without a full investigation. Its preflight must still confirm the office scope and the fate of the old account.

Use the account skill, but park the unresolved business choices before provisioning.

Evidence to establish — investigation or the known skill’s preflight

1. The request’s office code differed from the LDAP relationship and required customer confirmation.
2. The person already held the one permitted IPAL account, idle since 2023; a second linked account would violate uniqueness.
3. The approved outcome involved the agreed account treatment, four IC_USERS office memberships, two roles and enabled login.

Return to solution take

Confirm the office and treatment of the old account, then provision the agreed access without duplicating the person account.

Reject this shortcut: LDAP exists but the IPAL account does not: do not report access restored.

Confirmation and application

1. Ask the customer to confirm the office scope and whether the old account must be retained or replaced.
2. Apply the approved account/IC_USERS/role changes through the existing provisioning operation and enable login as authorised.
3. Ask the customer to log in in their own session and record the result without requesting credentials.

Verification

1. Exactly the intended account is linked to the person.
2. The confirmed offices and product roles are present, with no extra access.
3. The customer reports a successful login and the account/role checks agree.

Recovery

Reverse only the recorded provisioning delta after checking new use and dependencies; do not blindly reactivate an obsolete account.

What is retained

Memory: LDAP existence, IPAL account existence and permission to use a product are different facts.

Skill: Make office-code confirmation and the old-account decision explicit inputs to the account skill.

Tool candidate: Automate the LDAP → person → account → office → role inventory and one-account check; leave the business choices to the person.

Next request: Recheck account existence and branch membership before reuse; existing identity becomes repair rather than create.

Source basis: Case 5 / SD-1729: one existing account, uncertain office code and customer login proof — aisa-next/10 Architecture/40 Support/Case Studies.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Our new office needs to issue this product.

Specific failure illustrated

The intermediary is created but still cannot issue for the intended office or product.

Initial solution take

The intermediary is created but still cannot issue for the intended office or product.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. INSIS agent/office records and IPAL account/branch records are separate provisioning layers.
2. Product roles and office numbering prerequisites are not created merely by adding the account.
3. The INSIS or sequence step may belong to Bulstrad IT rather than the IPAL operator.

Return to solution take

Join the missing INSIS/office prerequisites with the narrow IPAL provisioning delta.

Reject this shortcut: A new office exists but has no usable sequence: no completed provisioning verdict.

Confirmation and application

1. Compare the approved agent, broker, office and product scope with both systems.
2. Assign the missing INSIS or numbering step to its owner and wait for attributable evidence.
3. Apply the remaining IC_USERS/product-role changes and request only the authorised issuance check.

Verification

1. The intermediary appears under the correct office.
2. The intended product is available and an unrelated role gains no access.
3. The numbering prerequisite is usable; any issued test number is recorded as an effect.

Recovery

Undo only the added rights/links that remain unused and in scope; allocated numbers and externally created records require their own recovery decision.

What is retained

Memory: An account row is not complete intermediary provisioning.

Skill: Keep actor ownership and numbering as dependencies in the provisioning checklist.

Tool candidate: Create a provisioning-diff tool that reports missing relationships and sequences without granting roles or consuming numbers.

Next request: Inspect all prerequisite layers and the effective product roles; reuse cannot authorise another employee.

Source basis: DC-04 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Extend the framework so we can issue a certificate.

Specific failure illustrated

The extended cargo framework still does not appear in the child-policy selector.

Initial solution take

The extended cargo framework still does not appear in the child-policy selector.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The desired new end date must be confirmed; 'synchronise' does not say whether to extend, duplicate or repoint.
2. INSIS, IPAL header/annex/cover/premium layers and the integration cache can hold different periods.
3. Updating some dates leaves the selector reading stale values or an outdated cache.

Return to solution take

Align the approved framework period across all required layers, with the INSIS owner's result included.

Reject this shortcut: Four date layers match but two and the cache remain stale: fail completion.

Confirmation and application

1. Capture the current framework/member/date matrix and the agreed end date.
2. Have each authorised owner apply its exact date delta, then refresh the relevant integration cache.
3. Re-run the selector and the separately authorised child-issuance check.

Verification

1. All required date relationships match the approved period.
2. The intended framework is offered in the selector window.
3. The child uses that framework; any number-consuming test is separately accounted for.

Recovery

Keep before dates and cache/version evidence; compensate only unchanged case-owned deltas, and account for children issued in the meantime.

What is retained

Memory: The selector depends on more than the framework header, and caches do not necessarily repair themselves.

Skill: Make the complete date matrix and selector predicate part of framework synchronization.

Tool candidate: Automate a six-layer-plus-cache comparison that identifies each stale layer and the exact missing predicate.

Next request: Read the current framework and approved dates, including the selector's lookahead; never choose the largest date as business authority.

Source basis: DC-05 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The framework exists, but we cannot select it.

Specific failure illustrated

The request names a fresh cargo proposal, but the existing mapped framework already has 36 certificates and the fresh proposal is a duplicate.

Initial solution take

The request names a fresh cargo proposal, but the existing mapped framework already has 36 certificates and the fresh proposal is a duplicate.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. In SD-1841, the existing mapped framework already supported 36 certificates; it was not a missing transfer.
2. The new proposal had PAS_POLICY_ID equal to its own source id and a different cover set: ICC_UNLOAD versus ICC_STR_RUBB.
3. The existing record needed an INSIS-to-IPAL metadata synchronization, including REPORT_POLICIES_PC; the duplicate’s fate required a separate customer choice.

Return to solution take

Synchronize the existing mapped framework across the seven declared layers; do not repoint or silently cancel the duplicate.

Reject this shortcut: A matching policy number points to a different INSIS master: refuse the shortcut.

Confirmation and application

1. Compare both IPAL candidates, their source/target identities and the existing framework’s 36 children.
2. Prepare the INSIS-to-IPAL update set for header, annex, covers, objects, premium-rate dimensions, policyholder and cache, each with its expected count.
3. Re-read all layers and the selector; ask the owner what to do with the duplicate. A new certificate test requires separate authority because it consumes a number.

What the archive actually records

The SD-1841 archive records synchronization of the existing framework, followed by a question about the duplicate. It does not establish that the duplicate was cancelled.

Verification

1. The existing mapped framework, not the self-sentinel duplicate, carries the reconciled values.
2. The header/annex/cover/object/rate/party/cache comparisons satisfy the approved scope.
3. The duplicate stays untouched pending its owner’s decision; the claimed child-issuance proof names whether a real authorised test ran.

Recovery

Preserve all old pointers and reconcile any issued child before reverting a link; no blanket deletion of duplicate-looking policies.

What is retained

Memory: Thirty-six existing children can prove which framework already works. A matching number and self-sentinel proposal must not override that identity evidence.

Skill: Separate migration-import, fresh-proposal and duplicate-master branches.

Tool candidate: Automate the framework identity/dimension inventory and return a candidate comparison for the owner's decision.

Next request: Re-run the discriminator and full diff before reusing the small repoint operation.

Source basis: Case 3 / SD-1841: 36 children, duplicate application, seven-layer synchronization and unresolved duplicate choice — aisa-next/10 Architecture/40 Support/Case Studies.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Please correct the amount on this cargo statement.

Specific failure illustrated

A cargo premium/certificate correction loops on 'application rejected' after an earlier transfer.

Initial solution take

A cargo premium/certificate correction loops on 'application rejected' after an earlier transfer.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Issued policy versus application is a business choice, not an interchangeable state.
2. Payments or a claim can block the normal correction path.
3. Currency, FX date and PAS_POLICY_ID determine which recalculation/retransfer procedure is valid.

Return to solution take

Use the correction path whose preconditions match the requested business state and currency.

Reject this shortcut: Customer wanted an application, not a revived policy: ask before any state transition.

Confirmation and application

1. Confirm proposal versus active-policy intent and read claims/payments/current transfer identity.
2. Run the approved recalculation or correction sequence, preserving any temporary state/date changes.
3. Restore the original state/date where required, refresh any new target identifiers and regenerate the exact document.

Verification

1. The requested premium or insured value reconciles in its stated currency.
2. All temporary dates/states are restored without an unintended second recalculation.
3. Both systems and the final document reflect the agreed outcome.

Recovery

Use the captured original values and actual landed identifiers; a retransfer that creates a new identity cannot be reversed using stale ids.

What is retained

Memory: An FX or premium procedure is valid only for its issue-state, payment and date basis.

Skill: Keep separate branches for direct correction, recalculation and retransfer; never infer 'restore active policy' from a request about an application.

Tool candidate: Automate the state/payment/claim/FX preflight and post-operation identity refresh, leaving the authorised effect to its registered operation.

Next request: Check paid/claimed state, currency and current procedure behaviour before using the past sequence.

Source basis: DC-07 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The owner shown on the policy is wrong.

Specific failure illustrated

The print shows the wrong party, or a participant change leaves two active owners.

Initial solution take

The print shows the wrong party, or a participant change leaves two active owners.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. POLCLM_PARTICIPANTS and INSIS POLICY.CLIENT_ID/O_OBJECT_OWNERS/O_OBJECT_CREDITED are different consuming relationships.
2. A second active owner can leave 200% ownership even if one name prints correctly.
3. An IPAL-only party with no SOURCE_ID cannot be treated as already propagated to INSIS.

Return to solution take

Correct the approved participant relationship and every required propagation edge, without changing unrelated roles.

Reject this shortcut: One owner prints correctly but a second active owner leaves 200% ownership: fail.

Confirmation and application

1. Compare participant roles, active ownership shares, bank links and source mappings.
2. Prepare the smallest authorised annex or row delta for the agreed survivor/party.
3. Re-read both systems and regenerate the policy/debit note.

Verification

1. The intended policyholder, owner and bank appear where required.
2. Active ownership shares have the expected total, with no obsolete active link.
3. The policy and debit note agree with the approved parties.

Recovery

Restore captured role/link values only if current ownership and subsequent annexes still permit it; external registrations need separate handling.

What is retained

Memory: A correct printed name alone does not establish participant consistency.

Skill: Verify roles and ownership totals across both systems after a party change.

Tool candidate: Package the participant/ownership/bank comparison as a deterministic diff with explicit missing source mappings.

Next request: Rebuild the participant graph from current evidence; do not copy a previous person's ids.

Source basis: DC-08 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Change the payment plan to four installments.

Specific failure illustrated

INSIS installments change but IPAL still shows the old schedule or due dates.

Initial solution take

INSIS installments change but IPAL still shows the old schedule or due dates.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. IPAL POL_PPLAN is an independent splitter, not a projection of INSIS.
2. CHANGE_INSTALLMENTS writes the INSIS side only.
3. PREM_INST/PREM_INST_FRACT contain multiple date fields, and paid installments cannot be treated as editable placeholders.

Return to solution take

Change the agreed unpaid schedule on every required side and compare the full date set.

Reject this shortcut: INSIS changed but IPAL still shows the old plan: no completion.

Confirmation and application

1. Inventory installments, paid status, residual annexes and all consuming date columns.
2. Apply the authorised splitter/procedure and any separately required IPAL counterpart delta.
3. Reconcile totals and dates, then reopen the payment-plan screen.

Verification

1. Installment amounts sum to the premium in the correct currency.
2. All named due/fraction dates align with the agreed plan.
3. Paid items remain unchanged and the operator sees the new schedule.

Recovery

Retain the before schedule; do not overwrite payments or annexes created after the plan. A compensated financial effect needs its own authority.

What is retained

Memory: Running the INSIS splitter does not update the IPAL schedule.

Skill: Require a two-system date and amount matrix around installment operations.

Tool candidate: Automate the independent-schedule comparison, including paid-item exclusions and the complete date-field inventory.

Next request: Recompute the live payment state and scope; a prior four-installment example is not a ready row set.

Source basis: DC-09 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Why did this premium change?

Specific failure illustrated

A reported 'missing discount' is diagnosed from a result field instead of the factors sent for rating.

Initial solution take

A reported 'missing discount' is diagnosed from a result field instead of the factors sent for rating.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. POL_PREM_RATE stores a rating result; it is not the original ABACUS input factor.
2. The fed factor, cover definition and recorded loading/discount must be reconstructed separately.
3. A correct quote may require an explanation rather than a data change.

Return to solution take

Replay the actual rating input and explain the result, or isolate the precise incorrect factor/rule.

Reject this shortcut: Treating POL_PREM_RATE as the fed factor yields the wrong cause: reject the answer.

Confirmation and application

1. Read the input factor set and selected template/effective version.
2. Reproduce the quote and compare per-cover base premium, loading/discount and recorded totals.
3. Send the supported explanation; route any real rule defect to its owning change path.

Verification

1. The replay uses the same factors and effective rating version.
2. Premium components reconcile with the recorded total and currency.
3. The explanation names why the discount/loading did or did not apply.

Recovery

Correct the explanation if its assumptions fail; do not roll back a correctly rated policy to match a mistaken expectation.

What is retained

Memory: Applied result and fed factor are different evidence.

Skill: Require the actual rating request before diagnosing a discount from POL_PREM_RATE.

Tool candidate: Build a request-versus-result comparator that preserves per-cover arithmetic and flags a missing or transformed factor.

Next request: Recheck current tariff/version and inputs before relying on the previous explanation.

Source basis: DC-10 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Correct the vehicle registration on this policy.

Specific failure illustrated

A vehicle correction changes the latest row but the policy still consumes an earlier wrong version.

Initial solution take

A vehicle correction changes the latest row but the policy still consumes an earlier wrong version.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. OBJ_CAR versions are connected through SR_OBJECTS and the INSIS object mapping.
2. Plate-based matching can graft a different vehicle; plate equality is not identity.
3. An earlier consumed snapshot may retain the wrong VIN, registration or type.

Return to solution take

Correct the agreed object chain or use the valid annex path, not just the most recent row.

Reject this shortcut: Only the latest vehicle row is changed while an earlier consumed version remains wrong: fail.

Confirmation and application

1. Resolve the complete vehicle version chain and compare each consumed IPAL snapshot with INSIS O_CAR.
2. Prepare the scoped correction using the authoritative mapped vehicle identity and exclude collisions.
3. Re-run the chain-aware comparison and check the affected document/registry outcome.

Verification

1. The relevant COMPARE_IPAL_INSIS_CAR comparison returns no differences.
2. Every consumed version has the intended value and mapping.
3. The requested print or separately owned registry result is proved.

Recovery

Keep before images for each touched version; never overwrite a later ownership/object change during reversal.

What is retained

Memory: The object consumed by an annex can differ from the newest vehicle row.

Skill: Always traverse the mapped version chain and discriminate a plate collision before applying a correction.

Tool candidate: Wrap the chain traversal and field comparison in one reusable read-only vehicle diagnostic.

Next request: Enumerate the current chain again; reusing one row id is never the skill.

Source basis: DC-11 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The policy was cancelled by mistake.

Specific failure illustrated

A mistaken cancellation closes a policy or its downstream multi-year periods.

Initial solution take

A mistaken cancellation closes a policy or its downstream multi-year periods.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Return-to-application followed by rejection can leave IPAL CLOSED/CANCELLED and INSIS negative states.
2. The multi-year variant may cancel downstream periods, not just the selected row.
3. Reviving an INSIS application can be an external-owner action.

Return to solution take

Restore the agreed application or active-policy state using the matching recovery path.

Reject this shortcut: External owner says done without the required state/readback: remain waiting for verification.

Confirmation and application

1. Confirm the intended state, regulatory ties, payments and affected family.
2. Have the authorised owner apply its scoped restoration and record what actually changed.
3. Re-read the full family and exercise the required customer action or print.

Verification

1. Both systems show the intended mapped business state.
2. Required downstream periods are reconciled rather than silently abandoned.
3. The customer outcome is demonstrated, not inferred from an external 'done' message.

Recovery

Capture the pre-restoration state and new dependencies; any compensation must account for payments, registration and subsequently active periods.

What is retained

Memory: Application recovery and active-policy revival are different procedures.

Skill: Use a restoration decision table keyed by regulatory tie, payment, intended state and family impact.

Tool candidate: Automate the cancellation-footprint and recovery-precondition comparison before a person selects the authorised path.

Next request: Recheck external registration/payment constraints and the requested end state before proposing a known path.

Source basis: DC-12 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The two systems show different policy periods.

Specific failure illustrated

A cancellation or period correction lands on one side and leaves the other system or printed hierarchy stale.

Initial solution take

A cancellation or period correction lands on one side and leaves the other system or printed hierarchy stale.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Cancellation can fail between the INSIS and IPAL phases in either direction.
2. ConvertApplication does not necessarily refresh INSR_BEGIN/END.
3. A header-only period correction can leave annex, cover and premium date layers unchanged.

Return to solution take

Classify the direction of drift, then reconcile the exact state and date layers that remain wrong.

Reject this shortcut: One-sided period fix leaves the consuming print hierarchy stale: fail.

Confirmation and application

1. Compare mapped states and every affected period layer against the owner's intended state.
2. Assign each system's correction to its authorised owner, using current before-state predicates.
3. Re-read the complete hierarchy and regenerate the document.

Verification

1. The policy states agree through the declared mapping, not literal code equality.
2. All required begin/end relationships are consistent.
3. The printed period uses the corrected hierarchy.

Recovery

Compensate only landed steps with current-state checks; a partial cross-system correction is not a shared database transaction.

What is retained

Memory: The direction and failed propagation edge determine the repair.

Skill: Keep separate forward/reverse state-desynchronisation and date-propagation branches.

Tool candidate: Build a state/date taxonomy query that returns the divergent layer and its consuming surface.

Next request: Determine which side changed first from current evidence; never pick a system solely because it was authoritative last time.

Source basis: DC-13 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The policy exists, but the portal shows it as incomplete.

Specific failure illustrated

A 'hollow policy' remains failed in IPAL after a registry timeout, while a real policy exists in INSIS.

Initial solution take

A 'hollow policy' remains failed in IPAL after a registry timeout, while a real policy exists in INSIS.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. GFIRM can time out inside conversion even when INSIS created the policy.
2. IPAL may reference an orphan or sibling instead of the real active policy.
3. The header, period hierarchy and SRD_INTEGR caches all participate in the displayed result.

Return to solution take

Reconcile IPAL to the proved INSIS master across all three layers, without another blind conversion.

Reject this shortcut: The Jira mirror and notification count as two clean uses, or only the header is fixed: reject.

Confirmation and application

1. Deduplicate the HelpDesk/Jira/mail aliases and identify the real target policy from effect evidence.
2. Prepare the exact header, annex/object/cover and cache delta for that master.
3. Apply only authorised outstanding steps and verify search plus registry state.

Verification

1. IPAL search returns the intended policy number and active state.
2. All three layers reference the same proved master.
3. Registry evidence supports the promised business status.

Recovery

Preserve old mappings and reconcile any live policy before changing them again; never replay an ambiguous conversion blindly.

What is retained

Memory: A timeout is not proof that no policy was created.

Skill: Use one canonical request and a three-layer reconciliation packet.

Tool candidate: Automate target-policy candidate discovery and the header/hierarchy/cache diff; do not count channel mirrors as independent learning.

Next request: Retrieve through the customer's Bulgarian phrase and trigger, then find the live authoritative sibling again.

Source basis: DC-14 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The registry is rejecting the policy.

Specific failure illustrated

A green-card/registry request is rejected despite a policy that appears valid locally.

Initial solution take

A green-card/registry request is rejected despite a policy that appears valid locally.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. C003-GC01 can identify a one-day period mismatch; C007-PL-VH18 denotes a different duplicate-policy problem.
2. Local policy dates do not establish current registry validity.
3. A blank may have been consumed by another channel.

Return to solution take

Decode the actual response and give the matching explanation or precisely scoped owner instruction.

Reject this shortcut: A stale response is reused as current cover/validity proof: reject.

Confirmation and application

1. Read the current INTRF_EISOUKR_LOG response and related policy/green-card/sticker periods.
2. Discriminate duplicate cover, period mismatch and blank ownership before proposing any correction.
3. Re-query the promised registry/status outcome after the authorised action, or send the supported explanation.

Verification

1. The response code is interpreted for its actual operation.
2. Dates and blank ownership agree with current registry evidence.
3. The promised issue/status result is demonstrated if an operational repair was requested.

Recovery

Correct an unsupported explanation promptly; any date/registration compensation must account for already-published cover.

What is retained

Memory: Different registry codes with similar UI wording require different action.

Skill: Keep a response-code decision table with operation, date and ownership checks.

Tool candidate: Automate code decoding and the scoped current-status comparison, preserving observation time.

Next request: Query current status and recheck code meaning; do not infer today's insurance state from an older answer.

Source basis: DC-15 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The commission was not transferred correctly.

Specific failure illustrated

The policy has a missing or wrong commission even though the intermediary exists.

Initial solution take

The policy has a missing or wrong commission even though the intermediary exists.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. IPAL AGENT ATTRC2/3, POLICY_COMMISSIONS and GEN_AGENT_COMMISSIONS carry different parts of the result.
2. INS_BOF.sPolComm can update only in one direction, leaving an old value.
3. A missing CFG_AGENT_GEN_COMMISSION_RULES rate is a rule problem rather than a copied-percentage fix.

Return to solution take

Distinguish incorrect policy data, a missing effective rule and a propagation defect.

Reject this shortcut: A copied percentage fixes one row but violates the effective rule: fail.

Confirmation and application

1. Reconstruct the effective agent/product rule and the actual propagated attributes.
2. Prepare the authorised policy-specific correction or assign the missing rule to Configuration/its owner.
3. Recompute and compare the affected commission/self-retention amounts.

Verification

1. The effective rule explains the selected percentage.
2. Policy and commission rows contain the approved result in its currency.
3. Unrelated effective dates, agents and policies remain unchanged.

Recovery

Preserve original rule/data values and subsequent accounting effects; do not reverse a later valid commission with an old percentage.

What is retained

Memory: A copied percentage can conceal a missing rule or an only-up propagation predicate.

Skill: Classify data, rule and code causes before choosing the commission remedy.

Tool candidate: Automate the effective-rule/attribute/commission comparison and report the exact failing propagation edge.

Next request: Recheck current agent contract/rate and policy state before using the formula.

Source basis: DC-16 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The printed document has a missing value.

Specific failure illustrated

The requested document is wrong even though the template itself can render correctly.

Initial solution take

The requested document is wrong even though the template itself can render correctly.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Invocation and exact parameters must be proved before blaming template configuration.
2. BI Publisher reads INSIS data; a missing limit/rate/register value can produce a plausible but incomplete document.
3. A persisted PDF can predate the data it should show.

Return to solution take

Fix the proved data or document-timing gap, and regenerate the exact document.

Reject this shortcut: The template is blamed while required source data is absent: reject the route.

Confirmation and application

1. Find the invocation, requested document name, parameter set and target template version.
2. Compare the consuming INSIS rows and currency/register timing with the document's requirements.
3. Apply the scoped data repair or simply regenerate when all required data is already correct.

Verification

1. The exact requested document is invoked with the right parameters.
2. Required limits, office, rates and period data appear in the new output.
3. No unrelated document is emitted by an over-broad selector.

Recovery

Keep the original document/evidence; correct or regenerate the output and compensate only an actual data effect, not an imagined template change.

What is retained

Memory: A correct template with absent data and an old stored PDF are separate failure branches.

Skill: Start print diagnostics with invocation, input data and timestamps.

Tool candidate: Build an invocation/data-readiness/document-age probe that chooses repair versus reprint without repeated manual queries.

Next request: Check invocation and current data before considering a template fix.

Source basis: DC-17 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Add this missing vehicle model to the list.

Specific failure illustrated

A requested catalogue value or blank exists in one place but is missing from the consuming selection.

Initial solution take

A requested catalogue value or blank exists in one place but is missing from the consuming selection.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Business-key uniqueness must be checked before an INSERT is prepared.
2. PR_PRICING_FACTOR_VALUES and dependent values can need different mappings and labels.
3. A visible label alone does not establish usable pricing/transfer or blank lifecycle.

Return to solution take

Add only the missing approved business keys and their required dependencies.

Reject this shortcut: The label exists but the dependent value is invisible or wrong for another product: fail.

Confirmation and application

1. Compare existing values, dependent keys, labels and external nomenclature codes.
2. Use the applicable BSO/car skill or hand product-factor semantics to Configuration.
3. Re-read the dependent selection and run the authorised consuming check.

Verification

1. The requested value appears under the correct dependency.
2. No duplicate business key or reused blank is introduced.
3. Pricing/transfer or the permitted issuance check consumes the intended value.

Recovery

Remove only unused inserted values after dependency checks; used blanks and historical references must be preserved.

What is retained

Memory: A label, a selectable value and a valid downstream code are different requirements.

Skill: Make dependency and external-code checks mandatory in the existing add-value skill.

Tool candidate: Automate business-key and dependency diffs so additions are prepared from missing keys rather than repeated free-form SQL.

Next request: Search by business key and context first; an already-present value may need visibility repair, not insertion.

Source basis: DC-18 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Temporarily allow this blocked policy through.

Specific failure illustrated

An operator needs one blocked policy through a validation rule, then the normal rule restored.

Initial solution take

An operator needs one blocked policy through a validation rule, then the normal rule restored.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The blocking rule can be on IPAL, ABACUS or both.
2. A row changed 'for one policy' can affect every policy that consumes it.
3. Restoration is a required obligation even if the customer disappears or the deadline expires.

Return to solution take

Approve the complete relax/action/restore chain before changing the first value.

Reject this shortcut: Deadline expires or the customer disappears: restoration remains a live obligation.

Confirmation and application

1. Capture the actual rule, original value, twin rule and real audience, with a due time or action trigger.
2. Apply the authorised temporary delta and wait for the designated operator's action report.
3. Verify that action, then obtain H7 and restore/check the original baseline.

Verification

1. The intended action succeeds under the agreed exception.
2. The original value and applicable twin are restored.
3. The rule's other consumers are not left with a permanent relaxation.

Recovery

Compare current state with the value this case wrote before restoring; an unrelated later edit requires reconciliation instead of overwrite.

What is retained

Memory: A successful transfer does not complete a temporary-exception case until restoration is proved.

Skill: Persist restoration before relaxation and keep the repeated trigger linked to a lasting correction.

Tool candidate: Automate rule/twin/consumer inventory and due-obligation checks; a timer can queue review but cannot authorise the write.

Next request: Check earlier exceptions and their permanent-fix status; do not silently accumulate another indefinite relaxation.

Source basis: DC-19 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

There are two records for the same company.

Specific failure illustrated

A duplicate company appears in the picker after its INSIS counterpart was already removed.

Initial solution take

A duplicate company appears in the picker after its INSIS counterpart was already removed.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. In SD-1757, the obsolete registration value had one extra digit; that similarity alone was not authority to delete it.
2. The footprint scan covered 18 FK children and found no policies, participants or accounts on the obsolete IPAL record.
3. The captured pas_ccust_seek query returned both records, while HIST_P_PEOPLE confirmed the obsolete INSIS counterpart had been deleted.

Return to solution take

Delete the five proved orphan records in one asserted local transaction, preserving the agreed surviving customer.

Reject this shortcut: Zero local footprint or a changed dependent count invalidates the old packet.

Confirmation and application

1. Re-read the survivor, the obsolete record’s 18-child footprint and the same consuming search before approving the packet.
2. Delete the obsolete mapping, C_ADDRESSES, SR_ADDRESSES, C_COMPANY and C_CUST records in the reviewed order; require one row per statement or roll back the local transaction.
3. Replay pas_ccust_seek in the same transaction before commit, then check the actual picker after commit.

What the archive actually records

The SD-1757 archive records the five-row orphan cleanup and replay of the captured search with totalCount changing from 2 to 1. The current-case preflight must reproduce the footprint before reuse.

Verification

1. Every one of the five statements affects exactly its expected one row.
2. The consuming search changes from two candidates to the one intended survivor.
3. No policy, participant, account or dangling reference is removed or left behind; the picker shows the survivor.

Recovery

Use retained before records and current dependencies to review compensation; a zero-footprint candidate never justifies a broad customer merge.

What is retained

Memory: One logical orphan cleanup can span five records. Its safety comes from the footprint, exact per-statement counts and consuming-query replay, not a generic “duplicate” label.

Skill: Put footprint-first and consuming-query proof before every duplicate-customer action.

Tool candidate: Package dependency counts and the exact seek query into a comparison report that refuses an unexplained footprint change.

Next request: Requery the footprint; an INSIS merge is evidence, not an instruction to mirror deletion blindly.

Source basis: Case 2 / SD-1757: 18 FK checks, five asserted deletes and pas_ccust_seek 2-to-1 proof — aisa-next/10 Architecture/40 Support/Case Studies.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Please complete the waiting transfers.

Specific failure illustrated

A backlog contains routine signatures mixed with real transfer exceptions.

Initial solution take

A backlog contains routine signatures mixed with real transfer exceptions.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Some items only need the second signature; others have an active transfer or validation failure.
2. Already-completed target effects must be reconciled before retry.
3. One successful item cannot prove the state of the entire backlog.

Return to solution take

Classify every item, dispatch routine operator actions, and separate the exceptions into their own repair paths.

Reject this shortcut: One success is used to close all 45 items: reject.

Confirmation and application

1. Take a current per-item inventory of source state, request status and target-policy evidence.
2. Assign only the routine, authorised UI actions; record validation/outage exceptions with owners.
3. Join each item's effect receipt and target proof before marking the batch result.

Verification

1. Every declared item has its own classification and outcome.
2. Completed items are not transferred again.
3. No unresolved item is hidden behind a green batch summary.

Recovery

Stop the remaining queue when new evidence invalidates its classification; reconcile already-landed actions individually.

What is retained

Memory: A batch is an inventory of obligations, not one success flag.

Skill: Keep routine signatures, active requests, validation failures and outage residue separate.

Tool candidate: Automate the backlog classifier and per-item reconciliation matrix; count learning by independent request, not by each row.

Next request: Retrieve the classifier and recheck every current item, rather than applying one batch state flip.

Source basis: DC-21 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

The recovery is grounded in SD-1675 and its older SD-517 precedent. The client-performed action and fresh verification are part of the proposed replay.

Customer request

The transferred policy has an internal identifier instead of its proper policy number.

Specific failure illustrated

A transferred policy received a neighbouring policy's internal identifier as its displayed number.

Initial solution take

The number/identity equality skill can test the known sentinel mechanism. The earlier claim that the defect was fixed must be checked against this recurrence.

If the wrong number is another policy’s id, use the checked own-identifier instruction; do not change database mappings from memory.

Evidence to establish — investigation or the known skill’s preflight

1. The numbering sentinel regenerates only when POLICY_NO equals that policy's own SR_POLICY_ID.
2. A different policy's identifier in that field does not trigger the intended generation path.
3. An older 'fixed' article is contradicted by recurrence and must not be treated as current proof.

Return to solution take

Use the checked operator procedure with this policy's own identifier and verify the generated number.

Reject this shortcut: The old article is found but its current precondition is false: investigate instead.

Confirmation and application

1. Compare the displayed number, own identity and transfer state without conflating equal-looking identifiers.
2. Send the scoped return/set-own-sentinel/retransfer instruction to the authorised customer operator.
3. Record the customer's action and re-read the generated number, target mapping and resulting policy.

Verification

1. The displayed number is a valid policy number rather than another case's internal id.
2. The policy retains the intended mapping and business state.
3. The customer's outcome is checked before closure; the instruction alone is not the repair.

Recovery

Keep the prior identity/number evidence; reconcile an already-generated target number before any repeat of the procedure.

What is retained

Memory: A precedent's 'fixed in software' claim can become stale even when its recovery procedure still works.

Skill: Re-check the sentinel equality and record customer-performed actions explicitly.

Tool candidate: Build an identity/number/transfer comparison that supplies safe equality facets and refuses a neighbouring-id shortcut.

Next request: Start with the reviewed precedent, then repeat the smallest necessary staleness check.

Source basis: Case 6 / SD-1675: own-identifier sentinel, customer action and stale earlier fix claim — aisa-next/10 Architecture/40 Support/Case Studies.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The automated change stopped before it finished.

Specific failure illustrated

An earlier Beth automation stopped after some effects had already landed.

Initial solution take

An earlier Beth automation stopped after some effects had already landed.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Beth operation batches can contain successful and missing downstream steps.
2. A repeated whole batch can duplicate a document, registration or annex.
3. The promised result may depend on a step outside the automation's success message.

Return to solution take

Reconcile what landed and repair only the missing obligation.

Reject this shortcut: Re-running the whole batch duplicates an existing document or registration: reject.

Confirmation and application

1. Read the Beth operation batch and compare its receipts with current target records.
2. Prepare the authorised missing-step action with a new bounded effect identity.
3. Check the promised annex, print or commission outcome and preserve the original successful effects.

Verification

1. Every required step is either evidenced or explicitly outstanding.
2. Existing documents/registrations are not duplicated.
3. The original promised customer result exists after the missing step.

Recovery

Compensate only the newly applied missing step if needed; retain the earlier automation's journal and avoid a blanket undo.

What is retained

Memory: Automation completion text is weaker evidence than individual landed effects.

Skill: Use partial-effect reconciliation before rerunning an automation.

Tool candidate: Automate a batch-to-target receipt comparison and emit only the unresolved action set.

Next request: Reconcile the actual operation log before selecting a recovery step.

Source basis: DC-23 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The outage is over, but these policies are still stuck.

Specific failure illustrated

Infrastructure is healthy again but some policies or workflows remain half-written.

Initial solution take

Infrastructure is healthy again but some policies or workflows remain half-written.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. A healthy service probe proves availability, not consistency of the interrupted work.
2. An outage can leave different items before dispatch, after a target effect or before checkpointing.
3. Retrying all affected items can duplicate those that completed before the failure.

Return to solution take

Classify and reconcile the affected work after the infrastructure owner confirms recovery.

Reject this shortcut: A green service probe closes half-written policies without reconciliation: reject.

Confirmation and application

1. Confirm dependency health through its owner and inventory each interrupted item's last durable evidence.
2. Choose the existing repair path for each proved partial effect; keep unknown outcomes blocked for reconciliation.
3. Verify policy/workflow state and the customer surface for every item.

Verification

1. Every declared item has reconciled source and target evidence.
2. Unknown or partial effects remain visible instead of being counted as success.
3. The promised customer actions work after service recovery.

Recovery

Stop further dispatch if health or the item baseline changes; compensate only identified landed effects with their own permission.

What is retained

Memory: Service recovery and business-work recovery are separate outcomes.

Skill: Add explicit before-dispatch, after-effect and before-checkpoint outage branches.

Tool candidate: Automate a journal-versus-target recovery inventory, keeping uncertain calls distinct from safe retries.

Next request: Check current incident state and reconcile each item before applying the recovery skill.

Source basis: DC-24 evidence, mechanism and delivery census — aisa-next/10 Architecture/40 Support/Typical Cases.md