Modernisation proposal for review; durations are indicative.

verification-and-acceptance.md

This is an unapproved verification-and-acceptance proposal. It does not approve architecture, migration, release, production activation, retirement, staffing, cost, outage, service level or business-rule change. The proposed tests have not been executed.

Verification must distinguish observed legacy behaviour, intended requirements, accepted changes, defects and unresolved decisions. Passing selected tests would establish evidence only for the exercised versions, configurations, data and paths; it would not establish semantic completeness, production equivalence or fleet-wide coverage. Existing interfaces, data meanings, workflow asymmetries, status and error behaviour, localized text, ordering, persistence timing, audit intent, event timing, documents and reports remain compatibility constraints until accountable owners accept a change.

Acceptance records should identify the environment, deployed versions, configuration, database and migration state, representative data, dependencies, procedure, expected and observed outcomes, discrepancies, decision owners and recovery result. Thresholds for performance, availability, reconciliation, recovery, observation periods, security findings and operational errors are not supplied and remain approval decisions.

VER-001 Verify the Executable Baseline and Compatibility Catalogue

Changes: Recover the Executable and Operational Baseline; Establish Compatibility Characterization.

Characterization should demonstrate a reproducible build and deployment, then inventory active routes, middleware, registrations, handlers, validators, database objects, background work, files, reports, templates, integrations, configuration sources and operational dependencies. At least one representative journey should be traced from request and identity through authorization, validation, persistence, audit, event, file or external effect, response and failure handling. Successful, denied, malformed, stale, repeated and dependency-failure paths should be observed without assuming that compilation or existing test success proves runtime behaviour.

Migration evidence should show that the recovered baseline can be deployed repeatedly without intentional business change and that configuration and schema state are controlled. Comparisons should cover request and response shapes, status codes, validation and localized messages, null and empty results, ordering, save timing, navigation and external side effects. Unknown callers or production-only behaviour must remain visible exceptions rather than being declared compatible.

Security evidence should identify authentication schemes, reachable anonymous paths, identity resolution, secret sources and authorization enforcement points on the traced journey. Resilience evidence should include deployment recovery and restoration of a non-production backup, with failures and manual dependencies recorded.

Acceptance requires accountable review of the inventory, executable demonstration, compatibility catalogue, unresolved gaps and discrepancy classifications. Runtime support, topology, operational ownership and all quantitative acceptance thresholds remain decisions.

Related changes: CHG-001, CHG-002

VER-002 Verify Modular Deployment and Reversible Delivery

Changes: Introduce an Incremental Modular Deployment Model; Deliver Through Reversible, Independently Verifiable Slices.

Characterization should identify current coupling among notification, movement, party, route, classification, finance, guarantee, document, reporting and audit concerns, including direct database writes and synchronous caller expectations. It should establish where import, export and transit behaviour differs and therefore cannot safely be generalized.

Migration evidence should demonstrate one bounded slice behind a compatibility interface, with a single authoritative writer, controlled activation and a documented rollback or forward-recovery path. Cross-boundary writes should be detected and prohibited according to the proposed modular rules. Any use of feature flags should demonstrate restricted administration, audit, safe defaults and a removal decision.

Security evidence should show that deployment boundaries do not bypass existing resource authorization or expose new administrative surfaces. Resilience evidence should exercise failed deployment, partial activation, dependency outage and recovery without uncontrolled dual writes or duplicate external effects.

Acceptance requires preservation of characterized interfaces and business asymmetries, successful reconciliation for the selected cohort and an approved authority boundary. Selection among Azure App Service, Azure Container Apps and bounded Azure Functions remains conditional on runtime, operating-system, networking and workload evidence. Independent deployment is not itself evidence that a separate service is required.

Related changes: CHG-003, CHG-021

VER-003 Verify Lifecycle and Identifier Contracts

Changes: Formalize Notification and Assessment Lifecycles; Separate Movement, Shipment, Receipt and Outcome Rules; Define Identifier Allocation and Lookup Contracts.

Characterization should capture observed notification, assessment, movement, shipment, receipt, rejection, recovery, completion and cancellation states and transitions by actor and workflow. It should explicitly test the submitted-versus-awaiting-payment contradiction, receipt-versus-rejection precedence, partial rejection, withdrawal, resubmission, unlocking, prohibition, archive, closure, cancellation and deletion. Enum order must not be used as evidence of lifecycle order.

Identifier characterization should cover normalization, visible formatting, malformed and unmatched lookup results, authority scope, movement-number allocation, shipment bounds and concurrent requests. Existing database constraints and locking should be observed rather than inferred.

