Configuration module — typical cases

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

Customer request

Temporarily relax this validation for one policy.

Specific failure illustrated

A one-policy validation exception would become an uncontrolled shared rule change if its audience or restore were omitted.

Initial solution take

A one-policy validation exception would become an uncontrolled shared rule change if its audience or restore were omitted.

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

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

1. The CF catalogue includes temporary support requests as well as lasting configuration changes.
2. CFG_FLD_VALIDATION and its ABACUS twin may enforce different parts of the same block.
3. A shared threshold remains shared even when the request mentions one policy.

Return to solution take

Route the bounded exception to Support/Data and approve relaxation, customer action and restoration together.

Reject this shortcut: A supposedly policy-specific threshold actually affects every policy using the shared row: require the full impact gate.

Confirmation and application

1. Record the current rule/twin values, real consumer set and the agreed action window.
2. Apply only the authorised temporary delta and await the designated operator's result.
3. Verify the action, then restore the baseline under H7 and check both enforcement paths.

Verification

1. The requested action succeeds within the approved exception.
2. The original rule and twin are restored.
3. 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.

What is retained

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 candidate: Automate the twin-rule/audience comparison and restoration-due inventory; retain repeated exceptions as evidence for a lasting fix.

Next request: Look up previous exceptions and causal fixes, then re-read the live rule and its audience.

Source basis: CF-01 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Add a check that prevents this invalid policy.

Specific failure illustrated

A control row is installed but the requested condition is not actually enforced.

Initial solution take

A control row is installed but the requested condition is not actually enforced.

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

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

1. A control row that is installed but still OFF cannot enforce the requested rule.
2. Conditional or computed behaviour may need code rather than another configuration value.
3. IPAL, ABACUS and INSIS may have separate enforcement points.

Return to solution take

Change the existing rule where the capability exists, and join any required code or external INSIS work.

Reject this shortcut: The row exists but is OFF, or the INSIS twin is omitted: fail.

Confirmation and application

1. Export the current rule and express allowed/forbidden examples in the agreed product scope.
2. Apply the selected S2/S3 delta and recruit Development only for behaviour the current evaluator cannot express.
3. Activate on the chosen target after the evaluator and all required twins are ready.

Verification

1. Invalid examples trigger the intended rule.
2. Valid examples and permitted overrules still work.
3. 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.

What is retained

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 candidate: Automate a rule-capability/twin audit that detects OFF, unconsumed or missing counterpart rules.

Next request: Search prior rule changes, export current state and distinguish missing activation from missing code.

Source basis: CF-02 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Only this group should be allowed the exception.

Specific failure illustrated

An exception or product route grants access to more identities than the request authorised.

Initial solution take

An exception or product route grants access to more identities than the request authorised.

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

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

1. Per-user, per-agent and group overrules are different rights surfaces.
2. IPAL and ABACUS overrule groups may not resolve to the same effective audience.
3. Product Routes/roles are distinct from the platform's own operator permissions.

Return to solution take

Apply the exact approved identity/group delta with shared-impact authority.

Reject this shortcut: An overly broad group grants the exception to unlisted users: reject.

Confirmation and application

1. Resolve the approved identity handles and compare effective rights in every affected validation system.
2. Add or remove only the named bypass/visibility relationships and record their real audience.
3. Test an included and an excluded identity on the actual target.

Verification

1. The intended identity can perform the permitted action.
2. An unlisted identity cannot use the bypass or route.
3. 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.

What is retained

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 candidate: Automate effective-audience expansion and positive/negative role checks before a shared rights change.

Next request: Recheck current group membership, scope and requested authority; no previous approval is inherited.

Source basis: CF-03 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Apply the new tariff from the agreed date.

Specific failure illustrated

A new tariff version exists, but pricing still selects an older deployed version.

Initial solution take

A new tariff version exists, but pricing still selects an older deployed version.

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

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

1. ABACUS selects DEPLOYED versions, not merely newly created rows.
2. Template and effective date determine which version is priced.
3. Tariff effective date is not PR_BASIC_COVERS.VALID_FROM; price limits may belong to catalogue operations.

