Modernisation proposal for review; durations are indicative.

verification-and-acceptance.md

This document is an unapproved planning proposal. It defines proposed verification and acceptance evidence for CardDemo modernisation; it does not record executed tests, approved thresholds, semantic equivalence, production readiness, cutover authority, or retirement authority. All tests described below remain unexecuted. Where measurable thresholds, service levels, retention periods, availability, performance, recovery time, recovery point, or acceptable reconciliation differences are not evidenced, they remain decisions for accountable owners.

Results must be classified as passed, failed, blocked by missing evidence, not executable, or not applicable. Processing, compilation, deployment, connectivity, record counts, or tooling completion alone must not be accepted as proof of correct business semantics. Each result should retain the tested environment, deployed versions, controlled inputs, expected and actual outputs, messages, return codes, state before and after execution, commits, locks, logs, external effects, discrepancies, and recovery outcome.

VER-001 Verify the Deployed Baseline and Executable Characterization

Changes: Establish the Deployed Baseline and Evidence Register; Characterize Behaviour and Define Acceptance Before Replacement.

The proposed characterization should establish which releases, programs, maps, copybooks, transactions, jobs, procedures, datasets, VSAM clusters and alternate indexes, DB2 and IMS structures, queues, scheduler definitions, generated artifacts, load modules, configurations, and external interfaces are deployed in each relevant environment. Source-only, inactive, optional, historical, generated, and obsolete material should remain distinguishable from observed runtime behaviour. Conflicting names, layouts, page sizes, transfer targets, file roles, job sequences, and technology combinations must be retained as unresolved variants until runtime evidence resolves them.

Executable characterization should cover normal, boundary, invalid, duplicate, concurrent, not-found, partial-failure, restart, rerun, and restoration cases across sign-on, routing, inquiries, maintenance, payments, transaction processing, authorization, fraud, reference data, reporting, statements, migration, batch, and destructive file operations. Evidence should show business results and external effects rather than merely path execution.

Acceptance requires an accountable baseline for the tested scope, reproducible observations, and explicit disposition of every material contradiction as resolved, excluded from scope with evidence, or blocked. Unknown ownership, inaccessible runtime components, or inability to identify the active release blocks acceptance of affected paths.

Related changes: CHG-001, CHG-002

VER-002 Verify Workforce Identity, Authorization, and User Administration

Changes: Modernize Workforce Identity and Application Authorization; Preserve User Administration While Replacing Credential Handling.

Characterization should establish existing sign-on outcomes, administrative and ordinary-user routing, user-type meanings, effective permissions, retry and lockout behaviour, session handling, identity propagation, support access, deletion behaviour, and user-visible duplicate or missing-record errors. It should determine whether legacy security records act as credentials, routing profiles, authorization records, or a mixture. Display masking must not be treated as evidence of secure password storage.

Security verification should demonstrate the proposed authentication path, application-level authorization, least privilege, segregation of duties, privileged and break-glass access, managed workload identities, audit records, secret handling, session controls, and behaviour during identity-provider or connectivity failure. Tests should confirm that Azure role assignments do not unintentionally replace required application authorization. Legacy passwords must not be copied unless their protection and migration method are shown to be safe and supported; otherwise an approved reset or federation process is required.

Migration evidence should include account correlation, routing continuity, controlled handling of unmatched identities, rollback without locking authorized users out of both paths, and preservation of required audit history. Acceptance thresholds for retries, lockout, session duration, access-review completion, and privileged-access controls remain decisions.

Related changes: CHG-003, CHG-007

VER-003 Verify Presentation Contracts and Read-Only Servicing

Changes: Replace CICS and BMS Presentation Incrementally; Introduce Read-Only Servicing as the First Candidate Slice.

Characterization should compare legacy and proposed account or card inquiry for identity and role routing, cross-reference lookup, authoritative keys, not-found distinctions, filtering, sorting, paging, attention-key behaviour, masking, field formatting, validation, messages, and unavailable or placeholder options. Conflicting card keys, possibly omitted account-key components, page sizes, maps, transfer targets, snapshots, and presentation-to-storage mappings must be tested as alternatives rather than normalized.

