Source-derived document; review findings and open questions with the application owner.

12. Recovered requirements: current IWS system

In this document

12.1 Business purpose and scope

The application is identified as the International Waste Shipments (IWS) Service. Its stated business purpose is to manage compliance-related information for shipping waste into or out of the country. The available source describes notification applications, assessments, movements, shipments, waste and recovery data, competent authorities, carriers, facilities, financial guarantees, documents, reporting and user administration. This is a recovered description of the represented domain, not proof that every component is deployed in the same runtime boundary. [[LRG-02-0002-cba7f9acf83a4290::claim::APP-CLM-001]] Provenance gap: artifact/source reference unresolved.[[LRG-02-0001-781f4f335c5c1c9b::claim::APP-CLAIM-002]] Provenance gap: artifact/source reference unresolved.

The principal actors evidenced by the source are external users associated with notifications, internal users or competent-authority staff, administrators, and system integrations. Internal users are checked against competent-authority access; external users are checked against ownership or sharing for export notifications, while non-internal access to import notifications is denied by the observed authorization components. E0182

The system also interacts with an identity/token service, email infrastructure, document-generation components, virus-scanning functionality, SQL Server-backed repositories and stored procedures, and reporting objects. These relationships are evidenced at source or configuration level, but deployment ownership and production boundaries remain partly unknown. E0011E0244E0412E0414

Source-derived diagram. Some relationships may be inferred and require review.

Preparing diagram…

View Mermaid diagram source

flowchart LR
    External[External user] --> Web[Web/API request]
    Internal[Internal user] --> Web
    Web --> Domain[Notification and movement domain]
    Domain --> Data[(Repositories / SQL Server)]
    Domain --> Email[Email handlers]
    Domain --> Docs[Document generation]
    Web --> Auth[Identity and authorization]
    Auth --> Token[Identity service]
    Docs -. production rendering/use unresolved .-> Data

12.2 Notification and assessment lifecycle

The notification model represents statuses including NotSubmitted, Submitted, NotificationReceived, InAssessment, ReadyToTransmit, Transmitted, DecisionRequiredBy, Consented, FileClosed, Resubmitted, UnderProhibition, and InDetermination. These values establish the vocabulary of the current system, but not a complete linear state machine. E0006

The strongest available lifecycle evidence comes from unit tests for NotificationAssessment. A new assessment is expected to start in NotSubmitted. Submission requires notification progress to be complete; a successful submission changes the status to Submitted and raises notification status-change and submission events. Duplicate submission is rejected. Receipt is permitted from Submitted and records a received date. Commencement requires receipt and a payment-received date, then changes the status to InAssessment. Later operations cover completion, transmission and acknowledgement through ReadyToTransmit, Transmitted and DecisionRequiredBy. E0279

The same tests evidence additional transitions. Consent can be withdrawn with a date and reason; transmitted or decision-required work can be unlocked; consent and reassessment can be resubmitted under tested conditions; and decision-made states can be closed. Prohibition can be entered from each listed non-prohibition state and lifted back to listed prior states. The evidence does not justify saying that prohibition is reachable from literally every possible state, because the test set does not include UnderProhibition itself in its “any state” list. E0279

REQ-12-NOT-001 — Submit a complete notification.
When a notification is submitted, the current system shall permit submission only when the tested progress-completion condition is satisfied, reject duplicate submission, set the assessment status to Submitted, and raise the status-change and notification-submitted events.

REQ-12-NOT-002 — Receive and commence assessment.
The current system shall permit receipt from Submitted, record a received date, and permit commencement only after receipt and payment receipt have been recorded; successful commencement shall set status to InAssessment.

REQ-12-NOT-003 — Preserve tested assessment transitions.
The current system shall support the tested completion, transmission, acknowledgement, consent-withdrawal, unlock, resubmission, prohibition and file-closure operations, subject to their observed source guards. The evidence does not establish equivalent rules for every status combination.

Characterisation scenario candidate — submission

Given an assessment whose status is NotSubmitted and whose notification progress is complete
When the user submits the notification
Then the status becomes Submitted, submission and status-change events are raised, and a second submission is rejected.

Open question for Harten: The inspected artifact NotificationAssessmentStatusTests.cs establishes selected transitions but not the complete state matrix. Evidence needed: the full NotificationAssessment implementation, all status-transition tests, and production handler/controller integration tests.

12.3 Movement receipt and completion

Movement processing represents captured, submitted, received, completed, rejected, cancelled and partially rejected states. The source distinguishes external and internal receipt/completion paths. The domain applies selected guards involving dates, quantities, file identifiers and current state. [[LRG-02-0001-781f4f335c5c1c9b::claim::BR-CLAIM-002]] Provenance gap: artifact/source reference unresolved.[[LRG-02-0001-781f4f335c5c1c9b::rule::MOVEMENT-GUARDS]] Provenance gap: artifact/source reference unresolved.

The available evidence does not establish the complete movement workflow. In particular, it does not show whether all external and internal paths apply identical guards, how partial rejection affects remaining quantities, or which state is written when a handler fails. Repository evidence shows explicit movement deletion and update paths, but repository-level authorization is inconsistent and callers or stored procedures may provide additional controls. E0414

REQ-12-MOV-001 — Guard receipt and completion.
When a movement receipt or completion operation is requested, the current system shall apply the observed date, quantity, file-identifier and state-transition guards before changing movement data.

REQ-12-MOV-002 — Represent movement outcomes.
The current system shall represent the observed receipt/completion outcomes, including rejection, cancellation and partial rejection, and shall distinguish the external and internal operation paths where separate handlers exist.

Characterisation scenario candidate — receipt