Return to solution take

Create and test only the requested tariff-version delta, asserting the version actually selected.

Reject this shortcut: The new version is present but the engine still selects the old tariff: fail.

Confirmation and application

1. Bind the approved rates and worked examples to exact template/effective-date keys.
2. Author maintained rating metadata/files, compile and deploy only on the working environment for validation.
3. Release the chosen version set and re-run the same dated examples on target.

Verification

1. The selected version id is the intended new version.
2. Worked examples reconcile per cover and loading in their stated currency.
3. 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.

What is retained

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 candidate: Automate the template/version selection matrix and compare rating results against the approved worked examples.

Next request: Check current effective versions and requested scope before importing another tariff.

Source basis: CF-04 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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.

Customer request

Prepare the approved EUR partner templates with the correct offer selection and visibility.

Specific failure illustrated

The partner templates compile, but the caller can still silently receive the default tariff.

Initial solution take

The partner templates compile, but the caller can still silently receive the default tariff.

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

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

1. Offer-to-template resolution falls through TemplateOfferCode, OfferCode and LB_OFFER_PRICING_RULE to configured/default fallback.
2. KOLHIDA_EUR and MAXO_EUR are named template examples in the configuration census; this replay combines the documented template and selector mechanics.
3. Role visibility and a compiled version do not prove the intended caller selects that version.

Return to solution take

Treat each approved template/selector as a bounded work item and join rating, offer and visibility proof.

Reject this shortcut: All templates compile but every caller falls back to the default: fail.

Confirmation and application

1. Pin a leaf specification and effective version for KOLHIDA_EUR and MAXO_EUR; run the two template preparation tasks.
2. Bind the approved offer-to-template selectors and permitted audience without changing the unrelated default path.
3. Compile/test each working version, then release the selected set and repeat intended, default and wrong-caller probes.

Verification

1. KOLHIDA and MAXO examples select their declared template/version, not silent fallback.
2. Default callers keep their existing tariff and excluded roles gain no visibility.
3. 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.

What is retained

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 candidate: Build a selector-probe tool that records resolved template/version for intended, unknown/default and excluded callers; reuse it after every promotion.

Next request: Resolve the caller and active template first; reuse only compatible examples and create a new version delta.

Source basis: CF-05: named partner templates and incomplete promotion inventory — aisa-next/10 Architecture/20 Configuration/Typical Cases.md; Actual template-selection fallback chain and version-id proof requirements — aisa-next/10 Architecture/20 Configuration/Stage Abacus.md

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

Customer request

Change the discount and deductible rule.

Specific failure illustrated

Only part of a discount/loading/deductible rule is installed across the three systems.

Initial solution take

Only part of a discount/loading/deductible rule is installed across the three systems.

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

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

1. An INSIS HT_DISCOUNT_TYPE entry alone is not the operative discount rule.
2. IPAL definitions and ABACUS loading logic may use different codes or dates.
3. Activating a row before its code capability is available creates an inert or wrong rule.

Return to solution take

Join the approved IPAL, ABACUS and INSIS rule obligations before claiming delivery.

Reject this shortcut: Only HT_DISCOUNT_TYPE is installed while the operative rule is missing: no completion.

Confirmation and application

1. Map the requested business rule to current definitions, codes and effective dates.
2. Apply the selected stage delta and record the INSIS owner's separate work and any evaluator dependency.
3. Run the same boundary scenario through all promised pricing and policy surfaces.

Verification

1. The requested amount, limit and deductible agree across the declared surfaces.
2. The operative rule is present and selected, not just its type row.
3. 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.

What is retained

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 candidate: Automate code/date/rule coverage checks and replay the approved pricing boundary examples.

Next request: Check existing partial delivery and active versions before adding duplicate definitions.

Source basis: CF-06 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Add this value under the selected factor.

Specific failure illustrated

A new factor value can be selected but maps to the wrong code or dependent choice.

Initial solution take

A new factor value can be selected but maps to the wrong code or dependent choice.

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

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