Migration evidence should compare legacy and proposed transitions for state, editability, persisted records, audit entries, events, responses and failures. Concurrency tests should exercise duplicate and stale commands, simultaneous identifier allocation, repeated submissions, failed saves and bulk-operation interruption. No target state machine or uniqueness constraint should be activated while the underlying business decisions remain unresolved.

Security evidence should verify actor, ownership, organisation, authority and lifecycle-state checks for every exercised transition. Resilience evidence should show deterministic handling of retries, transaction failures and event failures without duplicate identifiers or concealed partial outcomes.

Acceptance requires an approved transition contract and identifier contract, with accountable decisions for all contradictory states and outcome rules. Unknown timing, concurrency and discrepancy thresholds remain decisions.

Related changes: CHG-004, CHG-005, CHG-006

VER-004 Verify Party Relationships and Authorization Enforcement

Changes: Centralize Authoritative Party and Relationship Checks; Implement Centrally Testable Authorization Policies; Resolve Identity, Authentication and Secret Management.

Characterization should build an action-resource matrix for external owners, shared users, assessors, authorities, administrators, read-only users, service clients and unauthenticated callers. It should trace organisation, ownership, membership, authority, facility, treatment-site and lifecycle checks through all actual enforcement layers. Posted and hidden relationship values should be tampered with to establish whether the server reloads authoritative records.

Migration evidence should compare allowed and denied outcomes before and after each bounded policy activation. Tests should cover reassignment, ownership transfer, deletion, guarantee decisions, finance changes, archive, sharing, files, reports, administration and account operations where those actions are present. State-changing retrieval operations should be characterized before replacement with protected non-GET commands.

Security evidence should cover bearer and cookie precedence, claims transformation, malformed and missing claims, inactive users, token refresh, service credentials, password reset, email verification, temporary state and secret access. Any auto-confirmation or attacker-influenced deserialization should receive direct investigation. Least-privilege access through managed identities and protected secret storage should be demonstrated where adopted, not assumed from configuration.

Resilience evidence should exercise identity-provider unavailability, expired credentials, key rotation and cross-node temporary-state behaviour. Acceptance requires tested deny paths, absence of reliance on client controls, an approved identity lifecycle and authorization matrix, and preservation of user-to-business relationships. External identity platform choice, dual-control requirements and denial-rate thresholds remain decisions.

Related changes: CHG-007, CHG-008, CHG-009

VER-005 Verify Dates, Quantities and Financial Calculations

Changes: Establish Authoritative Date and Calendar Semantics; Define Quantity, Unit and Rounding Contracts; Isolate Finance, Pricing, Payments and Refunds.

Characterization should preserve workflow-specific results while exercising every evidenced boundary around calendar days, working days, consent periods, movement windows, receipt and recovery ordering, report ranges, payments and refunds. Tests should distinguish date-only values from processing timestamps and cover timezone changes, holidays, inclusivity, malformed values, backdating and future dates.

Quantity evidence should cover tonnes, kilograms, litres and cubic metres; positive, zero, negative, null, missing and incomplete values; precision, conversion order, rounding, overflow, mixed units, consent limits, active loads and rejection effects. Financial evidence should cover credits, debits, balances, cleared amounts, refunds, effective dates, overlapping prices, missing prices, currency, precision, tax where applicable and records containing both credit and debit.

Migration evidence should provide record-level legacy-to-target comparisons using authoritative business inputs rather than display values. Differences should be classified rather than hidden by aggregate equality. Heuristic unit conversions and conflicting calculator behaviour must not be declared equivalent.

Security evidence should verify that posted dates, quantities, prices, payment values and refund values are reloaded or validated server-side and cannot be changed through hidden or stale inputs. Resilience evidence should cover retry and concurrency around payments, refunds and pricing selection without duplicate financial effects.

Acceptance requires approved calendar, conversion, precision, rounding, pricing and refund contracts. Legal, policy, finance and business owners must decide conflicting rules. No tolerance, monetary discrepancy, latency or calculation-equivalence threshold is currently supplied.

Related changes: CHG-010, CHG-011, CHG-012

VER-006 Verify Guarantees, Routes and Reference Meanings

Changes: Resolve Guarantee Cardinality and Decision Semantics; Preserve Route, Waste and Reference-Data Meaning.

Characterization should profile guarantee histories, multiple approved records, references, active loads, completion, approval, refusal, release and supersession. Concurrent approvals, self-approval possibilities, failed decisions and matching-versus-different-reference behaviour should be observed. Commented-out limits must not be treated as requirements.