Migration verification should compare approved field-level and semantic results without exposing sensitive values. It should exercise coexistence adapters, encoding and length translation, hybrid connectivity failures, stale or unavailable sources, progressive routing, telemetry, and routing back to the legacy path. Accessibility and enterprise interface requirements remain decisions until supplied.

Acceptance requires agreement on source authority and comparison rules, no unexplained difference in an authoritative key or material meaning, preserved error distinctions for the accepted scope, and a rehearsed routing rollback. Numerical discrepancy tolerances, latency, availability, and traffic progression gates remain owner decisions.

Related changes: CHG-004, CHG-005

VER-004 Verify Servicing Transactions and Concurrency

Changes: Consolidate Party, Account, and Card Servicing Transactions.

Characterization should exercise customer, account, cross-reference, and card validation; required lengths and numeric fields; status and expiry ranges; compound keys; uniqueness; identity mutability; not-found states; unchanged values; concurrent updates; locking; deadlocks; retries; and stale retrieved data. A specific failure test should update an account and then force the related customer update to fail, observing whether all intended changes roll back. The possible overwrite or loss of supplied card-security data must be tested without presuming that a defect exists.

Migration evidence should show authoritative ownership during coexistence and prevent ungoverned dual writes. If more than one store receives changes, evidence should demonstrate durable propagation, idempotency, lag detection, failure reconciliation, conflict handling, and preservation of audit history. Security evidence should confirm that card-security and personal data are minimized, protected, and excluded from inappropriate logs.

Acceptance requires exact agreed state transitions, preserved validation and not-found distinctions, and either one demonstrated local transaction or an explicitly accepted compensation model. Lock scope, retry limits, deadlock policy, uniqueness rules, and treatment of card-security values remain decisions where characterization does not resolve them.

Related changes: CHG-006

VER-005 Verify Atomic Payment and Transaction Outcomes

Changes: Establish Atomic and Idempotent Payment Processing; Separate Accepted and Rejected Transaction Outcomes.

Characterization should test blank and unknown accounts, invalid or non-payable states, unconfirmed payments, non-positive and insufficient balances, invalid formats, expiry, limits, duplicate identifiers, identifier exhaustion, concurrent submissions, accepted work, rejected work, reversals, refunds, restart, and rerun. Expected results should distinguish transactions, balances, statuses, failure reasons, and external effects. Rejected work must remain identifiable and must not be counted as successful processing.

Atomicity tests should inject failure before and after transaction creation, balance adjustment, status change, publication, acknowledgement, and commit. Repeated requests and reruns should demonstrate the agreed duplicate and idempotency semantics. Where one database transaction is proposed, rollback should leave the agreed pre-operation state. Where work is separated, evidence should cover durable commands, idempotency keys, state transitions, outbox processing, compensation, and reconciliation.

Migration comparison must avoid producing two real financial effects. Shadow validation or another approved non-posting comparison should reconcile decisions and calculations. Acceptance requires no unexplained authoritative financial difference, no unaccounted external effect, and a rehearsed stop, rollback, or forward-recovery procedure. Exact calculations, duplicate rules, tolerances, and acceptable reconciliation differences remain decisions until recovered and approved.

Related changes: CHG-008, CHG-009

VER-006 Verify Authorization Messaging and Fraud Separation

Changes: Reconcile Authorization Messaging and Persistence; Keep Fraud Processing Logically Distinct.

Characterization should recover request and response schemas, correlation, ordering, expiry, acknowledgement, retry, duplicate, timeout, dead-letter, reply-timing, and persistence semantics. Failure injection should occur before and after receipt, evaluation, persistence, publication, acknowledgement, timeout, retry, and expiry. Tests must determine whether response-before-persistence is required behaviour and whether MQ operations participate in any synchronization boundary.