1. PR_PRICING_FACTOR_VALUES and _DEPENDENT have different business-key scopes.
2. GLOBAL values and shared labels may affect more than the requested product.
3. INSIS/ABACUS code mappings must match the meaning of the new value.

Return to solution take

Add the missing approved value/dependency and label with a verified downstream mapping.

Reject this shortcut: A new factor value is selectable but maps to the wrong INSIS code: fail.

Confirmation and application

1. Export the current factor keys, parent selections, labels and external codes.
2. Apply only the missing business-key delta under the actual shared/product scope.
3. Select the value under the intended parent and check pricing and transfer consumption.

Verification

1. The value appears under the right parent selection.
2. The downstream system receives the intended code.
3. No duplicate or unrelated global value was changed.

Recovery

Remove only unused inserted keys and restore their prior mappings after checking historical consumers.

What is retained

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 candidate: Automate factor/label/external-code comparison and generate the missing-key plan from the diff.

Next request: Read current value and parent dependencies first; distinguish missing value from missing visibility.

Source basis: CF-07 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Change the documents produced for this product.

Specific failure illustrated

A print registration change produces the wrong document set or extra copies.

Initial solution take

A print registration change produces the wrong document set or extra copies.

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

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

1. CFG_PRINT_DOCS, its evaluator and the BI template are separate dependencies.
2. NULL/zero or an unknown selector token can be treated as enabled on a fail-open path.
3. The exact document parameters and copy count matter, not just a successful render.

Return to solution take

Deliver the approved registration/selector/template set in compatibility order.

Reject this shortcut: A NULL/zero gate is interpreted as enabled and extra documents are emitted: reject.

Confirmation and application

1. Compare the document registration, evaluator capability, template version and parameter contract.
2. Apply the exact registration delta and wait for any required code or external BI-template work.
3. Invoke the intended document and the negative selector cases on the chosen target.

Verification

1. Only the intended documents and copy counts are emitted.
2. Negative or disabled selectors produce no extra documents.
3. 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.

What is retained

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 candidate: Automate a document-selection matrix that records emitted document ids/counts and rejected selectors.

Next request: Probe invocation and current template parameters before editing the same cell again.

Source basis: CF-08 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

This office cannot get a policy number.

Specific failure illustrated

The office/year has numbering rows but cannot allocate a usable policy number.

Initial solution take

The office/year has numbering rows but cannot allocate a usable policy number.

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

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

1. CFG_POLICY_NO_SEQ does not establish that the INSIS sequence, synonym and grant exist.
2. The executing principal must see the correct sequence through the expected name.
3. Resetting a used counter can collide with already-issued numbers.

Return to solution take

Coordinate the precise row delta and separately authorised sequence/permission work.

Reject this shortcut: The sequence exists but its synonym/grant is missing, or a reset would collide: fail.

Confirmation and application

1. Read the product/office/year rows and non-consuming sequence metadata under the real principal.
2. Have the authorised DDL or external owner create the missing sequence/grant/synonym; preserve an existing used counter.
3. Run only the approved number-consuming test and record the allocated number.

Verification

1. The requested principal resolves the expected sequence and synonym.
2. The product/office/year path allocates a unique number.
3. 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.

What is retained

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 candidate: Automate the non-consuming numbering preflight and collision inventory; reserve allocation tests for explicit authority.

Next request: Inspect existing sequence and maximum issued values before applying a known creation pattern.

Source basis: CF-09 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Change the cover limit for this product.

Specific failure illustrated

A limit or deductible update copies an incomplete definition set over valid target values.

Initial solution take

A limit or deductible update copies an incomplete definition set over valid target values.

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

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

1. TEST and PROD may contain different legitimate cover/deductible definitions.
2. A sublimit belongs to a particular cover and effective scope.
3. The INSIS counterpart can remain stale after the IPAL delta.

Return to solution take

Apply only the approved per-cover limit/deductible change, preserving accepted target-only definitions.

Reject this shortcut: Copying TEST's smaller deductible set removes valid PROD definitions: reject.

