CSI baseline CSI-IFX-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.

Informix4GL Demo: verification plan

Dated baseline: 22 October 2026 · Five tasks, all not run

Verification status and scope

The following tasks describe evidence to collect and behaviour to observe. No application execution, deployment inspection, parser test or regression run was performed for this assessment. Two tasks develop retained characterisation proposals; three were proposed to close the assessment's identity, applicability and upgrade gaps. IFX-S-C13 IFX-S-PROVENANCE IFX-S-E0014

IFX-V-001: bind exact deployment, source and dependency identities

Purpose. Establish what is being assessed before relying on a version match. The retained documentation's analysed source revision is unbound, and filenames or mutable tags do not identify exact deployed binaries. IFX-S-PROVENANCE IFX-S-E0014

Work to perform. Identify the executable and source/build revision. Collect jar hashes, manifests and package metadata, including fork or patch provenance. Record the Informix edition and fix pack, container digest or installed archive provenance, Java distribution/version, JDBC driver and framework version. Establish which documented database setup route is effective. IFX-S-C10 IFX-S-E0014

Evidence to retain. An inventory linking each artifact to the build and environment, the method and date of collection, and the exact fields still unknown. Keep sensitive configuration out of public evidence.

Completion criterion. Every component used in a disposition is tied to an exact artifact and environment, or its unresolved identity remains an explicit blocker. Use the server result to check whether IFX-F-004's archive-specific rejection applies to the assessed server. IFX-S-IBM-20515

IFX-V-002: resolve iText/report-framework use and parser reachability

Purpose. Resolve two separate questions: whether the report framework uses iText, and whether a vulnerable PDF/XML parser receives relevant input. Retained descriptions of report output answer neither question completely. IFX-S-E0012 IFX-S-XXE

Work to perform. Inspect the framework or a trustworthy dependency/use map for the exact build. Identify library calls and their callers. For any relevant parsing entry point, trace input origin, transformations, runtime invocation, parser configuration and controls. Keep outbound report generation distinct from document parsing. If a later controlled runtime check is required, record its scope and conditions separately from static evidence.

Evidence to retain. A cited caller map, the binary identity from IFX-V-001, parser-specific observations and a reasoned candidate disposition. Record missing code or inaccessible paths as gaps rather than assuming a result.

Completion criterion. IFX-F-002 has a build-specific disposition supported by the package and path evidence, or remains unresolved with named missing conditions. The iText-to-framework relationship has its own documented state. IFX-F-001's support decision remains separately tracked. IFX-S-E0014 IFX-S-XXE IFX-S-ITEXT-EOL

IFX-V-003: characterise implemented report destinations

Purpose. Capture how mailing labels and accounts receivable behave for the executable being assessed before a reporting dependency changes. The retained plan covers file, printer and screen destinations. IFX-S-C13 IFX-S-C08

Work to perform. Use controlled customer and unpaid-order data. Select each implemented destination and record the output, completion behaviour, row handling and any errors. Capture default output files such as labels.out and ar.out where applicable. Observe report start, row emission and completion without assuming the framework's buffering semantics. IFX-S-E0012 IFX-S-C13

Evidence to retain. Executable and build identity, data preconditions, selected destination, generated output or permitted output capture, displayed messages and observed completion. Record unsupported or stubbed options separately; their menu presence is not evidence of report implementation. IFX-S-C14

Completion criterion. Each agreed implemented destination has an observed result suitable for comparison after the change. No destination is marked passed from a source expectation alone.

IFX-V-004: characterise order commit, rollback and invoice output

Purpose. Observe the documented order sequence and the boundaries left unresolved by the framework. This task covers the Java executable identified in the test record; separate 4GL programs require separate results. IFX-S-C13 IFX-S-C14

Scenario evidence: IFX-S-E0012 IFX-S-C13.

Evidence to retain. Inputs, database preconditions and final rows, transaction observations, messages, invoice invocation and output, totals, and any framework trace needed to explain an exception outcome.

Completion criterion. Each scenario has a recorded observation for the named build, and disagreements with source expectations remain visible. A passing successful-order scenario cannot stand in for the failure, exception or rounding scenarios.

IFX-V-005: verify the chosen server/Java/JDBC upgrade

Purpose. Establish that a precise target satisfies its installation prerequisites and supports the application's database behaviour. The IBM Java change matters when the selected target falls within the documented packaging boundary. IFX-S-IBM-JRE

Work to perform. Select and pin the server edition, fix pack, platform and image/archive. Record its requirements and provision the required Java environment. Build an isolated environment, verify installation and startup, load the agreed reference data, exercise JDBC operations, and run the relevant order, invoice and report scenarios. Reuse IFX-V-003 and IFX-V-004 outputs for comparison rather than inventing a new expected behaviour. IFX-S-C10 IFX-S-C13

Evidence to retain. Target identifiers, dependency versions, installation/startup results, Java and JDBC checks, test preconditions and regression outcomes.

Completion criterion. The exact target's prerequisites and agreed regressions are evidenced. Any failed or untested path remains open. A successful server installation alone does not complete the application verification.

Common result format

Record task and scenario, date, reviewer, source/build and environment identifiers, inputs, expected behaviour or question, actual observation, supporting evidence and disposition. Use not run, observed, passed against stated criteria, failed against stated criteria, or unresolved accurately. Preserve the distinction between a documented expectation and an executed result when updating the dated baseline.