Migration evidence should show how in-flight messages are drained, fenced, switched, replayed, or retained without loss or duplicate processing. If a transactional outbox changes reply timing, that change requires explicit acceptance. If response-before-persistence is preserved, durable recovery and reconciliation must restore missing persistence after an externally observed response.

Fraud tests should independently characterize duplicate-key handling, states, blocking effects, review activity, retention, purge predicates, and its relationship to authorization and transaction acceptance. Acceptance must not consolidate fraud and authorization by assumption. Timing, ordering, duplicate-detection windows, and dead-letter thresholds remain decisions.

Related changes: CHG-010, CHG-011

VER-007 Verify Reference Data Authority and Distribution

Changes: Establish Authoritative Reference Data and Distribution; Resolve Data Authority Before Canonical Modelling.

Characterization should classify each relevant representation as authoritative, derived, replicated, synchronized, independently maintained, historical, or obsolete. Tests should establish transaction-type and category ownership, referential restrictions, synchronization direction, extraction and refresh behaviour, effective dating, runtime use, rollback, and rerun treatment. Deleting a transaction type referenced by a category should produce the confirmed restriction if that behaviour is active.

Data verification should preserve meaningful differences in keys, blanks, zeroes, signs, encodings, dates, monetary precision, statuses, and physical layouts. The relational and IMS authorization representations and the discrepancy between the IMS child layout and unload allocation require explicit reconciliation.

Acceptance requires an approved authority decision for every migrated representation, identified consumers, controlled version distribution, and detection of stale or divergent copies. Refresh latency and divergence tolerances remain decisions.

Related changes: CHG-012, CHG-015

VER-008 Verify Rehearsable Migration and Data Reconciliation

Changes: Build Rehearsable Migration and Reconciliation Pipelines.

Migration tests should exercise extraction, transfer, framing, decoding, transformation, loading, rejection, restart, restoration, cleanup, and rerun. Cases should cover fixed-width boundaries, blanks, zeroes, signs, delimiters, invalid dates, numeric precision, overflow, truncation, unknown record types, duplicates, compound keys, sequence discontinuities, cross-record relationships, and recreation of alternate indexes and access paths.

Evidence should include controlled source, extracted, transformed, loaded, rejected, and duplicate counts, together with referential, uniqueness, sequence, status-distribution, and applicable balance or financial reconciliation. Matching counts alone are insufficient. Tool completion must not prove that meanings, relationships, indexes, or access paths are correct.

Differences should be classified as explained and accepted, correction required, blocked by missing evidence, or unresolved. Unresolved differences affecting authoritative keys, financial values, security, customer continuity, or external effects block acceptance. The unexplained IMS layout and allocation discrepancy blocks affected migration until resolved. Numeric tolerances, checksum rules, and permitted rejection levels remain decisions.

Related changes: CHG-016

VER-009 Verify Batch, Reports, Statements, and Recovery

Changes: Rebuild Batch Workflows from Dependencies Rather Than Job Names; Preserve Reports and Statements Through Data Reconciliation; Prove Backup, Restore, and External-Effect Recovery.

Characterization should recover prerequisites, ordering, waits, checkpoints, completion signals, return-code handling, scheduler dependencies, file opening and closing, rerun rules, and outcomes for daily, weekly, and monthly processing. Tests should interrupt delete, define, replace, unload, reload, posting, and index-build operations at representative boundaries, then verify that restart neither duplicates nor omits work and does not expose partial data or inconsistent indexes.

Report and statement verification should compare approved content, totals, dates, sorting, formatting, distribution, and retained history. Visual similarity alone is insufficient. Backup evidence must include successful restoration and reconciliation of restored databases or files with queues, messages, reports, payments, and other external effects.

Acceptance requires a verified dependency model, restartable operations, reconciled outputs, and a rehearsed recovery runbook. Backup creation alone does not pass. Retention, distribution obligations, recovery time, recovery point, geo-recovery, and acceptable report differences remain decisions.