Confirmation and application

1. Compare the affected definitions in both directions and confirm the required business limits.
2. Prepare the scoped existing-product delta and the INSIS owner's counterpart obligation.
3. Run at-limit, below-limit and above-limit quotes/views on the chosen target.

Verification

1. The changed cover enforces the approved boundary.
2. Valid target-only and unrelated cover definitions remain.
3. 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.

What is retained

Memory: Environment differences are not automatically defects to synchronise away.

Skill: Require per-cover directional baselines and unchanged-definition regressions.

Tool candidate: Automate the cover-definition diff and boundary-case generation without deciding which environment is authoritative.

Next request: Export both targets, including PROD-only definitions, before changing one cover.

Source basis: CF-10 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Correct this message shown to the customer.

Specific failure illustrated

The message row is corrected but the operator still sees the old or wrong-language text.

Initial solution take

The message row is corrected but the operator still sees the old or wrong-language text.

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

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

1. The message key and language identify the changed value.
2. Shared consumers may use the same key in several screens/products.
3. A target cache can retain the previous text after the row changes.

Return to solution take

Change the approved text and refresh the correct projection/cache without disturbing other consumers.

Reject this shortcut: The row changes but the customer still sees cached text: no visible-result proof.

Confirmation and application

1. Resolve the key, language, current text and all affected consumers.
2. Apply the exact shared-label delta and its authorised cache refresh.
3. Open the affected screen/document and compare the displayed wording in each relevant language.

Verification

1. The visible text equals the approved wording.
2. The intended language and shared consumers resolve correctly.
3. Unrelated keys and translations remain unchanged.

Recovery

Restore the specific prior text and refresh its cache after checking for a newer approved wording.

What is retained

Memory: A successful row update does not prove a visible text change.

Skill: Carry key/language/consumer/cache evidence with label changes.

Tool candidate: Automate key-to-consumer tracing and post-refresh visible-text comparison.

Next request: Check the current target key and cache before proposing another translation write.

Source basis: CF-11 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Add this clause to the existing product.

Specific failure illustrated

A new clause prices correctly but cannot be selected, transferred or printed completely.

Initial solution take

A new clause prices correctly but cannot be selected, transferred or printed completely.

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

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

1. Catalogue, rating, offers, limits, print and INSIS mappings form a dependency chain.
2. A new cover can require code or an externally owned INSIS definition.
3. A single-stage sign-out cannot claim the joint sales/transfer result.

Return to solution take

Run only the affected stages and join every required clause dependency before delivery.

Reject this shortcut: The cover prices correctly but has no INSIS mapping or print support: fail.

Confirmation and application

1. Map the new clause to current codes and list missing catalogue/rating/offer/print/seam pieces.
2. Prepare the selected stage and external/code deltas, with compatibility order and signed outputs.
3. Exercise selection, pricing, transfer and printing on the requested target.

Verification

1. The clause is selectable with the intended limits.
2. Rating and loadings reconcile with the approved examples.
3. 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.

What is retained

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 candidate: Automate dependency coverage and the same clause's selection/rating/transfer/print assertion set.

Next request: Export the current clause and related versions first; apply only the requested new delta.

Source basis: CF-12 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Change the covers included in this package.

Specific failure illustrated

A package's happy path works, but a forbidden cover combination is still selectable.

Initial solution take

A package's happy path works, but a forbidden cover combination is still selectable.

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

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

1. LB_OFFERS and cover-definition rules govern selection, defaults and constraints.
2. Mandatory, optional, conflict and limit rules must be tested as combinations.
3. The offer's rating baseline can be reused only when its template mapping remains compatible.

Return to solution take

Apply the agreed offer/package delta and test allowed and forbidden combinations.

Reject this shortcut: The happy-path package works but a forbidden cover combination remains selectable: reject.

Confirmation and application

1. Export the existing offer, covers, constraints and compatible pricing inputs.
2. Change only the approved selection/default/rule relationships.
3. Exercise mandatory, optional, conflict and limit combinations with their actual tariff resolution.