Route and classification characterization should cover transit positions, permutations, gaps, resequencing, no-transit flags, countries, entry and exit points, authorities, customs offices, transport methods, route multiplicity and facility cardinality. Waste, recovery, disposal, packaging, obsolete codes and the distinctions among standard, custom, not-listed and not-applicable values should be retained.

Migration evidence should show deterministic preservation of historical codes, identities, ordinals and guarantee decisions. Invalid or ambiguous records should be retained as rejected or unresolved records rather than silently deduplicated, normalized or reclassified.

Security evidence should test authority and ownership checks for guarantee decisions and reference-data administration. Resilience evidence should exercise simultaneous guarantee decisions, failed persistence, interrupted resequencing and replay without losing history or producing multiple unintended active records.

Acceptance requires approved guarantee cardinality, decision semantics, route completeness, facility and treatment-site rules and reference-data ownership. Until those decisions exist, new uniqueness or normalization constraints must not be accepted.

Related changes: CHG-013, CHG-014

VER-007 Verify Files, Scanning and Generated Documents

Changes: Secure Uploads, Downloads and Generated Documents.

Characterization should record current upload, download, scanning and generation behaviour, including filenames, metadata, authorization, templates, annexes, block ordering, visible content, repeated generation and failure responses. It should cover clean, virus, unknown and error scanner outcomes, plus timeout, outage, malformed content, null collections, missing entities, duplicate ordinals and output collisions.

Migration evidence should compare source and target file metadata, bytes where meaningful, versions, ownership, retention state and generated document appearance. A proposed private Azure Blob Storage path should retain relational authority for ownership and authorization. Quarantine and promotion should be demonstrated with agreed size, content, signature and malware controls. Interrupted transfer and rerun should not create untracked or unauthorized files.

Security evidence should test upload and download authorization, path and filename handling, content-type deception, unsafe active content, sensitive error disclosure and scanner bypass. Resilience evidence should cover scanner outage, conversion failure, temporary-file cleanup, orphan reconciliation, repeated requests and restoration from retained source material.

Acceptance requires document comparison by accountable consumers and approved handling for unknown or unavailable scan results. Size limits, scanner selection, retention, legal hold, rescanning, cleanup timing and visual-difference tolerances remain decisions.

Related changes: CHG-015

VER-008 Verify Durable Effects, Transactions and Audit

Changes: Introduce Durable Integration Delivery; Strengthen Transaction, Concurrency and Audit Boundaries.

Characterization should trace representative mutations across database writes, audits, files, caches, email, events and external services. It should establish observed dispatch timing, transaction boundaries, retry behaviour and whether audit records represent attempted, denied, failed or successful actions.

Migration evidence should demonstrate atomic business persistence where required and durable recording of integration intent where a transactional outbox is adopted. Consumers should tolerate duplicates, preserve required ordering and expose retry, replay and dead-letter outcomes. Existing synchronous responses must remain synchronous where characterized callers require them.

Security evidence should verify authorization before business mutation and external effect, least-privilege publisher and consumer access, protected replay authority and separation of security audit, business history and diagnostic telemetry. Resilience evidence should exercise failed saves, process termination after commit, duplicate delivery, out-of-order messages, poison messages, external timeout, replay and reconciliation.

Acceptance requires record-level proof that no exercised failure creates an unexplained business change, missing required audit, uncontrolled duplicate effect or irreconcilable message. Retry limits, ordering scope, dead-letter age, event-delivery timing and operational ownership remain decisions.

Related changes: CHG-016, CHG-018

VER-009 Verify Reports and Operational Readiness

Changes: Separate Reporting Read Models Without Changing Outputs; Establish Azure Observability and SRE Operations.

Characterization should capture report columns, aliases, workbook structures, ordering, status derivation, null handling, date boundaries, unit treatment, authorization, cache behaviour and differences between import and export logic. Representative small, empty and large results should be retained for comparison without assuming that these samples cover all consumers.

Migration evidence should compare legacy and proposed reports at record, field and presentation level. Expected transformations must be separated from source anomalies, target defects and unresolved discrepancies. Any read model or replica should demonstrate its refresh, freshness and reconciliation behaviour before user-visible activation.

Security evidence should verify report access by identity, organisation, authority and ownership and should check exports for sensitive-data leakage and spreadsheet-formula risks. Operational telemetry should correlate requests, database work, outbox processing, messages, dependencies and report refresh without logging inappropriate secrets or personal data.