Related changes: CHG-013, CHG-014, CHG-019

VER-010 Verify Security and Operational Observability

Changes: Apply Least-Privilege Security and Sensitive-Data Controls; Introduce End-to-End Observability and SRE Operations.

Security verification should examine effective access to applications, datasets, databases, queues, file transfer, administrative functions, secrets, logs, and hybrid connections. It should demonstrate least privilege, managed identities where appropriate, encryption, secret rotation, network restrictions, protected logging, access review, and auditable privileged activity. Passwords, card-security values, sensitive personal data, and unnecessary payloads should not appear in telemetry.

Operational verification should correlate application, database, queue, workflow, migration, batch, and coexistence-adapter events sufficiently to diagnose a transaction or failed run without relying on sensitive payloads. Tests should cover alert delivery, dead letters, failed propagation, reconciliation differences, capacity warnings, restoration events, and ownership escalation.

Acceptance requires assigned operational and security ownership, actionable telemetry, protected logs, and tested incident and access-review procedures. Availability, latency, throughput, alert thresholds, retention, residency, key-management requirements, and escalation times remain decisions; no reliability or security improvement may be claimed before baselines and approved targets exist.

Related changes: CHG-017, CHG-018

VER-011 Verify Build, Release, Coexistence, and Retirement Controls

Changes: Automate Supported Build, Release, and Rollback Paths; Deliver Incrementally with Controlled Coexistence and Retirement.

Build verification should reproduce required compilation, precompilation, binding, link-editing, map generation, database change, infrastructure deployment, and generated-artifact handling for the accepted scope. It should detect conditional paths that bypass promotion or refresh, incompatible versions, malformed allocations, and unsupported dependencies. Compilation and deployment success are inputs to acceptance, not acceptance evidence.

Release tests should cover progressive deployment, backward-compatible contracts, database expansion and contraction, rollback to a prior supported release, and forward correction where rollback is unsafe. Each slice should rehearse coexistence routing, reconciliation, failure injection, support runbooks, and the last safe rollback point. In-flight work, consumed identifiers, emitted messages, audit records, and externally observed effects must be addressed explicitly.

Retirement acceptance requires identified consumers and dependencies, accessible retained records, accepted reconciliation, proven target restoration, active support ownership, satisfied retention duties, and ended fallback dependence. Unknown consumers, unresolved discrepancies, untested recovery, or continuing reliance on legacy reporting or recovery blocks retirement.

Related changes: CHG-020, CHG-021

VER-012 Verify Measures, Capacity Assumptions, and Final Acceptance Governance

Changes: Establish Measures Before Claiming Benefits; Plan Capacity, Scenarios, and Re-Estimation Without Invented Commitments.

The first accepted slice should establish collection methods for relevant measures such as change lead time, deployment frequency, failed-change rate, recovery time, incidents, unsupported components, vulnerability-remediation age, batch completion reliability, reconciliation differences, duplicate processing, dead-letter volume, restore-test success, access-review completion, latency, and availability. For every adopted measure, its baseline, target, owner, source, sampling period, exclusions, and review cadence require approval before benefit claims are made.

Capacity and acceptance planning should distinguish human effort, tool runtime, waiting time, and elapsed calendar time. Low, central, and high-complexity scenarios should be revisited using evidence from the first accepted slice and later rehearsals. Business calendars, freezes, outage tolerance, extract windows, shared environments, hybrid connectivity, licensing, suppliers, and scarce reviewers should be recorded as constraints when known rather than assumed.

Final acceptance for any slice requires approved scope, resolved or explicitly excluded contradictions, passed characterization and migration rehearsals, accepted security and privacy controls, assigned support ownership, tested restoration, approved reconciliation criteria, and rehearsed rollback or forward recovery. No deadline, budget, staffing level, outage allowance, production suitability, or benefit is established by this proposal.

Related changes: CHG-022, CHG-023