Verification

1. Allowed combinations remain selectable and priced.
2. Forbidden combinations are rejected by the consuming flow.
3. Unchanged packages retain their behaviour.

Recovery

Restore the prior compatible offer/rule version and account for quotes or policies already using the new package.

What is retained

Memory: One green package example does not test its exclusion rules.

Skill: Require both allowed and forbidden cover combinations in offer sign-out.

Tool candidate: Generate and run the bounded combination matrix from the declared offer constraints.

Next request: Re-evaluate the current offer and pricing versions before reusing its previous rule.

Source basis: CF-13 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Add this question to the product questionnaire.

Specific failure illustrated

The new question exists in INSIS but is ignored by IPAL or the rating request.

Initial solution take

The new question exists in INSIS but is ignored by IPAL or the rating request.

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

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

1. INSIS-native question/answer codes, IPAL factors and ABACUS input are distinct mappings.
2. Requiredness may depend on another answer and need a real evaluator capability.
3. A definition deployed on one surface is only partial delivery.

Return to solution take

Join the external question definition with the required factor and rating mappings.

Reject this shortcut: INSIS shows the question but IPAL or rating still ignores it: remain partially delivered.

Confirmation and application

1. Confirm the question meaning, answer codes, conditional requiredness and effective dates.
2. Track the INSIS-owner result and apply only the affected IPAL/rating delta.
3. Enter allowed and missing/invalid answers and inspect the actual rating/transfer input.

Verification

1. The question is usable on every promised surface.
2. Requiredness and valid answer choices are enforced.
3. Rating consumes the intended answer code.

Recovery

Restore only the affected mappings/definition after checking existing answers and policies; preserve historical interpretation.

What is retained

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 candidate: Automate the mapping comparison and capture actual outgoing factor values for the question examples.

Next request: Inspect which twins already exist and their effective dates rather than restarting the whole request.

Source basis: CF-14 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

The new clause is not transferred correctly.

Specific failure illustrated

A new IPAL-to-INSIS mapping row is present but the transfer consumer never reads it.

Initial solution take

A new IPAL-to-INSIS mapping row is present but the transfer consumer never reads it.

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

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

1. Covers, objects, loadings and fields use different mapping keys.
2. A configuration entry cannot implement a code capability that is absent.
3. Unknown and unmapped inputs require an explicit outcome.

Return to solution take

Change the proven consumed mapping, or recruit Development for the missing consumer capability.

Reject this shortcut: The mapping row is present but the consumer never reads that column: reject.

Confirmation and application

1. Export both code spaces and inspect the active transfer consumer for the proposed mapping field.
2. Apply the approved mapping delta only after its code precondition is satisfied.
3. Transfer representative and unmapped examples and compare the target values.

Verification

1. The intended source values reach the expected target codes.
2. Unmapped/invalid inputs fail in the declared way.
3. Unchanged sibling mappings still work.

Recovery

Restore the compatible mapping and consumer version; reconcile effects of transfers already performed.

What is retained

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 candidate: Automate mapping coverage and consumer-capability checks, then replay representative transfer assertions.

Next request: Check current code and configuration together before treating a missing result as a missing row.

Source basis: CF-15 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Create a variant of this existing product.

Specific failure illustrated

The product rows are cloned, but the variant still uses the donor's process, numbering or routes.

Initial solution take

The product rows are cloned, but the variant still uses the donor's process, numbering or routes.

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

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

1. A donor's structures are not all reusable for the new product.
2. The census’s 3606-from-3635 example required a product process/BPMN change as well as copied configuration rows.
3. Rating, codes, numbering, documents and access must belong to the variant's own scope.

Return to solution take

Clone only approved structures and join the necessary process/code changes.

Reject this shortcut: Rows are cloned but the product starts the donor's wrong process or uses donor numbering: fail.

Confirmation and application

1. Inventory the donor and requested differences across all selected configuration parts.
2. Build the variant deltas and accepted Development work rather than copying incompatible behaviour.
3. Run the variant's own quote/issue/transfer/print path and an unchanged-donor regression.