Given a submitted movement with valid receipt data
When an authorized receipt operation is submitted
Then the movement enters the received state and the receipt data is persisted.

The final step is a candidate because the supplied evidence establishes the domain vocabulary and selected guards, but not the complete persistence outcome.

Open question for Harten: The inspected artifacts Movement domain evidence and MovementRepository.cs do not establish all transitions or transaction behavior. Evidence needed: external/internal receipt and completion handlers, movement entity methods, stored procedures, and integration tests covering valid, invalid and partial-rejection cases.

Assessment processing includes consent with a date range, conditions and a consent date. Financial-guarantee operations include creation, approval, refusal and release. The observed request handlers persist selected operations, but the evidence does not establish the complete eligibility, authorization or downstream decision policy. [[LRG-02-0001-781f4f335c5c1b9::claim::BR-CLAIM-003]] Provenance gap: artifact/source reference unresolved.[[LRG-02-0001-781f4f335c5c1b9::rule::ASSESSMENT-DECISION-RULES]] Provenance gap: artifact/source reference unresolved.

REQ-12-ASS-001 — Record consent decisions.
When consent is granted, the current system shall accept and persist the evidenced consent date range, conditions and date, subject to the handler and domain guards currently implemented.

REQ-12-FG-001 — Process guarantee decisions.
The current system shall expose operations for creating, approving, refusing and releasing financial guarantees. Each operation shall invoke the corresponding observed domain or handler operation and persist its selected result.

Characterisation scenario candidate — consent

Given an assessment eligible for consent
When an authorized decision-maker records consent with a valid date range and conditions
Then the consent details are saved and the assessment follows the applicable consent status transition.

Eligibility and the resulting status require confirmation from the full implementation.

Open question for Harten: The inspected handlers NotificationAssessment and financial-guarantee request handlers show selected persistence calls but not the complete policy. Evidence needed: authorization services, domain methods, database mappings, event handlers and end-to-end decision tests.

12.5 Authorization, deletion and exceptional behaviour

Authorization intent is expressed through request attributes, bearer-token configuration, controller filters, ownership checks and competent-authority checks. However, the source does not establish effective enforcement for every endpoint, mutation, download, deletion or client-supplied identifier path. [[LRG-02-0001-781f4f335c5c1c9b::rule::RULE-001]] Provenance gap: artifact/source reference unresolved.E0054

A particularly important current-system exception is export-notification deletion. The controller first retrieves notification details and checks whether deletion is allowed. If the lookup returns null, the visible condition is skipped and the code subsequently accesses notificationDetails.NotificationId, permitting a possible NullReferenceException. The POST also accepts a client-supplied notification identifier; notification ownership, current deletability and correspondence with the earlier lookup are not demonstrated in the controller excerpt. E0105

REQ-12-AUTH-001 — Authorize protected operations.
For requests carrying authorization metadata, the current system shall evaluate the configured authentication, ownership, sharing or competent-authority checks before performing the protected operation. Effective coverage remains to be verified per endpoint.

REQ-12-DEL-001 — Handle unresolved deletion lookups.
If an export-notification deletion lookup returns no notification, the current system should return a controlled not-found or validation result rather than dereferencing the missing result. This is a recovered corrective requirement based on an observed exception path, not evidence that the correction already exists.

Open question for Harten: The inspected artifacts DeleteExportNotificationController.cs, AuthorizationService.cs and AuthorizationContextExtensions.cs do not establish the effective runtime security boundary. Evidence needed: the relevant attributes and handlers, route registration, integration tests, and deployed authorization configuration.

12.6 Documents, notifications and operational exceptions

Movement-document generation orders document blocks by OrdinalPosition, calls Merge() for each block, and calls GenerateAnnex(i) for annex-capable blocks whose HasAnnex value is true. Carrier, facility and customs-office blocks intentionally split main-document and annex work. Facility generation has a specific rule for two facilities and requires exactly one actual site. [[LRG-02-0001-781f4f335c5c1c9b::claim::OBSERVED-DOCUMENT-MERGE-PIPELINE]] Provenance gap: artifact/source reference unresolved.E0457

REQ-12-DOC-001 — Merge movement documents.
The current system shall merge document blocks in ordinal order and generate annexes only for annex-capable blocks marked as requiring an annex.

Document template validity, successful production rendering, persistence and transmission are not established. Missing merge fields, unexpected table structure, duplicate actual sites or repeated annex generation can cause exceptions according to the inspected code. E0457

Email handlers construct approval and rejection notifications using named templates and approval links. This evidences message construction and selected notification flows, but not successful SMTP delivery in production. [[LRG-02-0002-cba7f9acf83a4290::claim::APP-CLM-005]] Provenance gap: artifact/source reference unresolved.

Virus scanning supports HTTP scanning with a bearer token and file-based scanning through temporary files. Results include Unknown, Clean, Virus and Error; tests cover clean and virus outcomes and selected write/deletion exceptions. The scanner API exposes an anonymous GET health-style action while its POST scan action is authorized, so authorization depends on HTTP method. [[LRG-02-0002-cba7f9acf83a4290::claim::APP-CLM-008]] Provenance gap: artifact/source reference unresolved.E0412

Open question for Harten: The inspected document-generation, email and virus-scanning artifacts establish component behavior but not production operation. Evidence needed: deployed templates, SMTP and scanner configuration, route-level integration tests, and operational logs showing successful generation, delivery and scanning.

Contains public sector information licensed under the Open Government Licence v3.0. Original public repository. This independent Harten analysis was not commissioned, approved or endorsed by DEFRA or the Environment Agency.

Analysed source-archive hash is recorded; its exact upstream Git commit has not been established. The generated material does not establish complete requirements, operational security or functional equivalence.