CSI baseline CSI-CARD-2026-10-22 · 22 October 2026. Limited to the registered source set. Application execution and proposed tests were not run; source findings do not establish runtime behaviour.

CardDemo: action plan

Assessment baseline: 22 October 2026. The next work should bind the evidence and installed environment, then resolve the two specific integrity questions. The priorities below are proposed review priorities based on the known paths and missing evidence. They are not vulnerability severity ratings, delivery commitments or claims that any work has already run.

Recommended order and deliverables

The public edition supplies C13-03, C13-04 and C13-13 as proposed scenarios. It does not supply execution results or a verified source-to-PDF binding. CARD-SRC-07 CARD-SRC-09

First establish what is being reviewed

The retained source archive establishes the source statements used in this assessment. The later public documentation edition has separate provenance and does not verify its analysed upstream commit. For the paths to be exercised, obtain a source-to-documentation binding or compare the relevant programs and dependencies. Record the resulting authority decision before calling an observed difference a defect. An older retained specification must not become the current requirement merely because it is available. CARD-SRC-01 CARD-SRC-07 CARD-SRC-14

In parallel with that reconciliation, the application and runtime owners can provide the exact installed dependencies and builds. Confirm that the optional authorisation extension is enabled before preparing its failure case. Attach the effective queue, database, transaction and file configuration needed to interpret observations. These are proposed responsibilities; no individual owner or delivery date is assigned by this report. CARD-SRC-05 CARD-SRC-06

Resolve the authorisation boundary

The first behaviour question is whether the requester observes approval when the later IMS write fails in the chosen environment. The source establishes that the reply routine precedes the database-write routine and uses MQ no-syncpoint options. The vendor semantics explain why a later backout does not by itself undo an outside-syncpoint put. The unresolved part is the actual message, database and transaction outcome. CARD-SRC-02 CARD-SRC-10 CARD-SRC-11

Prepare CARD-TEST-01 in an authorised isolated environment with the bound build and controlled fixtures. Capture request consumption, reply content and correlation, actual receipt, IMS summary/detail state, transaction outcome and logs. Review a normal control alongside the failure case. The deliverable should state what happened and what remains unobserved before recommending a transaction-boundary change. CARD-SRC-09

A change proposal should preserve the approval/decline contract and correlation behaviour and explain how it addresses any observed disagreement between the received response and recorded state. This is a proposed decision criterion, not a conclusion that such a disagreement has occurred.

Resolve recovery prerequisites and paired-update behaviour

Obtain installed ACCTDAT and CUSTDAT FILE definitions and the corresponding ICF catalog LOG attributes before interpreting a rollback experiment. The retained program's rollback request is explicit, but the sample RECOVERY(NONE) and JOURNAL(NO) declarations do not settle effective recoverability. CARD-SRC-03 CARD-SRC-04 CARD-SRC-12 CARD-SRC-13

Use CARD-TEST-02 to compare both records after a normal paired update and after a controlled customer-write failure following the account rewrite. Then use CARD-TEST-03 to inspect stale-update rejection and the recorded values after a concurrent change. Preserve unchanged fields and no-change observations when assessing any runtime or resource change. CARD-SRC-03 CARD-SRC-09

The resulting review should distinguish the program's requested control flow, the installed resource prerequisites and the observed outcome. This distinction prevents a rollback statement from being treated as evidence that both records were restored.

Evaluate notices only after the inventory is bound

After CARD-TEST-04, a reviewer can evaluate a specific vendor notice against its exact product, affected range and configuration conditions. An applicable MQ/IMS change could then use the authorisation trace; a relevant CICS recovery change could use the paired-update trace. These links select candidate regression work. They do not create a CVE or support finding in advance. CARD-SRC-02 CARD-SRC-03 CARD-SRC-05 CARD-SRC-06

Completion criteria for the next review

The next review should present the selected baseline, dated installed inventory, effective configuration, scenario authority and any newly captured observations together. Each task should retain its present not run status until evidence supports a different state. Failed, incomplete and blocked observations should be recorded as such, rather than converted into a pass.

Any proposed remediation should cite the finding, the new evidence and the behaviour it is intended to preserve. A later assessment should retain this dated baseline so that changes in conclusions remain reviewable.