Verification

1. The variant resolves its own codes, tariff and numbering.
2. The intended process and document set are selected.
3. 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.

What is retained

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 candidate: Automate a donor/variant dependency diff that flags embedded product ids, shared files and process/numbering reuse.

Next request: Read the donor's current state and reject incompatible inherited fields or processes.

Source basis: CF-16 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Configure the new core-system product and its rating.

Specific failure illustrated

ABACUS is ready, but the INSIS-native product is still unusable.

Initial solution take

ABACUS is ready, but the INSIS-native product is still unusable.

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

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

1. The requested sales path belongs to INSIS, not an invented IPAL sales catalogue.
2. ABACUS rating and any IPAL interface seam are separate deliverables.
3. The INSIS product/rule setup remains with its declared external owner.

Return to solution take

Coordinate the native product owner with the selected rating and interface work.

Reject this shortcut: An ABACUS-only sign-out closes the request while the INSIS product remains unusable: reject.

Confirmation and application

1. Record the native sales objective and required rating/seam contracts.
2. Complete and sign the selected ABACUS/seam deltas while tracking the INSIS owner's setup evidence.
3. Run the promised native flow and its actual rating request before returning the joined result.

Verification

1. The INSIS-native path is usable as requested.
2. ABACUS returns the intended rating for its inputs.
3. 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.

What is retained

Memory: The configuration proof ladder must match the actual sales channel.

Skill: Represent an INSIS-native product as named native/rating/seam obligations.

Tool candidate: Automate native-request-to-rating/seam checks and flag missing external-owner evidence at the join.

Next request: Recognise the target administration at intake and select only its real stages.

Source basis: CF-17 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

The specification changed; update the existing work.

Specific failure illustrated

A changed specification reaches one stage while another still consumes an older approved revision.

Initial solution take

A changed specification reaches one stage while another still consumes an older approved revision.

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

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

1. Re-uploaded files can amend or contradict earlier requirements.
2. An old H3 or preview signature binds the old artefact, not the new values.
3. Unchanged work should be retained, while dependent assertions must be invalidated.

Return to solution take

Confirm the exact S1 delta and rerun only its affected consumers.

Reject this shortcut: An old H3 or preview approval is reused after the tariff/limit requirement changed: reject.

Confirmation and application

1. Compare the source revisions and identify the requirement changed by the customer.
2. Have the S1 owner publish the approved revision delta and mark dependent sign-outs/assertions stale.
3. Reconcile affected stages and the final preview against the new input revision.

Verification

1. Every affected output cites the current approved requirement.
2. Superseded tariff/limit values no longer drive the target.
3. 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.

What is retained

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 candidate: Automate input-revision dependency tracing and report exactly which tests/sign-outs must be rerun.

Next request: Retrieve the product's latest approved scope and change history before accepting another re-upload.

Source basis: CF-18 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Run this promotion for the agreed period.

Specific failure illustrated

A campaign works at launch but has no durable stop-offering or safe retirement plan.

Initial solution take

A campaign works at launch but has no durable stop-offering or safe retirement plan.

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

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

1. Start/end dates and eligibility must be tested at their boundaries.
2. Stopping new sales is different from deleting definitions used by issued policies.
3. A browser/session ending cannot cancel the scheduled obligation.

Return to solution take

Deliver the compatible campaign change together with durable expiry and retirement obligations.

Reject this shortcut: A closed browser/session cancels campaign retirement, or removal breaks issued policies: reject.

Confirmation and application

1. Agree campaign dates, eligibility, duration semantics and treatment of already-issued policies.
2. Join the required code/rating/offer/label changes and assign the stop/removal work before delivery.
3. Test boundary dates and later verify that new sales stop while existing policies retain their terms.

Verification

1. Eligible dates and customers receive the campaign; outside cases do not.
2. New sales stop at the agreed boundary.
3. 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.

What is retained

Memory: Commercial expiry and data removal have different effects.

Skill: Persist campaign stop-offering and later retirement as separate obligations.