Resilience evidence should exercise dependency outage, stale read models, report divergence, stuck queues, orphaned files, deployment failure and backup restoration. Runbooks should identify detection, containment, recovery, escalation and reconciliation steps.

Acceptance requires accountable consumer review of report comparisons, operational ownership of alerts and demonstrated restore procedures. Availability, performance, report freshness, telemetry retention, support hours, recovery-time and recovery-point objectives remain decisions.

Related changes: CHG-017, CHG-020

VER-010 Verify Deterministic Data Migration and Recovery

Changes: Profile and Migrate Data Deterministically.

Characterization should profile nulls, duplicates, orphans, invalid references, status combinations, multiple approved guarantees, relationship cardinalities, route ordinals, units, decimal precision, collation, whitespace, obsolete values, business keys, historical lookup identities and records excluded by joins. Applied migration state and database-provider dependencies should be recorded.

Migration evidence should use business-readable transformation rules with deterministic mappings, preserved source evidence, retained rejects, checkpoints and defined rerun behaviour. Reconciliation should include meaningful source-to-target counts, business-key matches, referential checks, lifecycle and history continuity, party relationships, files, audits, guarantee history, reports and valid financial or quantity comparisons. Aggregate equality alone is insufficient.

Security evidence should protect extracts, migration credentials, rejected records and production-like rehearsal data through least privilege, encryption, access logging and approved disposal or retention. Resilience evidence should exercise preflight rejection, interruption, checkpoint restart, rerun, restoration and forward correction. Reverse migration should be claimed only where target activity can be represented safely in the legacy model.

Acceptance requires classified and owned discrepancies, business and data-owner sampling, demonstrated restore and an approved rollback or forward-recovery decision. Selection between Azure SQL Database and Azure SQL Managed Instance remains conditional on compatibility evidence. Permitted discrepancy levels, recovery duration and retention periods remain decisions.

Related changes: CHG-019

VER-011 Verify Cutover, Coexistence and Retirement

Changes: Deliver Through Reversible, Independently Verifiable Slices; Profile and Migrate Data Deterministically; Establish Azure Observability and SRE Operations.

Characterization should identify every affected caller, scheduled job, report, file flow, queued item, cache and external effect, along with the authoritative system for each migrated cohort. Writes near the cutover boundary, in-flight requests, stale sessions and concurrent edits should be exercised.

Migration evidence should include a production-like rehearsal of preflight, migration, reconciliation, controlled routing, observation, rollback where safe and forward recovery where rollback would lose accepted activity. Shadow processing must demonstrate that it cannot allocate identifiers, send correspondence, create payments or mutate authoritative records.

Security evidence should confirm approved cutover access, protected credentials, tested denial paths and containment procedures for an authorization defect. Resilience evidence should cover deployment rollback, database restoration, message replay, file-transfer interruption, external dependency timeout and reconciliation after recovery.

Acceptance requires approved write boundaries, cutover authority, communications, support arrangements, backup and restore evidence, measurable activation and rollback triggers, and no unresolved high-impact discrepancy. Retirement additionally requires confirmed caller transition, accepted observation, retained audit and historical access, recovery independence and approved retention and deletion rules. Downtime, observation duration, error thresholds and change-freeze constraints remain decisions.

Related changes: CHG-021, CHG-019, CHG-020

VER-012 Verify Measures, Scenarios and Approval Gates

Changes: Establish Measures, Scenarios and Approval Gates.

Characterization should establish data sources and calculation methods for candidate indicators such as deployment frequency, change lead time, failed-change rate, restoration time, availability, security findings, unsupported dependencies, restore success, dead-letter age, reconciliation differences, authorization-test coverage and incidents. Current values must be measured rather than inferred.

Migration and delivery evidence should separate human effort, automated-agent runtime, supplier and reviewer waiting time, environment contention and elapsed calendar time. The first accepted slice should provide observations for subsequent low, central and high scenarios, capacity assumptions, contingency and re-estimation. These scenarios must not be presented as commitments.

Security evidence should include unresolved high-impact findings, policy-test outcomes and approval dependencies. Resilience evidence should include restore-test outcomes, recovery observations, queue and reconciliation health and runbook execution.

Acceptance requires an approved owner, baseline, target, source, sampling period and calculation method for every adopted measure. Architecture and production gates also require resolved domain and authorization contracts, data profiles, interface inventory, service-level decisions, threat and privacy review, Azure option validation, operational ownership, cost assessment and demonstrated migration and recovery. Until those decisions and observations exist, benefit, readiness, schedule and delivery-capacity claims remain unverified.

Related changes: CHG-022