AISA v2.0 / Technical documentation / case-content.json
case-content.json
JSON · 1863 lines · 138,894 bytes · wiki path 10 Architecture/ui/case-content.json · download the raw file · cited from Configuration work procedures · Frequent AISA operations · Case journeys — the 68 real cases · Case protocol
Same folder: agent-catalog.json · agent_catalog.py · agent_map_svg.py · build_agent_map.py · build_case_content_docs.py · build_case_journeys.py · build_case_traces.py · build_operations_examples.py · case-journeys.json · case-runtime-traces.json · case-ui-specs.json · case_content.py · case_ui_model.py · frequent-operations.json · memory-capabilities.json · validate_agent_map.py · validate_case_content.py
{
"schema_version": 1,
"notice": "Evidence-grounded representative scenarios. Source facts and historic outcomes are distinguished from proposed AISA v2 execution, success checks and tool candidates. No live execution is claimed.",
"cases": {
"DC-01": {
"failure": "TransferAlreadyStarted after a revert, although no new transfer reached PL/SQL.",
"findings": [
"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.",
"The existing INSIS policy remains active, so another target policy must not be created."
],
"solution": "Reset only the proved stale IPAL policy/annex state, then run the authorised transfer against the existing INSIS policy.",
"steps": [
"Re-read the failed request, current substatus and active-transfer records; stop if a request is still running.",
"Bind the two state corrections to their before images and expected count of one each.",
"After the permitted correction, have the authorised actor sign and transfer once."
],
"checks": [
"IPAL and INSIS retain the same intended mapping.",
"MIGR_LOG records TransferPolicy.END for the new attempt.",
"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.",
"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": "Package the note/MIGR_LOG/state comparison into one read-only diagnostic that identifies the branch and emits the bounded evidence set.",
"sources": [
{
"path": "aisa-next/10 Architecture/40 Support/Case Studies.md",
"label": "Case 1 / SD-1717: guard semantics, two state changes and verified retransfer"
}
],
"basis": "Proposed AISA v2 replay grounded in the archived SD-1717 investigation and resolution. The dated archive is not a current environment observation.",
"take": "The symptom matches earlier stuck-transfer incidents, but an active transfer and a stale substatus need different treatment.",
"take_decision": "The state-flip procedure is only a candidate. Check the active request, note timeline and MIGR_LOG before choosing it."
},
"DC-02": {
"failure": "Period /5 is blank in a five-year policy document even though that period already exists in INSIS.",
"findings": [
"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.",
"The earlier “Application updated” action refreshed policy data but did not populate the missing register entry."
],
"solution": "Restore the single missing /5 register entry; do not retransfer five already-existing policy periods.",
"steps": [
"Re-read the complete five-period family and validate the missing-row discriminator and approved values.",
"Send the guarded, expected-one-row INSERT packet to Bulstrad IT; preserve /1–/4 and the existing POLICY records.",
"Record the owner's execution receipt, re-read the register and regenerate the requested document."
],
"checks": [
"Five POLICY periods match five MYR_POLICY entries under the current master.",
"No existing period, cancellation history, dates or cover data was rewritten.",
"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.",
"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": "Build one family-inventory tool returning policy/register membership, null fields, object links and document timing, plus assertions that distinguish those branches.",
"sources": [
{
"path": "memory/reference/myr_policy_missing_last_row_pattern.md",
"label": "SD-1598: absent /5 registry row and the distinct A–F failure variants"
},
{
"path": "aisa-next/10 Architecture/40 Support/Typical Cases.md",
"label": "DC-02: whole-family proof and documented MYR cases"
}
],
"basis": "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.",
"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.",
"take_decision": "Do not copy a previous INSERT or retransfer. First count and join the policy periods, register entries and document timestamps for this family.",
"take_steps": [
"Read all five policy periods and their current source/target identities.",
"Compare register membership and non-null fields, then compare the PDF timestamp with register population.",
"Choose repair only after distinguishing missing register data from missing policies or an old document."
],
"archive_result": "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.",
"similar": "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.",
"public_result": "All five policy years are represented in the regenerated document. The missing fifth-year entry was restored without retransferring the existing policy family.",
"packet_details": [
"Existing master and /5 policy identities are resolved through case handles; no new POLICY record is created.",
"Only the missing current-master register key with row_id=5 is eligible; the expected insertion count is exactly one.",
"Amounts and dates must come from the approved period data. The historic SD-1598 values and ratios are not a pricing formula for the next case."
]
},
"DC-03": {
"failure": "An account-creation request names an uncertain office code, but the person already owns the single permitted IPAL account.",
"findings": [
"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.",
"The approved outcome involved the agreed account treatment, four IC_USERS office memberships, two roles and enabled login."
],
"solution": "Confirm the office and treatment of the old account, then provision the agreed access without duplicating the person account.",
"steps": [
"Ask the customer to confirm the office scope and whether the old account must be retained or replaced.",
"Apply the approved account/IC_USERS/role changes through the existing provisioning operation and enable login as authorised.",
"Ask the customer to log in in their own session and record the result without requesting credentials."
],
"checks": [
"Exactly the intended account is linked to the person.",
"The confirmed offices and product roles are present, with no extra access.",
"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.",
"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": "Automate the LDAP → person → account → office → role inventory and one-account check; leave the business choices to the person.",
"initial_route": "ready",
"sources": [
{
"path": "aisa-next/10 Architecture/40 Support/Case Studies.md",
"label": "Case 5 / SD-1729: one existing account, uncertain office code and customer login proof"
}
],
"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.",
"take_decision": "Use the account skill, but park the unresolved business choices before provisioning.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-04": {
"failure": "The intermediary is created but still cannot issue for the intended office or product.",
"findings": [
"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.",
"The INSIS or sequence step may belong to Bulstrad IT rather than the IPAL operator."
],
"solution": "Join the missing INSIS/office prerequisites with the narrow IPAL provisioning delta.",
"steps": [
"Compare the approved agent, broker, office and product scope with both systems.",
"Assign the missing INSIS or numbering step to its owner and wait for attributable evidence.",
"Apply the remaining IC_USERS/product-role changes and request only the authorised issuance check."
],
"checks": [
"The intermediary appears under the correct office.",
"The intended product is available and an unrelated role gains no access.",
"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.",
"memory": "An account row is not complete intermediary provisioning.",
"skill": "Keep actor ownership and numbering as dependencies in the provisioning checklist.",
"tool": "Create a provisioning-diff tool that reports missing relationships and sequences without granting roles or consuming numbers.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-05": {
"failure": "The extended cargo framework still does not appear in the child-policy selector.",
"findings": [
"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.",
"Updating some dates leaves the selector reading stale values or an outdated cache."
],
"solution": "Align the approved framework period across all required layers, with the INSIS owner's result included.",
"steps": [
"Capture the current framework/member/date matrix and the agreed end date.",
"Have each authorised owner apply its exact date delta, then refresh the relevant integration cache.",
"Re-run the selector and the separately authorised child-issuance check."
],
"checks": [
"All required date relationships match the approved period.",
"The intended framework is offered in the selector window.",
"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.",
"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": "Automate a six-layer-plus-cache comparison that identifies each stale layer and the exact missing predicate.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-06": {
"failure": "The request names a fresh cargo proposal, but the existing mapped framework already has 36 certificates and the fresh proposal is a duplicate.",
"findings": [
"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.",
"The existing record needed an INSIS-to-IPAL metadata synchronization, including REPORT_POLICIES_PC; the duplicate’s fate required a separate customer choice."
],
"solution": "Synchronize the existing mapped framework across the seven declared layers; do not repoint or silently cancel the duplicate.",
"steps": [
"Compare both IPAL candidates, their source/target identities and the existing framework’s 36 children.",
"Prepare the INSIS-to-IPAL update set for header, annex, covers, objects, premium-rate dimensions, policyholder and cache, each with its expected count.",
"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."
],
"checks": [
"The existing mapped framework, not the self-sentinel duplicate, carries the reconciled values.",
"The header/annex/cover/object/rate/party/cache comparisons satisfy the approved scope.",
"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.",
"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": "Automate the framework identity/dimension inventory and return a candidate comparison for the owner's decision.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.",
"sources": [
{
"path": "aisa-next/10 Architecture/40 Support/Case Studies.md",
"label": "Case 3 / SD-1841: 36 children, duplicate application, seven-layer synchronization and unresolved duplicate choice"
}
],
"archive_result": "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."
},
"DC-07": {
"failure": "A cargo premium/certificate correction loops on 'application rejected' after an earlier transfer.",
"findings": [
"Issued policy versus application is a business choice, not an interchangeable state.",
"Payments or a claim can block the normal correction path.",
"Currency, FX date and PAS_POLICY_ID determine which recalculation/retransfer procedure is valid."
],
"solution": "Use the correction path whose preconditions match the requested business state and currency.",
"steps": [
"Confirm proposal versus active-policy intent and read claims/payments/current transfer identity.",
"Run the approved recalculation or correction sequence, preserving any temporary state/date changes.",
"Restore the original state/date where required, refresh any new target identifiers and regenerate the exact document."
],
"checks": [
"The requested premium or insured value reconciles in its stated currency.",
"All temporary dates/states are restored without an unintended second recalculation.",
"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.",
"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": "Automate the state/payment/claim/FX preflight and post-operation identity refresh, leaving the authorised effect to its registered operation.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-08": {
"failure": "The print shows the wrong party, or a participant change leaves two active owners.",
"findings": [
"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.",
"An IPAL-only party with no SOURCE_ID cannot be treated as already propagated to INSIS."
],
"solution": "Correct the approved participant relationship and every required propagation edge, without changing unrelated roles.",
"steps": [
"Compare participant roles, active ownership shares, bank links and source mappings.",
"Prepare the smallest authorised annex or row delta for the agreed survivor/party.",
"Re-read both systems and regenerate the policy/debit note."
],
"checks": [
"The intended policyholder, owner and bank appear where required.",
"Active ownership shares have the expected total, with no obsolete active link.",
"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.",
"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": "Package the participant/ownership/bank comparison as a deterministic diff with explicit missing source mappings.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-09": {
"failure": "INSIS installments change but IPAL still shows the old schedule or due dates.",
"findings": [
"IPAL POL_PPLAN is an independent splitter, not a projection of INSIS.",
"CHANGE_INSTALLMENTS writes the INSIS side only.",
"PREM_INST/PREM_INST_FRACT contain multiple date fields, and paid installments cannot be treated as editable placeholders."
],
"solution": "Change the agreed unpaid schedule on every required side and compare the full date set.",
"steps": [
"Inventory installments, paid status, residual annexes and all consuming date columns.",
"Apply the authorised splitter/procedure and any separately required IPAL counterpart delta.",
"Reconcile totals and dates, then reopen the payment-plan screen."
],
"checks": [
"Installment amounts sum to the premium in the correct currency.",
"All named due/fraction dates align with the agreed plan.",
"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.",
"memory": "Running the INSIS splitter does not update the IPAL schedule.",
"skill": "Require a two-system date and amount matrix around installment operations.",
"tool": "Automate the independent-schedule comparison, including paid-item exclusions and the complete date-field inventory.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-10": {
"failure": "A reported 'missing discount' is diagnosed from a result field instead of the factors sent for rating.",
"findings": [
"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.",
"A correct quote may require an explanation rather than a data change."
],
"solution": "Replay the actual rating input and explain the result, or isolate the precise incorrect factor/rule.",
"steps": [
"Read the input factor set and selected template/effective version.",
"Reproduce the quote and compare per-cover base premium, loading/discount and recorded totals.",
"Send the supported explanation; route any real rule defect to its owning change path."
],
"checks": [
"The replay uses the same factors and effective rating version.",
"Premium components reconcile with the recorded total and currency.",
"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.",
"memory": "Applied result and fed factor are different evidence.",
"skill": "Require the actual rating request before diagnosing a discount from POL_PREM_RATE.",
"tool": "Build a request-versus-result comparator that preserves per-cover arithmetic and flags a missing or transformed factor.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-11": {
"failure": "A vehicle correction changes the latest row but the policy still consumes an earlier wrong version.",
"findings": [
"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.",
"An earlier consumed snapshot may retain the wrong VIN, registration or type."
],
"solution": "Correct the agreed object chain or use the valid annex path, not just the most recent row.",
"steps": [
"Resolve the complete vehicle version chain and compare each consumed IPAL snapshot with INSIS O_CAR.",
"Prepare the scoped correction using the authoritative mapped vehicle identity and exclude collisions.",
"Re-run the chain-aware comparison and check the affected document/registry outcome."
],
"checks": [
"The relevant COMPARE_IPAL_INSIS_CAR comparison returns no differences.",
"Every consumed version has the intended value and mapping.",
"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.",
"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": "Wrap the chain traversal and field comparison in one reusable read-only vehicle diagnostic.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-12": {
"failure": "A mistaken cancellation closes a policy or its downstream multi-year periods.",
"findings": [
"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.",
"Reviving an INSIS application can be an external-owner action."
],
"solution": "Restore the agreed application or active-policy state using the matching recovery path.",
"steps": [
"Confirm the intended state, regulatory ties, payments and affected family.",
"Have the authorised owner apply its scoped restoration and record what actually changed.",
"Re-read the full family and exercise the required customer action or print."
],
"checks": [
"Both systems show the intended mapped business state.",
"Required downstream periods are reconciled rather than silently abandoned.",
"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.",
"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": "Automate the cancellation-footprint and recovery-precondition comparison before a person selects the authorised path.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-13": {
"failure": "A cancellation or period correction lands on one side and leaves the other system or printed hierarchy stale.",
"findings": [
"Cancellation can fail between the INSIS and IPAL phases in either direction.",
"ConvertApplication does not necessarily refresh INSR_BEGIN/END.",
"A header-only period correction can leave annex, cover and premium date layers unchanged."
],
"solution": "Classify the direction of drift, then reconcile the exact state and date layers that remain wrong.",
"steps": [
"Compare mapped states and every affected period layer against the owner's intended state.",
"Assign each system's correction to its authorised owner, using current before-state predicates.",
"Re-read the complete hierarchy and regenerate the document."
],
"checks": [
"The policy states agree through the declared mapping, not literal code equality.",
"All required begin/end relationships are consistent.",
"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.",
"memory": "The direction and failed propagation edge determine the repair.",
"skill": "Keep separate forward/reverse state-desynchronisation and date-propagation branches.",
"tool": "Build a state/date taxonomy query that returns the divergent layer and its consuming surface.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-14": {
"failure": "A 'hollow policy' remains failed in IPAL after a registry timeout, while a real policy exists in INSIS.",
"findings": [
"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.",
"The header, period hierarchy and SRD_INTEGR caches all participate in the displayed result."
],
"solution": "Reconcile IPAL to the proved INSIS master across all three layers, without another blind conversion.",
"steps": [
"Deduplicate the HelpDesk/Jira/mail aliases and identify the real target policy from effect evidence.",
"Prepare the exact header, annex/object/cover and cache delta for that master.",
"Apply only authorised outstanding steps and verify search plus registry state."
],
"checks": [
"IPAL search returns the intended policy number and active state.",
"All three layers reference the same proved master.",
"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.",
"memory": "A timeout is not proof that no policy was created.",
"skill": "Use one canonical request and a three-layer reconciliation packet.",
"tool": "Automate target-policy candidate discovery and the header/hierarchy/cache diff; do not count channel mirrors as independent learning.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-15": {
"failure": "A green-card/registry request is rejected despite a policy that appears valid locally.",
"findings": [
"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.",
"A blank may have been consumed by another channel."
],
"solution": "Decode the actual response and give the matching explanation or precisely scoped owner instruction.",
"steps": [
"Read the current INTRF_EISOUKR_LOG response and related policy/green-card/sticker periods.",
"Discriminate duplicate cover, period mismatch and blank ownership before proposing any correction.",
"Re-query the promised registry/status outcome after the authorised action, or send the supported explanation."
],
"checks": [
"The response code is interpreted for its actual operation.",
"Dates and blank ownership agree with current registry evidence.",
"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.",
"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": "Automate code decoding and the scoped current-status comparison, preserving observation time.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-16": {
"failure": "The policy has a missing or wrong commission even though the intermediary exists.",
"findings": [
"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.",
"A missing CFG_AGENT_GEN_COMMISSION_RULES rate is a rule problem rather than a copied-percentage fix."
],
"solution": "Distinguish incorrect policy data, a missing effective rule and a propagation defect.",
"steps": [
"Reconstruct the effective agent/product rule and the actual propagated attributes.",
"Prepare the authorised policy-specific correction or assign the missing rule to Configuration/its owner.",
"Recompute and compare the affected commission/self-retention amounts."
],
"checks": [
"The effective rule explains the selected percentage.",
"Policy and commission rows contain the approved result in its currency.",
"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.",
"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": "Automate the effective-rule/attribute/commission comparison and report the exact failing propagation edge.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-17": {
"failure": "The requested document is wrong even though the template itself can render correctly.",
"findings": [
"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.",
"A persisted PDF can predate the data it should show."
],
"solution": "Fix the proved data or document-timing gap, and regenerate the exact document.",
"steps": [
"Find the invocation, requested document name, parameter set and target template version.",
"Compare the consuming INSIS rows and currency/register timing with the document's requirements.",
"Apply the scoped data repair or simply regenerate when all required data is already correct."
],
"checks": [
"The exact requested document is invoked with the right parameters.",
"Required limits, office, rates and period data appear in the new output.",
"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.",
"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": "Build an invocation/data-readiness/document-age probe that chooses repair versus reprint without repeated manual queries.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-18": {
"failure": "A requested catalogue value or blank exists in one place but is missing from the consuming selection.",
"findings": [
"Business-key uniqueness must be checked before an INSERT is prepared.",
"PR_PRICING_FACTOR_VALUES and dependent values can need different mappings and labels.",
"A visible label alone does not establish usable pricing/transfer or blank lifecycle."
],
"solution": "Add only the missing approved business keys and their required dependencies.",
"steps": [
"Compare existing values, dependent keys, labels and external nomenclature codes.",
"Use the applicable BSO/car skill or hand product-factor semantics to Configuration.",
"Re-read the dependent selection and run the authorised consuming check."
],
"checks": [
"The requested value appears under the correct dependency.",
"No duplicate business key or reused blank is introduced.",
"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.",
"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": "Automate business-key and dependency diffs so additions are prepared from missing keys rather than repeated free-form SQL.",
"initial_route": "ready",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-19": {
"failure": "An operator needs one blocked policy through a validation rule, then the normal rule restored.",
"findings": [
"The blocking rule can be on IPAL, ABACUS or both.",
"A row changed 'for one policy' can affect every policy that consumes it.",
"Restoration is a required obligation even if the customer disappears or the deadline expires."
],
"solution": "Approve the complete relax/action/restore chain before changing the first value.",
"steps": [
"Capture the actual rule, original value, twin rule and real audience, with a due time or action trigger.",
"Apply the authorised temporary delta and wait for the designated operator's action report.",
"Verify that action, then obtain H7 and restore/check the original baseline."
],
"checks": [
"The intended action succeeds under the agreed exception.",
"The original value and applicable twin are restored.",
"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.",
"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": "Automate rule/twin/consumer inventory and due-obligation checks; a timer can queue review but cannot authorise the write.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-20": {
"failure": "A duplicate company appears in the picker after its INSIS counterpart was already removed.",
"findings": [
"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.",
"The captured pas_ccust_seek query returned both records, while HIST_P_PEOPLE confirmed the obsolete INSIS counterpart had been deleted."
],
"solution": "Delete the five proved orphan records in one asserted local transaction, preserving the agreed surviving customer.",
"steps": [
"Re-read the survivor, the obsolete record’s 18-child footprint and the same consuming search before approving the packet.",
"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.",
"Replay pas_ccust_seek in the same transaction before commit, then check the actual picker after commit."
],
"checks": [
"Every one of the five statements affects exactly its expected one row.",
"The consuming search changes from two candidates to the one intended survivor.",
"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.",
"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": "Package dependency counts and the exact seek query into a comparison report that refuses an unexplained footprint change.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.",
"sources": [
{
"path": "aisa-next/10 Architecture/40 Support/Case Studies.md",
"label": "Case 2 / SD-1757: 18 FK checks, five asserted deletes and pas_ccust_seek 2-to-1 proof"
}
],
"archive_result": "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."
},
"DC-21": {
"failure": "A backlog contains routine signatures mixed with real transfer exceptions.",
"findings": [
"Some items only need the second signature; others have an active transfer or validation failure.",
"Already-completed target effects must be reconciled before retry.",
"One successful item cannot prove the state of the entire backlog."
],
"solution": "Classify every item, dispatch routine operator actions, and separate the exceptions into their own repair paths.",
"steps": [
"Take a current per-item inventory of source state, request status and target-policy evidence.",
"Assign only the routine, authorised UI actions; record validation/outage exceptions with owners.",
"Join each item's effect receipt and target proof before marking the batch result."
],
"checks": [
"Every declared item has its own classification and outcome.",
"Completed items are not transferred again.",
"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.",
"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": "Automate the backlog classifier and per-item reconciliation matrix; count learning by independent request, not by each row.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-22": {
"failure": "A transferred policy received a neighbouring policy's internal identifier as its displayed number.",
"findings": [
"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.",
"An older 'fixed' article is contradicted by recurrence and must not be treated as current proof."
],
"solution": "Use the checked operator procedure with this policy's own identifier and verify the generated number.",
"steps": [
"Compare the displayed number, own identity and transfer state without conflating equal-looking identifiers.",
"Send the scoped return/set-own-sentinel/retransfer instruction to the authorised customer operator.",
"Record the customer's action and re-read the generated number, target mapping and resulting policy."
],
"checks": [
"The displayed number is a valid policy number rather than another case's internal id.",
"The policy retains the intended mapping and business state.",
"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.",
"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": "Build an identity/number/transfer comparison that supplies safe equality facets and refuses a neighbouring-id shortcut.",
"sources": [
{
"path": "aisa-next/10 Architecture/40 Support/Case Studies.md",
"label": "Case 6 / SD-1675: own-identifier sentinel, customer action and stale earlier fix claim"
}
],
"basis": "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.",
"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.",
"take_decision": "If the wrong number is another policy’s id, use the checked own-identifier instruction; do not change database mappings from memory."
},
"DC-23": {
"failure": "An earlier Beth automation stopped after some effects had already landed.",
"findings": [
"Beth operation batches can contain successful and missing downstream steps.",
"A repeated whole batch can duplicate a document, registration or annex.",
"The promised result may depend on a step outside the automation's success message."
],
"solution": "Reconcile what landed and repair only the missing obligation.",
"steps": [
"Read the Beth operation batch and compare its receipts with current target records.",
"Prepare the authorised missing-step action with a new bounded effect identity.",
"Check the promised annex, print or commission outcome and preserve the original successful effects."
],
"checks": [
"Every required step is either evidenced or explicitly outstanding.",
"Existing documents/registrations are not duplicated.",
"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.",
"memory": "Automation completion text is weaker evidence than individual landed effects.",
"skill": "Use partial-effect reconciliation before rerunning an automation.",
"tool": "Automate a batch-to-target receipt comparison and emit only the unresolved action set.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DC-24": {
"failure": "Infrastructure is healthy again but some policies or workflows remain half-written.",
"findings": [
"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.",
"Retrying all affected items can duplicate those that completed before the failure."
],
"solution": "Classify and reconcile the affected work after the infrastructure owner confirms recovery.",
"steps": [
"Confirm dependency health through its owner and inventory each interrupted item's last durable evidence.",
"Choose the existing repair path for each proved partial effect; keep unknown outcomes blocked for reconciliation.",
"Verify policy/workflow state and the customer surface for every item."
],
"checks": [
"Every declared item has reconciled source and target evidence.",
"Unknown or partial effects remain visible instead of being counted as success.",
"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.",
"memory": "Service recovery and business-work recovery are separate outcomes.",
"skill": "Add explicit before-dispatch, after-effect and before-checkpoint outage branches.",
"tool": "Automate a journal-versus-target recovery inventory, keeping uncertain calls distinct from safe retries.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-01": {
"failure": "A one-policy validation exception would become an uncontrolled shared rule change if its audience or restore were omitted.",
"findings": [
"The CF catalogue includes temporary support requests as well as lasting configuration changes.",
"CFG_FLD_VALIDATION and its ABACUS twin may enforce different parts of the same block.",
"A shared threshold remains shared even when the request mentions one policy."
],
"solution": "Route the bounded exception to Support/Data and approve relaxation, customer action and restoration together.",
"steps": [
"Record the current rule/twin values, real consumer set and the agreed action window.",
"Apply only the authorised temporary delta and await the designated operator's result.",
"Verify the action, then restore the baseline under H7 and check both enforcement paths."
],
"checks": [
"The requested action succeeds within the approved exception.",
"The original rule and twin are restored.",
"No other consumer is left with relaxed permanent behaviour."
],
"recovery": "If the current row no longer equals the case's temporary value, park restoration for reconciliation rather than overwriting the later change.",
"memory": "Temporary rule relief is not a new permanent product configuration.",
"skill": "Require restore identity, before value and due trigger before the first change.",
"tool": "Automate the twin-rule/audience comparison and restoration-due inventory; retain repeated exceptions as evidence for a lasting fix.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-02": {
"failure": "A control row is installed but the requested condition is not actually enforced.",
"findings": [
"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.",
"IPAL, ABACUS and INSIS may have separate enforcement points."
],
"solution": "Change the existing rule where the capability exists, and join any required code or external INSIS work.",
"steps": [
"Export the current rule and express allowed/forbidden examples in the agreed product scope.",
"Apply the selected S2/S3 delta and recruit Development only for behaviour the current evaluator cannot express.",
"Activate on the chosen target after the evaluator and all required twins are ready."
],
"checks": [
"Invalid examples trigger the intended rule.",
"Valid examples and permitted overrules still work.",
"The actual target uses the active rule and all declared twins."
],
"recovery": "Restore the prior rule version and activation state only after checking issued work and compatibility with the evaluator.",
"memory": "A row's existence is not evidence that the evaluator consumes it.",
"skill": "Bind each requested condition to a real capability and positive/negative examples.",
"tool": "Automate a rule-capability/twin audit that detects OFF, unconsumed or missing counterpart rules.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-03": {
"failure": "An exception or product route grants access to more identities than the request authorised.",
"findings": [
"Per-user, per-agent and group overrules are different rights surfaces.",
"IPAL and ABACUS overrule groups may not resolve to the same effective audience.",
"Product Routes/roles are distinct from the platform's own operator permissions."
],
"solution": "Apply the exact approved identity/group delta with shared-impact authority.",
"steps": [
"Resolve the approved identity handles and compare effective rights in every affected validation system.",
"Add or remove only the named bypass/visibility relationships and record their real audience.",
"Test an included and an excluded identity on the actual target."
],
"checks": [
"The intended identity can perform the permitted action.",
"An unlisted identity cannot use the bypass or route.",
"Unrelated roles and products retain their prior permissions."
],
"recovery": "Revert only the recorded rights delta after checking subsequent role changes; do not restore an obsolete whole group membership list.",
"memory": "Group membership is an indirect grant with a potentially larger audience than one user.",
"skill": "Review effective permissions, not only the inserted role row.",
"tool": "Automate effective-audience expansion and positive/negative role checks before a shared rights change.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-04": {
"failure": "A new tariff version exists, but pricing still selects an older deployed version.",
"findings": [
"ABACUS selects DEPLOYED versions, not merely newly created rows.",
"Template and effective date determine which version is priced.",
"Tariff effective date is not PR_BASIC_COVERS.VALID_FROM; price limits may belong to catalogue operations."
],
"solution": "Create and test only the requested tariff-version delta, asserting the version actually selected.",
"steps": [
"Bind the approved rates and worked examples to exact template/effective-date keys.",
"Author maintained rating metadata/files, compile and deploy only on the working environment for validation.",
"Release the chosen version set and re-run the same dated examples on target."
],
"checks": [
"The selected version id is the intended new version.",
"Worked examples reconcile per cover and loading in their stated currency.",
"Before/after effective-date boundaries and unaffected templates retain the expected tariff."
],
"recovery": "Keep the prior deployed version and selector bindings; a rollback must restore the intended version without removing historical applicability.",
"memory": "Compilation success and a plausible premium do not prove the new tariff was used.",
"skill": "Require version-id assertions and effective-date boundary examples.",
"tool": "Automate the template/version selection matrix and compare rating results against the approved worked examples.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-05": {
"failure": "The partner templates compile, but the caller can still silently receive the default tariff.",
"findings": [
"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.",
"Role visibility and a compiled version do not prove the intended caller selects that version."
],
"solution": "Treat each approved template/selector as a bounded work item and join rating, offer and visibility proof.",
"steps": [
"Pin a leaf specification and effective version for KOLHIDA_EUR and MAXO_EUR; run the two template preparation tasks.",
"Bind the approved offer-to-template selectors and permitted audience without changing the unrelated default path.",
"Compile/test each working version, then release the selected set and repeat intended, default and wrong-caller probes."
],
"checks": [
"KOLHIDA and MAXO examples select their declared template/version, not silent fallback.",
"Default callers keep their existing tariff and excluded roles gain no visibility.",
"Every declared template has per-cover rating proof on the requested target."
],
"recovery": "Restore prior selector/role bindings and deployed versions as one compatible set; do not leave a selector pointing at a removed version.",
"memory": "Template existence, caller selection and product visibility are three different checks.",
"skill": "Use a per-template plan with a joined selector/version/audience result matrix.",
"tool": "Build a selector-probe tool that records resolved template/version for intended, unknown/default and excluded callers; reuse it after every promotion.",
"sources": [
{
"path": "aisa-next/10 Architecture/20 Configuration/Typical Cases.md",
"label": "CF-05: named partner templates and incomplete promotion inventory"
},
{
"path": "aisa-next/10 Architecture/20 Configuration/Stage Abacus.md",
"label": "Actual template-selection fallback chain and version-id proof requirements"
}
],
"basis": "Composite configuration example using the census’s KOLHIDA_EUR/MAXO_EUR template names and the documented selector/fallback mechanics. It does not claim a captured incident in which those partners received the wrong price.",
"stage_work": {
"S2": "Prepare KOLHIDA_EUR and MAXO_EUR as separate pinned leaf specifications; compile and quote each intended working version, asserting its actual version id.",
"S4": "Bind the approved offer keys to KOLHIDA_EUR/MAXO_EUR through LB_OFFER_PRICING_RULE; prove that an unknown/default caller follows the unchanged fallback instead.",
"S5": "Apply only the approved product-route and role visibility for the two partner scopes; an unrelated role must remain excluded."
}
},
"CF-06": {
"failure": "Only part of a discount/loading/deductible rule is installed across the three systems.",
"findings": [
"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.",
"Activating a row before its code capability is available creates an inert or wrong rule."
],
"solution": "Join the approved IPAL, ABACUS and INSIS rule obligations before claiming delivery.",
"steps": [
"Map the requested business rule to current definitions, codes and effective dates.",
"Apply the selected stage delta and record the INSIS owner's separate work and any evaluator dependency.",
"Run the same boundary scenario through all promised pricing and policy surfaces."
],
"checks": [
"The requested amount, limit and deductible agree across the declared surfaces.",
"The operative rule is present and selected, not just its type row.",
"Unaffected products and dates retain their previous calculation."
],
"recovery": "Restore the compatible rule/version set and account for policies already issued under it; do not roll one side back in isolation.",
"memory": "A type catalogue entry and its effective rule are separate dependencies.",
"skill": "Require a three-system rule matrix and explicit external-owner evidence.",
"tool": "Automate code/date/rule coverage checks and replay the approved pricing boundary examples.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-07": {
"failure": "A new factor value can be selected but maps to the wrong code or dependent choice.",
"findings": [
"PR_PRICING_FACTOR_VALUES and _DEPENDENT have different business-key scopes.",
"GLOBAL values and shared labels may affect more than the requested product.",
"INSIS/ABACUS code mappings must match the meaning of the new value."
],
"solution": "Add the missing approved value/dependency and label with a verified downstream mapping.",
"steps": [
"Export the current factor keys, parent selections, labels and external codes.",
"Apply only the missing business-key delta under the actual shared/product scope.",
"Select the value under the intended parent and check pricing and transfer consumption."
],
"checks": [
"The value appears under the right parent selection.",
"The downstream system receives the intended code.",
"No duplicate or unrelated global value was changed."
],
"recovery": "Remove only unused inserted keys and restore their prior mappings after checking historical consumers.",
"memory": "A selectable label can still carry the wrong business code.",
"skill": "Include dependent-parent and downstream-code tests in the factor-value procedure.",
"tool": "Automate factor/label/external-code comparison and generate the missing-key plan from the diff.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-08": {
"failure": "A print registration change produces the wrong document set or extra copies.",
"findings": [
"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.",
"The exact document parameters and copy count matter, not just a successful render."
],
"solution": "Deliver the approved registration/selector/template set in compatibility order.",
"steps": [
"Compare the document registration, evaluator capability, template version and parameter contract.",
"Apply the exact registration delta and wait for any required code or external BI-template work.",
"Invoke the intended document and the negative selector cases on the chosen target."
],
"checks": [
"Only the intended documents and copy counts are emitted.",
"Negative or disabled selectors produce no extra documents.",
"The selected template receives the expected object/party parameters."
],
"recovery": "Restore the compatible registration and evaluator/template state; retain already-generated documents as recorded effects.",
"memory": "Adding a gate token before its evaluator can enable rather than suppress printing.",
"skill": "Verify registration, code capability and negative document selection as one release unit.",
"tool": "Automate a document-selection matrix that records emitted document ids/counts and rejected selectors.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-09": {
"failure": "The office/year has numbering rows but cannot allocate a usable policy number.",
"findings": [
"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.",
"Resetting a used counter can collide with already-issued numbers."
],
"solution": "Coordinate the precise row delta and separately authorised sequence/permission work.",
"steps": [
"Read the product/office/year rows and non-consuming sequence metadata under the real principal.",
"Have the authorised DDL or external owner create the missing sequence/grant/synonym; preserve an existing used counter.",
"Run only the approved number-consuming test and record the allocated number."
],
"checks": [
"The requested principal resolves the expected sequence and synonym.",
"The product/office/year path allocates a unique number.",
"Existing issued numbers and counters are preserved."
],
"recovery": "Do not reset or drop a used sequence as rollback; reconcile allocated numbers and compensate only the safe configuration delta.",
"memory": "A sequence's existence is weaker than permission to use it through the consuming name.",
"skill": "Treat row, sequence, synonym and grant as separate prerequisites.",
"tool": "Automate the non-consuming numbering preflight and collision inventory; reserve allocation tests for explicit authority.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-10": {
"failure": "A limit or deductible update copies an incomplete definition set over valid target values.",
"findings": [
"TEST and PROD may contain different legitimate cover/deductible definitions.",
"A sublimit belongs to a particular cover and effective scope.",
"The INSIS counterpart can remain stale after the IPAL delta."
],
"solution": "Apply only the approved per-cover limit/deductible change, preserving accepted target-only definitions.",
"steps": [
"Compare the affected definitions in both directions and confirm the required business limits.",
"Prepare the scoped existing-product delta and the INSIS owner's counterpart obligation.",
"Run at-limit, below-limit and above-limit quotes/views on the chosen target."
],
"checks": [
"The changed cover enforces the approved boundary.",
"Valid target-only and unrelated cover definitions remain.",
"Every promised system shows the compatible limit/deductible."
],
"recovery": "Restore the prior affected definition only after checking policies and later edits; never replace the whole target catalogue with TEST.",
"memory": "Environment differences are not automatically defects to synchronise away.",
"skill": "Require per-cover directional baselines and unchanged-definition regressions.",
"tool": "Automate the cover-definition diff and boundary-case generation without deciding which environment is authoritative.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-11": {
"failure": "The message row is corrected but the operator still sees the old or wrong-language text.",
"findings": [
"The message key and language identify the changed value.",
"Shared consumers may use the same key in several screens/products.",
"A target cache can retain the previous text after the row changes."
],
"solution": "Change the approved text and refresh the correct projection/cache without disturbing other consumers.",
"steps": [
"Resolve the key, language, current text and all affected consumers.",
"Apply the exact shared-label delta and its authorised cache refresh.",
"Open the affected screen/document and compare the displayed wording in each relevant language."
],
"checks": [
"The visible text equals the approved wording.",
"The intended language and shared consumers resolve correctly.",
"Unrelated keys and translations remain unchanged."
],
"recovery": "Restore the specific prior text and refresh its cache after checking for a newer approved wording.",
"memory": "A successful row update does not prove a visible text change.",
"skill": "Carry key/language/consumer/cache evidence with label changes.",
"tool": "Automate key-to-consumer tracing and post-refresh visible-text comparison.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-12": {
"failure": "A new clause prices correctly but cannot be selected, transferred or printed completely.",
"findings": [
"Catalogue, rating, offers, limits, print and INSIS mappings form a dependency chain.",
"A new cover can require code or an externally owned INSIS definition.",
"A single-stage sign-out cannot claim the joint sales/transfer result."
],
"solution": "Run only the affected stages and join every required clause dependency before delivery.",
"steps": [
"Map the new clause to current codes and list missing catalogue/rating/offer/print/seam pieces.",
"Prepare the selected stage and external/code deltas, with compatibility order and signed outputs.",
"Exercise selection, pricing, transfer and printing on the requested target."
],
"checks": [
"The clause is selectable with the intended limits.",
"Rating and loadings reconcile with the approved examples.",
"The clause transfers and prints through the declared mappings."
],
"recovery": "Restore compatible stage versions in dependency order; retain issued-policy and external effects that cannot be rolled back as rows.",
"memory": "Pricing proof is only one part of delivering a usable clause.",
"skill": "Use a cross-stage clause checklist and an explicit join of signed results.",
"tool": "Automate dependency coverage and the same clause's selection/rating/transfer/print assertion set.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-13": {
"failure": "A package's happy path works, but a forbidden cover combination is still selectable.",
"findings": [
"LB_OFFERS and cover-definition rules govern selection, defaults and constraints.",
"Mandatory, optional, conflict and limit rules must be tested as combinations.",
"The offer's rating baseline can be reused only when its template mapping remains compatible."
],
"solution": "Apply the agreed offer/package delta and test allowed and forbidden combinations.",
"steps": [
"Export the existing offer, covers, constraints and compatible pricing inputs.",
"Change only the approved selection/default/rule relationships.",
"Exercise mandatory, optional, conflict and limit combinations with their actual tariff resolution."
],
"checks": [
"Allowed combinations remain selectable and priced.",
"Forbidden combinations are rejected by the consuming flow.",
"Unchanged packages retain their behaviour."
],
"recovery": "Restore the prior compatible offer/rule version and account for quotes or policies already using the new package.",
"memory": "One green package example does not test its exclusion rules.",
"skill": "Require both allowed and forbidden cover combinations in offer sign-out.",
"tool": "Generate and run the bounded combination matrix from the declared offer constraints.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-14": {
"failure": "The new question exists in INSIS but is ignored by IPAL or the rating request.",
"findings": [
"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.",
"A definition deployed on one surface is only partial delivery."
],
"solution": "Join the external question definition with the required factor and rating mappings.",
"steps": [
"Confirm the question meaning, answer codes, conditional requiredness and effective dates.",
"Track the INSIS-owner result and apply only the affected IPAL/rating delta.",
"Enter allowed and missing/invalid answers and inspect the actual rating/transfer input."
],
"checks": [
"The question is usable on every promised surface.",
"Requiredness and valid answer choices are enforced.",
"Rating consumes the intended answer code."
],
"recovery": "Restore only the affected mappings/definition after checking existing answers and policies; preserve historical interpretation.",
"memory": "Seeing a question on one screen does not establish end-to-end consumption.",
"skill": "Keep a question → answer code → factor → rating mapping with requiredness tests.",
"tool": "Automate the mapping comparison and capture actual outgoing factor values for the question examples.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-15": {
"failure": "A new IPAL-to-INSIS mapping row is present but the transfer consumer never reads it.",
"findings": [
"Covers, objects, loadings and fields use different mapping keys.",
"A configuration entry cannot implement a code capability that is absent.",
"Unknown and unmapped inputs require an explicit outcome."
],
"solution": "Change the proven consumed mapping, or recruit Development for the missing consumer capability.",
"steps": [
"Export both code spaces and inspect the active transfer consumer for the proposed mapping field.",
"Apply the approved mapping delta only after its code precondition is satisfied.",
"Transfer representative and unmapped examples and compare the target values."
],
"checks": [
"The intended source values reach the expected target codes.",
"Unmapped/invalid inputs fail in the declared way.",
"Unchanged sibling mappings still work."
],
"recovery": "Restore the compatible mapping and consumer version; reconcile effects of transfers already performed.",
"memory": "An inert mapping is a code/deployment dependency, not a reason to insert more rows.",
"skill": "Prove the consuming code path before accepting a seam change.",
"tool": "Automate mapping coverage and consumer-capability checks, then replay representative transfer assertions.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-16": {
"failure": "The product rows are cloned, but the variant still uses the donor's process, numbering or routes.",
"findings": [
"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.",
"Rating, codes, numbering, documents and access must belong to the variant's own scope."
],
"solution": "Clone only approved structures and join the necessary process/code changes.",
"steps": [
"Inventory the donor and requested differences across all selected configuration parts.",
"Build the variant deltas and accepted Development work rather than copying incompatible behaviour.",
"Run the variant's own quote/issue/transfer/print path and an unchanged-donor regression."
],
"checks": [
"The variant resolves its own codes, tariff and numbering.",
"The intended process and document set are selected.",
"The donor continues to behave as before."
],
"recovery": "Retire or restore only the variant's case-owned structures after checking issued use; never undo shared donor data blindly.",
"memory": "A row clone is not a complete new-product deployment.",
"skill": "Use donor-suitability and clone-plus-code checks before planning the stage set.",
"tool": "Automate a donor/variant dependency diff that flags embedded product ids, shared files and process/numbering reuse.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-17": {
"failure": "ABACUS is ready, but the INSIS-native product is still unusable.",
"findings": [
"The requested sales path belongs to INSIS, not an invented IPAL sales catalogue.",
"ABACUS rating and any IPAL interface seam are separate deliverables.",
"The INSIS product/rule setup remains with its declared external owner."
],
"solution": "Coordinate the native product owner with the selected rating and interface work.",
"steps": [
"Record the native sales objective and required rating/seam contracts.",
"Complete and sign the selected ABACUS/seam deltas while tracking the INSIS owner's setup evidence.",
"Run the promised native flow and its actual rating request before returning the joined result."
],
"checks": [
"The INSIS-native path is usable as requested.",
"ABACUS returns the intended rating for its inputs.",
"Only the promised IPAL seam is claimed; no IPAL issuance proof is invented."
],
"recovery": "Restore compatible rating/seam versions with the native owner; keep externally issued effects explicit.",
"memory": "The configuration proof ladder must match the actual sales channel.",
"skill": "Represent an INSIS-native product as named native/rating/seam obligations.",
"tool": "Automate native-request-to-rating/seam checks and flag missing external-owner evidence at the join.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-18": {
"failure": "A changed specification reaches one stage while another still consumes an older approved revision.",
"findings": [
"Re-uploaded files can amend or contradict earlier requirements.",
"An old H3 or preview signature binds the old artefact, not the new values.",
"Unchanged work should be retained, while dependent assertions must be invalidated."
],
"solution": "Confirm the exact S1 delta and rerun only its affected consumers.",
"steps": [
"Compare the source revisions and identify the requirement changed by the customer.",
"Have the S1 owner publish the approved revision delta and mark dependent sign-outs/assertions stale.",
"Reconcile affected stages and the final preview against the new input revision."
],
"checks": [
"Every affected output cites the current approved requirement.",
"Superseded tariff/limit values no longer drive the target.",
"Unaffected verified work is retained with its valid dependencies."
],
"recovery": "Return to the prior specification only through a new reviewed revision; do not silently reuse an old signature.",
"memory": "Approval follows the artefact revision, not the filename or the fact that the customer once approved it.",
"skill": "Treat requirement amendments as scoped invalidation and reconciliation.",
"tool": "Automate input-revision dependency tracing and report exactly which tests/sign-outs must be rerun.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-19": {
"failure": "A campaign works at launch but has no durable stop-offering or safe retirement plan.",
"findings": [
"Start/end dates and eligibility must be tested at their boundaries.",
"Stopping new sales is different from deleting definitions used by issued policies.",
"A browser/session ending cannot cancel the scheduled obligation."
],
"solution": "Deliver the compatible campaign change together with durable expiry and retirement obligations.",
"steps": [
"Agree campaign dates, eligibility, duration semantics and treatment of already-issued policies.",
"Join the required code/rating/offer/label changes and assign the stop/removal work before delivery.",
"Test boundary dates and later verify that new sales stop while existing policies retain their terms."
],
"checks": [
"Eligible dates and customers receive the campaign; outside cases do not.",
"New sales stop at the agreed boundary.",
"Issued policies remain valid and retirement has an accountable successor."
],
"recovery": "Restore the compatible offering state only after checking issued use; destructive removal is separately scoped and gated.",
"memory": "Commercial expiry and data removal have different effects.",
"skill": "Persist campaign stop-offering and later retirement as separate obligations.",
"tool": "Automate boundary-date probes and due-obligation checks, with a historical-consumer test before removal.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-20": {
"failure": "The product menu is hidden for an excluded role, but the backend still accepts access.",
"findings": [
"Routes and product roles differ across targets.",
"Menu visibility is only one access surface.",
"Shared-role changes can widen access beyond the requested audience."
],
"solution": "Apply and prove the effective audience on both navigation and backend checks.",
"steps": [
"Compare the intended audience with effective target route/role relationships.",
"Apply the exact shared visibility delta and refresh the relevant projection.",
"Test the included and excluded role through the actual menu and backend path."
],
"checks": [
"The intended audience sees and can use the product.",
"An excluded role cannot reach it through a direct request.",
"Unrelated products and roles remain unchanged."
],
"recovery": "Restore only the recorded role/route delta after checking subsequent approved access changes.",
"memory": "A hidden menu is not an authorization boundary.",
"skill": "Require both positive and negative audience tests across UI and backend.",
"tool": "Automate effective-audience expansion and paired navigation/backend probes.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-21": {
"failure": "A nomenclature reload changes the meaning of keys already used by pricing or historical policies.",
"findings": [
"Business keys are consumed by tariffs, labels and external mappings.",
"A new catalogue may rename or regroup meanings rather than merely add rows.",
"Historical policies still need their old values to remain interpretable."
],
"solution": "Apply a reviewed compatibility mapping or additive delta rather than a blind replacement.",
"steps": [
"Compare old/new business keys and enumerate pricing and historical consumers.",
"Resolve meaning changes as a business decision, then apply only the compatible approved reload/mapping.",
"Price and transfer new selections and read representative historical policies."
],
"checks": [
"New values have the intended meaning and downstream codes.",
"Tariff keys keep their approved semantics.",
"Historical consumers and shared labels remain readable."
],
"recovery": "Retain the prior key mapping and compensate only after checking new selections; avoid deleting values already consumed.",
"memory": "Equal-looking catalogue rows do not prove semantic compatibility.",
"skill": "Require key-meaning and historical-consumer checks before a reload.",
"tool": "Automate the old/new key diff with consumer references and unresolved semantic changes.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-22": {
"failure": "A repeated BSO batch request would insert numbers that are already allocated or used.",
"findings": [
"Blank ranges have ownership, uniqueness and FREE/USED lifecycle.",
"A repeat request is not a second independent set of numbers.",
"Consuming a blank to prove issuance is an effect, not a read-only query."
],
"solution": "Provision only the approved missing range using the existing Support/Data skill.",
"steps": [
"Compare the exact ranges, owner and current lifecycle; separate duplicates and used numbers.",
"Insert only the permitted missing range and preserve already-used/allocated blanks.",
"Reconcile counts and uniqueness, then perform only an explicitly approved consumption test."
],
"checks": [
"The range count equals the approved missing set.",
"No duplicate, reinserted used number or changed owner exists.",
"The intended free blank is usable under the approved test."
],
"recovery": "Remove only still-unused case-inserted blanks after checking ownership and subsequent allocation.",
"memory": "One batch is one learning origin, not one independent success per blank.",
"skill": "Keep range, ownership, duplicate and lifecycle checks in the BSO skill.",
"tool": "Automate range-gap/duplicate/lifecycle inventory and exact post-insert reconciliation.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-23": {
"failure": "A commission expression fixes the requested product but changes historical or unrelated calculations.",
"findings": [
"The rule's product/agent scope and effective date determine its audience.",
"A policy-specific commission repair is different from changing a rule set.",
"A shared expression may have consumers beyond the named request."
],
"solution": "Apply the exact effective rule delta with explicit unaffected-scope examples.",
"steps": [
"Compare the current rule, audience, date boundaries and dependent calculations.",
"Apply the approved rule and any required external counterpart without copying a policy percentage.",
"Recompute affected and unchanged participant/date cases in their currency."
],
"checks": [
"The intended effective cases produce the approved commission.",
"Historical and unrelated scopes retain their expected result.",
"The target consumes the intended new rule version."
],
"recovery": "Restore a prior rule only with its effective scope and accounting implications reviewed; do not undo settled results as a simple row reset.",
"memory": "A rule change has a broader audience than one policy correction.",
"skill": "Carry effective-date and unaffected-audience regressions with commission rules.",
"tool": "Automate rule-consumer expansion and a versioned commission example matrix.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-24": {
"failure": "CONTRACT_TYPE or a process registration is deployed but empty or never consumed.",
"findings": [
"A schema column, populated values and the consumer capability are separate release components.",
"BPMN/product registration must select the intended process.",
"Activating configuration before compatible code/schema can leave an inert or failing path."
],
"solution": "Join schema/code capability, configuration values and the intended process selection.",
"steps": [
"Read actual schema support, current values and the active code/BPMN consumer.",
"Deliver compatible prerequisites before activating the approved registration rows.",
"Create the authorised test instance and verify the selected contract type/process."
],
"checks": [
"The required values are populated, not NULL placeholders.",
"The active consumer reads and selects them.",
"The expected workflow runs on the declared target."
],
"recovery": "Restore the compatible registration and consumer set, preserving already-started process instances.",
"memory": "Schema presence is only the first third of a usable contract-type change.",
"skill": "Use schema + value + consumer + workflow proof as one release join.",
"tool": "Automate capability/value/consumer checks and record the selected process version for the test instance.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"CF-25": {
"failure": "A delta built from TEST assumes columns or definitions that do not exist on PROD.",
"findings": [
"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.",
"Environment counts alone cannot decide the desired direction of change."
],
"solution": "Produce a directional reconciliation report for the selected groups; do not synchronise the estate wholesale.",
"steps": [
"Compare actual columns, business keys, effective versions and consuming code in both directions.",
"Classify each difference as requested change, accepted target-only state or unresolved incompatibility.",
"Deliver the reviewed report and exact eligible delta, with unsupported target operations excluded."
],
"checks": [
"Every selected difference has a disposition and observation basis.",
"No packet references a missing target column.",
"Accepted target-only data is preserved; report-only scope performs no writes."
],
"recovery": "Correct the report or withdraw an invalid packet; an unapplied report has no database rollback.",
"memory": "TEST is evidence, not a universal authority for PROD.",
"skill": "Make schema capability and directional business-key baselines prerequisites to configuration.",
"tool": "Automate a target-aware four-layer diff of schema, data, effective versions and consuming code.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-01": {
"failure": "A product's process code is updated, but Camunda still runs the old BPMN version or the wrong product path.",
"findings": [
"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.",
"Existing in-flight instances may continue on their original process version."
],
"solution": "Change the approved product process and release its compatible Core/BPMN components.",
"steps": [
"Pin the product process key, branch heads, BPMN and user-task code; confirm placement.",
"Implement and test the requested path in isolated worktrees, including any Configuration registration dependency.",
"Deploy the declared Core image and BPMN set, then start the permitted test instance."
],
"checks": [
"The target process definition/version is the intended one.",
"A test instance reaches the requested stage with correct user tasks.",
"Existing in-flight instances have an explicit treatment rather than being silently assumed migrated."
],
"recovery": "Use the recorded prior image/process version and account for instances started under the new definition; a code rollback does not rewrite process history.",
"memory": "Image publication and process-definition activation are distinct events.",
"skill": "Require process key/version and a real workflow transition in release proof.",
"tool": "Automate source/BPMN/target-version comparison and capture the test instance's stage transitions.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-02": {
"failure": "The bank-beneficiary print change is only half-promoted: the selector is enabled before its evaluator and data dependencies are ready.",
"findings": [
"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.",
"C# selection, shared library, PL/SQL, registration rows and the external BI template must agree."
],
"solution": "Deliver the complete print contract in compatibility order and test both wanted and unwanted documents.",
"steps": [
"Reproduce per-object bank-beneficiary selection and inventory the exact C#/library/POLQRY/row/template versions.",
"Prepare the reviewed code and stored-code change; join the Configuration and BI-owner obligations before enabling the selector.",
"Promote the compatible set and invoke the exact credited/non-credited object examples."
],
"checks": [
"The requested bank clause contains the intended object and parameters.",
"A non-credited object emits no unwanted bank document.",
"POLQRY has the required implementation, and the target serves all declared components."
],
"recovery": "Restore the compatible selector/evaluator/registration set; previously generated documents remain recorded external effects and may require separate handling.",
"memory": "A fail-open print gate turns an incomplete release into extra output, not just a missing feature.",
"skill": "Never activate the new selector ahead of its evaluator, rows and template.",
"tool": "Automate a print-release manifest plus positive/negative document-selection probes, including a stored-code-body capability check.",
"sources": [
{
"path": "aisa-next/10 Architecture/40 Support/Case Studies.md",
"label": "Case 4 / SD-1863: missing rows, POLQRY stub and fail-open print token"
},
{
"path": "aisa-next/10 Architecture/30 Source/Typical Cases.md",
"label": "DV-02: code, library, PL/SQL, rows and BI-template release obligations"
}
],
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-03": {
"failure": "A request for a reinsurance capability is treated as one small fix despite programme-scale scope.",
"findings": [
"The catalogue describes facultative, treaty, claims and reporting work across many plugins and services.",
"No single generic 'done' test can establish that entire capability.",
"The current Development charter accepts bounded changes, not an unbounded new-module programme."
],
"solution": "Return a scoped programme referral with its accountable owner and separately definable implementation slices.",
"steps": [
"Identify the requested business capability, existing modules and the coordination owner.",
"Separate bounded defects/extensions from the programme's deliverables and dependencies.",
"Record the acknowledged scope/referral and any independently authorised slice."
],
"checks": [
"The owner and scope boundary are acknowledged.",
"No claim says that all facultative/treaty/reporting capability is delivered.",
"Any future slice has its own input, tests and delivery acceptance."
],
"recovery": "Amend the scope/referral if it was wrong; there is no target rollback for a programme that was not implemented.",
"memory": "A long commit stream is evidence of programme scope, not one completed small case.",
"skill": "Keep programme intake distinct from ordinary implementation tasks.",
"tool": "Use a read-only component/dependency inventory to support scope assessment; do not invent an execution tool for an unapproved programme.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-04": {
"failure": "A premium-rule library is released, but an active consumer still computes the old result.",
"findings": [
"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.",
"A family calculation needs boundary examples and unchanged sibling products."
],
"solution": "Implement the agreed rule at its approved seam and release every required consumer.",
"steps": [
"Reproduce the exact product/cover rule with approved arithmetic and inspect actual placement.",
"Implement the narrow change, test affected boundaries and review the package/row dependencies.",
"Publish and rebuild/deploy all declared consumers, then repeat the worked quotes on target."
],
"checks": [
"The affected product/cover examples match the intended calculation and currency.",
"Boundary and unchanged-sibling examples remain correct.",
"Serving consumers use the reviewed package version."
],
"recovery": "Roll back the compatible package/consumer set and account for quotes or policies already produced under the changed rule.",
"memory": "A package release is not a deployed calculation change.",
"skill": "Keep the worked-example set and consumer manifest in the release packet.",
"tool": "Automate package-to-serving-consumer version checks and replay the per-product arithmetic matrix.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-05": {
"failure": "RegisterPolicy returns success, but the partner's policy later fails transfer or printing.",
"findings": [
"The registration plugin, identity client and database schema form one contract.",
"Repeated requests and supplied policy numbers need declared idempotency/validation behaviour.",
"The partner's requested target may be staging without a production release."
],
"solution": "Deliver the bounded registration-contract change with its schema and identity dependencies.",
"steps": [
"Pin the exact partner request examples, target and registration/identity/schema versions.",
"Implement and test valid, invalid and repeated requests at the approved plugin seam.",
"Deploy only the agreed target set and exercise register → transfer → print."
],
"checks": [
"Valid examples produce the intended policy and document.",
"Invalid and repeated requests follow the approved response/effect behaviour.",
"Transfer and print proof accompany REST success."
],
"recovery": "Reconcile policies already registered before retry or compensation; preserve issued numbers and identity-client changes outside the packet.",
"memory": "A successful HTTP response is not proof of completed registration delivery.",
"skill": "Use the approved partner collection as an end-to-end contract with negative and repeat examples.",
"tool": "Automate request replay and downstream policy/transfer/print correlation, with credentials and customer identifiers excluded from retained fixtures.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-06": {
"failure": "The UI accepts party data that the active backend rejects or transfers differently.",
"findings": [
"Customer fields pass through UI validation, backend rules and INSIS propagation.",
"custPid, optional addresses and account-related fields have distinct source/format rules.",
"A same-day UI/backend pair can still be only partly deployed."
],
"solution": "Change and deliver the compatible field contract across the affected consumers.",
"steps": [
"Reproduce create/edit with the exact valid and invalid field examples on the current target.",
"Implement the narrow UI/backend/identity change at the approved seams.",
"Deploy the compatible pair and inspect the resulting participant data after transfer."
],
"checks": [
"The UI and backend agree on valid and invalid input.",
"The intended optional and required fields behave correctly.",
"Transferred participant data matches the approved source meaning."
],
"recovery": "Restore the compatible client/server contract; review records already saved or transferred under the changed rules before attempting data compensation.",
"memory": "A UI validator change does not establish the server's field contract.",
"skill": "Keep source-of-truth and negative/optional-field examples with the paired release.",
"tool": "Automate the UI-request-backend-target field comparison using sanitised fixtures.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-07": {
"failure": "The participant/commission UI reaches production while its required backend half remains on staging.",
"findings": [
"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.",
"Office/agent rules and downstream defaults must be checked together."
],
"solution": "Deliver the reviewed compatible UI/backend change and retain any missing half as an open obligation.",
"steps": [
"Reproduce the participant search/default and identify the actual serving revisions.",
"Implement or promote only the required pair, including the declared plugin/consumer changes.",
"Run the target search and a test quote with the approved intermediary/office scope."
],
"checks": [
"The intended participant is returned.",
"Commission defaults follow the correct agent/office rule.",
"Both serving halves match the release packet."
],
"recovery": "Roll back the compatible pair, not only the visible UI, and account for quotes created with changed defaults.",
"memory": "A green UI deployment can conceal an absent backend capability.",
"skill": "Make required client/server halves explicit in the release join.",
"tool": "Automate a serving-capability/version check before the participant and commission regression probes.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-08": {
"failure": "The BGN-to-EUR programme is compressed into one case and legacy-currency behaviour is lost.",
"findings": [
"The change spans plugins, shared models, rating filters, printing and UI interpretation.",
"The history contains reverts and restoration of conversion behaviour.",
"A new EUR quote and a legacy BGN policy have different obligations."
],
"solution": "Refer the programme explicitly and accept only bounded currency slices with named dependencies.",
"steps": [
"Identify affected product/system seams and the accountable programme owner.",
"Separate the requested slice from the cross-product programme; define both new-EUR and legacy cases for that slice.",
"Record the scope decision or deliver only the separately approved slice."
],
"checks": [
"The referral is labelled as a referral, not a completed currency programme.",
"Any implemented slice preserves the intended legacy interpretation.",
"Its quote, transfer and print examples reconcile with currency displayed."
],
"recovery": "Review conversion semantics and records already produced before reversing a slice; do not undo the programme with a bulk currency-string replacement.",
"memory": "Currency code replacement is not the same as preserving monetary meaning.",
"skill": "Require paired new-currency/legacy-policy fixtures for every bounded slice.",
"tool": "Automate a slice-specific quote/transfer/print comparison with explicit currency and conversion basis.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-09": {
"failure": "A Bulgarian number field looks correct but submits a different numeric value after parsing or blur.",
"findings": [
"The relevant path includes toNumberParser, form validation and the actual outgoing payload.",
"Comma/dot entry, blur and reopening exercise different transitions.",
"The correct master path may differ from the customer's serdica-shared/Formly lineage."
],
"solution": "Route this Core Development offer type into Assessment & Offers. Clarify the request, investigate required effort through scoped domain evidence, draft owner-backed terms, obtain customer approval and communicate the decision. No implementation follows from offer approval.",
"steps": [
"Clarify the exact requested shared behaviour and success examples with the customer.",
"Assess the required work and dependencies using current source evidence and comparable cases; record uncertainty and separate active effort from external waiting.",
"Prepare owner-backed scope/price/delivery terms, obtain the customer’s decision on the exact offer revision, and communicate it. Missing terms remain pending."
],
"checks": [
"The numeric-input gesture and posted value are attached to the owner brief.",
"Every quoted offer or delivery term has an owner/source reference and its proposed/committed status.",
"No Core implementation tasks or grants exist; absent commercial terms remain visible as pending."
],
"recovery": "Correct the request or communicated terms through the same reviewed channel. There is no target code/data change to reverse.",
"memory": "Retain the shared-versus-customer classification, reproducible evidence and the source of commercial/delivery terms; do not retain a fictitious executed repair.",
"skill": "Assess required work and craft a sourced offer; retain comparable effort evidence and the customer decision.",
"tool": "Reuse the common request/packet and channel tools; this request does not justify a new code-execution tool.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations. The current AISA path is classification and commercial communication only. No offer, price or delivery date is invented.",
"similar": "Check whether the new request is the same shared behaviour or a customer-specific variant, then prepare a fresh owner brief and obtain current offer/delivery terms.",
"public_result": "The Core request is in Assessment & Offers. Required effort and the owner’s offer/delivery terms must be established before customer approval; no code change is being implemented."
},
"DV-10": {
"failure": "The requested object-dialog behaviour already exists in source but the target serves an older version.",
"findings": [
"Feature absence, a bug and a missing promotion require different work.",
"The description/dialog history includes changes that did not reach production.",
"Opening, editing and saving exercise more than the initial render."
],
"solution": "Implement only a missing approved capability, or promote the existing reviewed change when deployment is the gap.",
"steps": [
"Compare the target interaction and serving UI revision with the known source change.",
"Prepare the smallest required dialog/label/data-contract delta or promotion.",
"Test open, edit, validate, save and repeated navigation on the target."
],
"checks": [
"The requested dialog or description feature is actually present on target.",
"Edits persist with valid data-contract behaviour.",
"Reopening and subsequent navigation remain usable."
],
"recovery": "Restore the prior compatible UI/data-contract version and keep already-saved record changes explicit.",
"memory": "Source presence does not prove user-visible availability.",
"skill": "Check the serving revision before treating a reported missing UI feature as new development.",
"tool": "Automate the target-version check and a small dialog interaction/persistence regression.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-11": {
"failure": "A framework contract-type column exists, but required values are NULL or never selected by the process.",
"findings": [
"Schema, configuration values, code/plugin and workflow are separate dependencies.",
"Cargo FRAME/group-policy behaviour may touch shared Annexes consumers.",
"A new column on both environments does not establish a working feature."
],
"solution": "Join the contract-type schema, values and consumers with the intended framework flow.",
"steps": [
"Pin actual schema, code and workflow versions and list the expected contract-type values.",
"Implement the approved source changes and join the Configuration delta before activation.",
"Create the permitted child under the intended framework and inspect the consumed contract type."
],
"checks": [
"The required values are populated and meaningful.",
"The active consumer selects the declared FRAME/contract type.",
"The child is created under the correct framework and unrelated contracts still work."
],
"recovery": "Restore a compatible code/value set; account for children or process instances created under the new contract type.",
"memory": "Schema presence, population and runtime consumption are three separate proofs.",
"skill": "Require the mixed code/configuration release and its consumer test.",
"tool": "Automate schema/value/consumer checks and capture the framework/child linkage in the smoke test.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-12": {
"failure": "A motor-flow change handles one subtype but retries an ambiguous partner timeout or breaks a sibling product.",
"findings": [
"Product/subtype and process version determine which rule executes.",
"A timeout may follow a completed external effect.",
"A Next Release wish is a waiting request, not an implicitly authorised deployment."
],
"solution": "Implement the bounded subtype rule or retain the explicit release wait, with timeout reconciliation preserved.",
"steps": [
"Reproduce the exact motor subtype, partner response and current process/riskmodel path.",
"Implement the approved plugin/service/filter change and test affected plus sibling cases.",
"Deploy only as authorised and reconcile an unknown external outcome before any retry."
],
"checks": [
"The requested subtype follows the intended flow.",
"Sibling products and relevant negative responses remain valid.",
"Ambiguous external effects are reconciled rather than repeated."
],
"recovery": "Use the declared code/process reversal and reconcile external registrations or documents already produced.",
"memory": "Timeout classification and subtype discrimination belong in the fix, not in an operator's memory.",
"skill": "Keep subtype, response and current-process inputs in the regression fixture.",
"tool": "Automate subtype/response replay with explicit unknown-outcome checks instead of a blanket retry script.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-13": {
"failure": "A routine port restores a pricing filter that was deliberately reversed on production.",
"findings": [
"Python riskmodel pre/post-filters choose or transform rating inputs/results.",
"Target-only reversals are part of the intended target state until reviewed.",
"The deployed anl-risk-model artifact, not a source file alone, determines behaviour."
],
"solution": "Apply the reviewed target-specific filter change using the repository's Python toolchain.",
"steps": [
"Read the current pre/post-filter, selected template and source/target reversal history.",
"Implement and test the approved input/output behaviour without restoring an excluded target change.",
"Deploy the declared artifact and run current get_rates fixtures per cover and template."
],
"checks": [
"The intended template and per-cover premiums are selected.",
"Unchanged cases retain their expected output.",
"The target serves the approved filter revision, including its intentional exclusions."
],
"recovery": "Restore the recorded prior filter/artifact with its target exceptions; do not use a generic port to erase a deliberate reversal.",
"memory": "A target reversal is evidence of intended behaviour, not automatically a missing commit.",
"skill": "Keep target-specific exclusions and exact filter input/output fixtures.",
"tool": "Automate per-cover filter regressions and compare the proposed port with recorded target-only reversals.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-14": {
"failure": "The C# caller is promoted but the live PL/SQL still implements the old transfer/revert contract.",
"findings": [
"Stored code may not be versioned in the repository alongside its caller.",
"A return-to-application sequence can affect an entire multi-year family.",
"Cross-system timeouts leave effects that must be reconciled before replay."
],
"solution": "Deliver the compatible caller and stored-code contract, then prove the transfer/revert sequence.",
"steps": [
"Reproduce the caller/database boundary and retain the current package body and effect evidence.",
"Prepare the reviewed source and PL/SQL artifacts in compatible order, with declared effect/DDL gates.",
"Run the authorised target sequence and compare family state before and after."
],
"checks": [
"The active caller and package implement the same contract.",
"Transfer/revert completes without duplicate effects.",
"Required family membership and state invariants still hold."
],
"recovery": "Restore compatible caller/package versions and compensate only known landed data effects; a package rollback does not undo policy changes.",
"memory": "Caller deployment and database-contract deployment must join before delivery.",
"skill": "Retain the triggering action, live package identity and whole-family regression.",
"tool": "Automate caller/package capability checks and the journal-backed transfer/revert assertion sequence.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-15": {
"failure": "The new validation library builds successfully, but no enabling row or Bulgarian message reaches the target.",
"findings": [
"The generic Operations library, configuration activation and SR_MESSAGES are separate components.",
"A package version is not enough if a consumer was not rebuilt.",
"Human-readable error arguments are part of the operator-facing contract."
],
"solution": "Deliver the compatible library, consumers, enabling rows and message keys.",
"steps": [
"Identify the generic capability, required activation rows and message parameters.",
"Implement/review the narrow change and join the Configuration or owner's row delivery.",
"Rebuild the declared consumers and trigger valid/invalid examples on target."
],
"checks": [
"The invalid input is blocked by the intended control.",
"A permitted policy start date still passes the enabled control.",
"The Bulgarian message and its arguments resolve from the deployed code/row set."
],
"recovery": "Restore compatible activation/message/library versions and account for cases already processed under the rule.",
"memory": "A build can be green while a configurable control is inert.",
"skill": "Make code, enabling rows, message keys and consumer versions one release checklist.",
"tool": "Automate capability/activation/message completeness checks and replay the invalid/valid operator examples.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-16": {
"failure": "A robustness patch exists but the affected query still scans, truncates useful results or leaks the wrong error.",
"findings": [
"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.",
"Shared library fixes require all affected consumers to be rebuilt."
],
"solution": "Route this Core Development offer type into Assessment & Offers. Clarify the request, investigate required effort through scoped domain evidence, draft owner-backed terms, obtain customer approval and communicate the decision. No implementation follows from offer approval.",
"steps": [
"Clarify the exact requested shared behaviour and success examples with the customer.",
"Assess the required work and dependencies using current source evidence and comparable cases; record uncertainty and separate active effort from external waiting.",
"Prepare owner-backed scope/price/delivery terms, obtain the customer’s decision on the exact offer revision, and communicate it. Missing terms remain pending."
],
"checks": [
"The paging workload, shared cap/default semantics and affected consumers are attached to the owner brief.",
"Every quoted offer or delivery term has an owner/source reference and its proposed/committed status.",
"No Core implementation tasks or grants exist; absent commercial terms remain visible as pending."
],
"recovery": "Correct the request or communicated terms through the same reviewed channel. There is no target code/data change to reverse.",
"memory": "Retain the shared-versus-customer classification, reproducible evidence and the source of commercial/delivery terms; do not retain a fictitious executed repair.",
"skill": "Assess required work and craft a sourced offer; retain comparable effort evidence and the customer decision.",
"tool": "Reuse the common request/packet and channel tools; this request does not justify a new code-execution tool.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations. The current AISA path is classification and commercial communication only. No offer, price or delivery date is invented.",
"similar": "Check whether the new request is the same shared behaviour or a customer-specific variant, then prepare a fresh owner brief and obtain current offer/delivery terms.",
"public_result": "The Core request is in Assessment & Offers. Required effort and the owner’s offer/delivery terms must be established before customer approval; no code change is being implemented."
},
"DV-17": {
"failure": "A cross-branch port matches a commit subject but loses target-only behaviour or lands on the wrong layout.",
"findings": [
"Source and target paths can differ substantially.",
"Target-only fixes and reversals must be preserved explicitly.",
"A history rewrite invalidates previously reviewed head relationships."
],
"solution": "Port the reviewed semantic change in the requested direction against freshly pinned heads.",
"steps": [
"Capture source/target heads, path correspondence and target-only exceptions.",
"Apply the narrow semantic delta in an isolated target worktree and review the target diff.",
"Run target tests and record equivalence evidence against the actual heads."
],
"checks": [
"The target behaviour implements the intended source change.",
"Target-only accepted work remains intact.",
"The reviewed heads still match before promotion; rewritten history forces new review."
],
"recovery": "Use a reviewed revert/continuation on the target's actual history; do not reset away unrelated target work.",
"memory": "Subject matching is retrieval help, not proof of an equivalent port.",
"skill": "Keep directional path maps and target exceptions with the port packet.",
"tool": "Automate head/path/patch correspondence and flag target-only or rewritten-history conflicts for review.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-18": {
"failure": "The image is published after a tooling change, but a clean build or the actual deployment job still fails.",
"findings": [
"CI configuration, runtime dependencies, lockfiles and generated schemas can change together.",
"The job identity and target environment must be explicit.",
"Generated artifacts or instruction files cannot be silently omitted from review."
],
"solution": "Fix the specific build/runtime boundary and prove the complete reproducible artifact/job path.",
"steps": [
"Reproduce the failing clean build or job with the pinned toolchain and dependency graph.",
"Make the scoped CI/dependency/tooling change and review lock/schema/instruction changes with it.",
"Run a clean build and the declared runtime/job checks, then verify target use if deployment was requested."
],
"checks": [
"The clean build is reproducible from the reviewed inputs.",
"The intended job produces the correct artifact for the named target.",
"Runtime/deployment proof accompanies registry publication where required."
],
"recovery": "Restore compatible toolchain/config/lock versions; preserve produced artifacts and actual job effects for reconciliation.",
"memory": "An image in a registry is not deployment or runtime acceptance.",
"skill": "Include generated and tooling-control files in the reviewable change.",
"tool": "Automate a pinned clean-build/job/artifact verification run and report the exact failing boundary.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
},
"DV-19": {
"failure": "An appsettings reset overwrites an environment-specific route or secret reference.",
"findings": [
"The active service may read values from a different source than the edited local file.",
"Environment-specific routes are intentional differences until reviewed.",
"Secret values must remain in the existing secret store, not copied into example configuration."
],
"solution": "Apply only the approved target setting delta through the actual configuration/image release path.",
"steps": [
"Compare intended settings, local resets, target configuration sources and the consuming service.",
"Prepare the minimal reviewed value/reference change while preserving unrelated target settings.",
"Deploy through the declared path and exercise the integration that consumes the setting."
],
"checks": [
"The active service reads the intended target value.",
"The required route/integration works.",
"Unrelated routes and secret references are preserved."
],
"recovery": "Restore the recorded prior target value/reference via the same release mechanism; never restore an entire developer-local file over the target.",
"memory": "A local reset is not evidence that the target should match the developer's defaults.",
"skill": "Keep per-environment setting meaning and consumption in the deployment checklist.",
"tool": "Automate a redacted target-setting diff and a focused consumption probe, showing references rather than secrets.",
"basis": "Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations."
}
},
"studies": {
"1": {
"case_id": "DC-01"
},
"2": {
"case_id": "DC-20"
},
"3": {
"case_id": "DC-06"
},
"4": {
"case_id": "DV-02"
},
"5": {
"case_id": "DC-03"
},
"6": {
"case_id": "DC-22"
},
"7": {
"request": "The policy should run for 65 months, but IPAL shows 60; the print has the intended date.",
"failure": "The first diagnosis extrapolated TEST deployment evidence to PROD and proposed a broad promotion/back-fill.",
"findings": [
"The LAST_DDL_TIME evidence initially came from TEST only; it could not establish a missing PROD deployment.",
"A PROD check found both relevant packages deployed on 26.05, two minutes apart.",
"The remaining failure was one policy on a silent exception path, not a proved thousand-policy campaign failure."
],
"solution": "Back-fill only the affected policy’s required date hierarchy and propose the bounded stored-code correction separately.",
"steps": [
"Re-read PROD package and policy evidence with environment origin attached.",
"Review the one-policy END_DATE/RENEWAL_DATE delta across the consuming header/annex/object/cover hierarchy.",
"Re-check the IPAL header’s intended 27.10.2031 date and retain the separate trace/renewal-date code issue."
],
"checks": [
"The PROD claim cites PROD evidence.",
"The affected IPAL date matches the agreed date already reflected by the print.",
"No unproved fleet-wide correction is included."
],
"memory": "Wrong-environment evidence can turn a single-policy failure into an invented deployment incident.",
"skill": "Reject an environment claim unless its evidence envelope names that environment.",
"tool": "Automate environment-stamped package/row comparison and limit the proposed affected set to proved records."
},
"8": {
"request": "After reverting and correcting the multi-year policies, period 3 is missing from INSIS.",
"failure": "The revert/cancellation cascade affected renewal periods; this is not the SD-1598 missing-register-only variant.",
"findings": [
"The archive describes cancellation/renaming of periods 2 and 3 and retransfer recreating only period 2.",
"The inventory distinguished current IPAL rows, historical INSIS instances and the MYR register.",
"Later correction rounds also confused tariff numbers 1.80%/2.10% with depreciation; they are different fields and meanings."
],
"solution": "Use the reviewed family recovery/UI sequence for the actual surviving state, then verify every period and the requested pricing meaning.",
"steps": [
"Inventory all periods and cancellation history before choosing the recovery branch.",
"Perform the authorised return/edit/recalculate/transfer sequence, refreshing identities and preconditions after each effect; hold no DB transaction across human waits.",
"Re-read all family members and prints after each material correction, and keep the causal development proposal separate."
],
"checks": [
"Every intended period exists and prints.",
"Tariff rate is checked in its own pricing fields, not inferred from MYR depreciation.",
"The outcome and any residual/cancelled instances remain explicit."
],
"memory": "A cancelled/uncreated renewal cannot be repaired by copying the one-row register INSERT from another family.",
"skill": "Select the recovery by family state and keep tariff-versus-depreciation semantics explicit.",
"tool": "Extend the family inventory with current/historical identity and price-field meaning checks."
},
"9": {
"request": "Three requests concern twelve installments, a rejected cargo proposal, and a missing bank-beneficiary block.",
"failure": "Three plausible shortcuts caused three different retractions: wrong tables, wrong business intent and missed correspondence.",
"findings": [
"SD-1627: empty CFG_DURATION_PFREQUENCY/CFG_FLD_VALIDATION results did not rule out the PR_PRICING_FACTOR_VALUES LOV gate with ATTR3=UR_12_INSTALLMENTS.",
"SD-1636: the requester wanted an application; a retransfer created an unwanted active policy before the intended external revive.",
"SD-1651: the mail thread identified the BI template’s empty beneficiary block; a remembered “wrong INSIS tab” answer did not address it."
],
"solution": "Resolve each case with its separating evidence; do not reuse one surface-level explanation across them.",
"steps": [
"For SD-1627, inspect the consumed LOV and peer role-qualified row before the one-row addition.",
"For SD-1636, confirm the application end-state, reconcile the already-created effects and obtain the named INSIS owner’s result.",
"For SD-1651, use the correspondence and exact print to coordinate the template owner, including the address variant."
],
"checks": [
"The twelve-installment role consumes the intended LOV value.",
"The cargo object has the agreed application state, with unintended effects accounted for.",
"The exact beneficiary block and address print correctly."
],
"memory": "Zero rows in two tables do not prove absence of a third gate; “transfer” does not define the desired business state.",
"skill": "Require consuming-path introspection, explicit intent and cross-channel evidence.",
"tool": "Use targeted gate/intent/source-evidence checks and preserve each corrected claim with its counterexample."
},
"10": {
"request": "The hollow-policy view should show the two references reported through HelpDesk and mirrored into Jira.",
"failure": "The Jira mirror was completed in six minutes, but that did not mean the underlying cache repair had been executed.",
"findings": [
"The references represented different origins: one generated Serdica number had already materialised as an official policy number.",
"The INSIS-origin policy correctly lacked a C_POLICIES header; reporting caches, not a missing portal policy, were the proposed repair surface.",
"Four cache UPDATEs were proposed and held pending confirmation of the consuming view; the archive says they were not executed."
],
"solution": "Confirm the cache consumers and keep the bounded cache delta held; do not insert a C_POLICIES header or infer repair from mirror status.",
"steps": [
"Correlate the HelpDesk origin and Jira mirror once, then resolve both policy identities.",
"Verify the two cache consumers and prepare only the scoped four-update packet.",
"Apply only after authority and current preflight; then test the actual hollow-policy view."
],
"checks": [
"The original request and its mirror are one work origin.",
"No portal header is fabricated for the INSIS-only policy.",
"The view, not Jira completion, supplies repair proof after any future application."
],
"memory": "Channel completion and operational completion are different events.",
"skill": "Keep proposed/unapplied cache work visible and verify the consuming view.",
"tool": "Automate origin/identity/cache correlation and retain the held action set without counting a clean execution."
}
},
"marketing": {
"case": "CF-05",
"label": "The goal, in one configuration request",
"heading": [
"Make the change.",
"Prove the right caller gets it."
],
"quote": "“Give KOLHIDA and MAXO their own EUR prices — and no one else.”",
"origin": "CF-05 is the modal ABACUS change on this estate: product 4704 alone carries 115 rating versions against 71 product versions. HDesk 00097862 and 00102031; the INSIS five-table anatomy of SD-1443.",
"today": "Today each template is a version prepared on TEST and promoted one to two months later — and thirteen online-channel templates of 06–07.2026 never left TEST at all.",
"touches": [
"Parts 5, 3 and 12 of the twelve — tariff, packages, access — plus the INSIS discount configuration and its five-table anatomy (CFG_ABC_QUEST_DISC_AGENT 4 → 33 rows, SD-1443).",
"Stages S2 Abacus, S4 Offer and S5 Serdica only; the deployment set is abacus-only plus the product-visibility roles (“Show custom product 4704 / 4710 for (AVVI)”).",
"The rows a partner template actually moves: LB_OFFER_PRICING_RULE 8, CFG_SPECIAL_OFFER_MOTOR 14 (08.2026), and one rating version per template — KOLHIDA_EUR, MAXO_EUR, BL / ER_RENT / ER_LEASE.",
"S1 has to hold N templates for one product where the product schema holds one, so every template is a leaf specification with its own selector, audience and effective version."
],
"customer": "Each approved template becomes its own bounded work item: a pinned leaf specification and effective version, the approved offer selector and permitted audience, then per-cover rating proof on the requested target. The request is not finished because the versions compiled — it is finished when the intended caller resolves the approved template, the default caller keeps its existing tariff, and the excluded role still sees nothing.",
"next": "Retain that template existence, caller selection and product visibility are three different checks, and turn the probe into a tool that records the resolved template and version for the intended, the default and the excluded caller. The next partner request resolves the caller and the active template first, then writes a version delta instead of copying an example."
}
}