Tool candidate: Automate boundary-date probes and due-obligation checks, with a historical-consumer test before removal.

Next request: Check current campaign and successor obligations before extending or recreating it.

Source basis: CF-19 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Make the product visible to the agreed users.

Specific failure illustrated

The product menu is hidden for an excluded role, but the backend still accepts access.

Initial solution take

The product menu is hidden for an excluded role, but the backend still accepts access.

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

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

1. Routes and product roles differ across targets.
2. Menu visibility is only one access surface.
3. Shared-role changes can widen access beyond the requested audience.

Return to solution take

Apply and prove the effective audience on both navigation and backend checks.

Reject this shortcut: The menu hides a route but the backend still permits an excluded role: fail.

Confirmation and application

1. Compare the intended audience with effective target route/role relationships.
2. Apply the exact shared visibility delta and refresh the relevant projection.
3. Test the included and excluded role through the actual menu and backend path.

Verification

1. The intended audience sees and can use the product.
2. An excluded role cannot reach it through a direct request.
3. Unrelated products and roles remain unchanged.

Recovery

Restore only the recorded role/route delta after checking subsequent approved access changes.

What is retained

Memory: A hidden menu is not an authorization boundary.

Skill: Require both positive and negative audience tests across UI and backend.

Tool candidate: Automate effective-audience expansion and paired navigation/backend probes.

Next request: Recheck live effective rights; TEST visibility does not prove PROD entitlement.

Source basis: CF-20 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Replace this nomenclature with the approved version.

Specific failure illustrated

A nomenclature reload changes the meaning of keys already used by pricing or historical policies.

Initial solution take

A nomenclature reload changes the meaning of keys already used by pricing or historical policies.

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

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

1. Business keys are consumed by tariffs, labels and external mappings.
2. A new catalogue may rename or regroup meanings rather than merely add rows.
3. Historical policies still need their old values to remain interpretable.

Return to solution take

Apply a reviewed compatibility mapping or additive delta rather than a blind replacement.

Reject this shortcut: Replacing the catalogue changes the meaning of existing tariff keys: reject.

Confirmation and application

1. Compare old/new business keys and enumerate pricing and historical consumers.
2. Resolve meaning changes as a business decision, then apply only the compatible approved reload/mapping.
3. Price and transfer new selections and read representative historical policies.

Verification

1. New values have the intended meaning and downstream codes.
2. Tariff keys keep their approved semantics.
3. 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.

What is retained

Memory: Equal-looking catalogue rows do not prove semantic compatibility.

Skill: Require key-meaning and historical-consumer checks before a reload.

Tool candidate: Automate the old/new key diff with consumer references and unresolved semantic changes.

Next request: Re-evaluate current pricing references and previously rejected scope before reusing a reload script.

Source basis: CF-21 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Add the next batch of green cards and stickers.

Specific failure illustrated

A repeated BSO batch request would insert numbers that are already allocated or used.

Initial solution take

A repeated BSO batch request would insert numbers that are already allocated or used.

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

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

1. Blank ranges have ownership, uniqueness and FREE/USED lifecycle.
2. A repeat request is not a second independent set of numbers.
3. Consuming a blank to prove issuance is an effect, not a read-only query.

Return to solution take

Provision only the approved missing range using the existing Support/Data skill.

Reject this shortcut: A repeated request would reinsert used or already allocated blanks: reject.

Confirmation and application

1. Compare the exact ranges, owner and current lifecycle; separate duplicates and used numbers.
2. Insert only the permitted missing range and preserve already-used/allocated blanks.
3. Reconcile counts and uniqueness, then perform only an explicitly approved consumption test.

Verification

1. The range count equals the approved missing set.
2. No duplicate, reinserted used number or changed owner exists.
3. The intended free blank is usable under the approved test.

Recovery

Remove only still-unused case-inserted blanks after checking ownership and subsequent allocation.

What is retained

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 candidate: Automate range-gap/duplicate/lifecycle inventory and exact post-insert reconciliation.

Next request: Check overlap and lifecycle again; last month's range is not this month's authority.

Source basis: CF-22 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Change the commission rules for this product.

Specific failure illustrated

A commission expression fixes the requested product but changes historical or unrelated calculations.

Initial solution take

A commission expression fixes the requested product but changes historical or unrelated calculations.

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

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

1. The rule's product/agent scope and effective date determine its audience.
2. A policy-specific commission repair is different from changing a rule set.
3. A shared expression may have consumers beyond the named request.

Return to solution take

Apply the exact effective rule delta with explicit unaffected-scope examples.

Reject this shortcut: A new global expression changes historical or unrelated policies unexpectedly: fail.

Confirmation and application

1. Compare the current rule, audience, date boundaries and dependent calculations.
2. Apply the approved rule and any required external counterpart without copying a policy percentage.
3. Recompute affected and unchanged participant/date cases in their currency.

Verification

1. The intended effective cases produce the approved commission.
2. Historical and unrelated scopes retain their expected result.
3. 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.

What is retained

Memory: A rule change has a broader audience than one policy correction.

Skill: Carry effective-date and unaffected-audience regressions with commission rules.

Tool candidate: Automate rule-consumer expansion and a versioned commission example matrix.

Next request: Read the current effective rule and its affected scope before reusing the earlier expression.

Source basis: CF-23 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Register the new contract type and its process.

Specific failure illustrated

CONTRACT_TYPE or a process registration is deployed but empty or never consumed.

Initial solution take

CONTRACT_TYPE or a process registration is deployed but empty or never consumed.

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

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

1. A schema column, populated values and the consumer capability are separate release components.
2. BPMN/product registration must select the intended process.
3. Activating configuration before compatible code/schema can leave an inert or failing path.

Return to solution take

Join schema/code capability, configuration values and the intended process selection.

Reject this shortcut: CONTRACT_TYPE is deployed but NULL and never consumed: no completion.

Confirmation and application

1. Read actual schema support, current values and the active code/BPMN consumer.
2. Deliver compatible prerequisites before activating the approved registration rows.
3. Create the authorised test instance and verify the selected contract type/process.

Verification

1. The required values are populated, not NULL placeholders.
2. The active consumer reads and selects them.
3. The expected workflow runs on the declared target.

Recovery

Restore the compatible registration and consumer set, preserving already-started process instances.

What is retained

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 candidate: Automate capability/value/consumer checks and record the selected process version for the test instance.

Next request: Check all three layers before assuming a new field or registration row is sufficient.

Source basis: CF-24 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md

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

Customer request

Show what differs before we change the product.

Specific failure illustrated

A delta built from TEST assumes columns or definitions that do not exist on PROD.

Initial solution take

A delta built from TEST assumes columns or definitions that do not exist on PROD.

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

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

1. UI_REQUIRED is a documented TEST-only column; target schema must be checked before packet construction.
2. The census also finds legitimate PROD-only deductible/rule data and differing effective versions.
3. Environment counts alone cannot decide the desired direction of change.

Return to solution take

Produce a directional reconciliation report for the selected groups; do not synchronise the estate wholesale.

Reject this shortcut: A TEST-only UI_REQUIRED column is used in a PROD write packet: reject before dispatch.

Confirmation and application

1. Compare actual columns, business keys, effective versions and consuming code in both directions.
2. Classify each difference as requested change, accepted target-only state or unresolved incompatibility.
3. Deliver the reviewed report and exact eligible delta, with unsupported target operations excluded.

Verification

1. Every selected difference has a disposition and observation basis.
2. No packet references a missing target column.
3. 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.

What is retained

Memory: TEST is evidence, not a universal authority for PROD.

Skill: Make schema capability and directional business-key baselines prerequisites to configuration.

Tool candidate: Automate a target-aware four-layer diff of schema, data, effective versions and consuming code.

Next request: Re-measure affected groups; stored differences are historical evidence, never today's source of truth.

Source basis: CF-25 evidence, mechanism and delivery census — aisa-next/10 Architecture/20 Configuration/Typical Cases.md