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

Phase 4 — Understanding and handoff

Purpose and scope

The International Waste Shipments (IWS) Service supports the preparation, assessment, approval, movement, and closure of waste-shipment notifications. The source evidence represents notification and movement data, competent authorities, carriers, facilities, customs offices, waste operations, financial guarantees, documents, users, and reporting structures. This establishes the business domain represented by the system, but not every production boundary or deployment responsibility. E0054 E0459 E0316

This chapter describes the current system as evidenced by source analysis. Observed means the cited code or tests directly demonstrate the behaviour. Inferred means the behaviour is a reasonable interpretation of the evidence but is not proved end to end. Unknown means that the supplied evidence does not establish the behaviour; omitted evidence must not be treated as evidence of absence.

Provenance gap: This passage has no artifact/source citation.

Actors and system responsibilities

The principal actors represented in the current system are:

Provenance gap: This passage has no artifact/source citation.

• external notification users, including exporters, importers, producers, carriers, and other shared users;
• internal users and competent-authority staff;
• administrators managing users, notifications, and archival operations;
• services responsible for scanning, email, document generation, and API integration; and
• persistence and reporting components.

Provenance gap: This passage has no artifact/source citation.

The application distinguishes internal users from external users in notification authorisation. Internal users are checked against the notification’s competent authority. External users are checked against ownership or sharing for export notifications, while non-internal users are denied access to import-notification applications. E0182

Authorization intent is also attached to request contracts. Read requests commonly declare export-notification read permission; mutations commonly declare edit permission together with read-only protection; deletion and unauthorised feedback are represented as special cases. This is observed declaration-level behaviour, not proof that every invocation path enforces the declared attributes. E0054

The web and API layers provide request entry points, while mediator-style requests and handlers coordinate domain operations and persistence. The supplied evidence shows asynchronous request handling, repositories, Entity Framework-based access, stored procedures, mappings, and selected transaction paths. It does not establish the complete runtime topology. E0105 E0414

flowchart LR
    User[External or internal user] --> Web[Web/API request]
    Web --> Request[Request contract and handler]
    Request --> Domain[Domain operation]
    Domain --> Data[(Persistence/reporting)]
    Domain --> Notification[Email/document/scanning services]
    Web -. unresolved endpoint coverage .-> Auth[Authorization enforcement]

Main triggers and current workflows

A notification is created through a multi-step controller flow. The tested sequence selects a competent authority, accepts a notification type, and redirects through creation-related pages. Invalid model state returns the user to the relevant view. These tests demonstrate controller expectations, but they do not prove that the notification is persisted or establish the exact meaning of the “Created” page. E0494

A notification assessment has an explicit domain lifecycle represented in tests. The default state is NotSubmitted. Submission requires notification progress to be complete; successful submission changes the status to Submitted and raises status-change and submission events. Receipt is permitted from Submitted, records a received date, and changes status. Commencement requires receipt and a payment-received date, then moves the assessment to InAssessment. Completion, transmission, and acknowledgement are tested as an ordered progression toward DecisionRequiredBy. E0279

The lifecycle is not a simple numeric progression. Tests also cover consent withdrawal, unlocking, resubmission, reassessment, rejection of changes, and closure from decision-made states. Prohibition can be entered from each listed non-prohibition state, but the evidence does not justify the stronger statement that it can be entered from literally every possible state. Editability is only tested for a subset of statuses. E0279

Requirement statements

The following identifiers describe current-system behaviour supported by the evidence:

Provenance gap: This passage has no artifact/source citation.

• REQ-16-01 — Notification submission: The system shall prevent assessment submission when notification progress is incomplete; when progress is complete, submission shall change the assessment status from NotSubmitted to Submitted and raise the tested submission events. Observed in unit-test expectations; production conformance unknown. E0279
• REQ-16-02 — Notification receipt: The system shall permit receipt from Submitted, record a received date, and change the assessment status. Observed in tests; the complete date-validation policy is unknown. E0279
• REQ-16-03 — Assessment commencement: The system shall require NotificationReceived and a payment-received date before commencing assessment, then move the assessment to InAssessment. Observed in tests. E0279
• REQ-16-04 — Editability: The system shall allow editing in the tested states NotSubmitted, Submitted, NotificationReceived, InAssessment, and Unlocked, and shall reject editing in ReadyToTransmit, Transmitted, DecisionRequiredBy, and UnderProhibition. Observed only for the listed states; policy for other statuses is unknown. E0279
• REQ-16-05 — Movement receipt and completion: The movement domain shall represent captured, submitted, received, completed, rejected, cancelled, and partially rejected outcomes, with distinct external and internal receipt/completion paths. Selected date, quantity, file-identifier, and transition guards shall apply. Observed domain representation and selected guards; complete parity between paths is unknown. E0105
• REQ-16-06 — Consent and financial guarantees: Assessment processing shall support consent with a date range, conditions, and date, and shall expose financial-guarantee creation, approval, refusal, and release operations. Observed handler operations; eligibility, authority, and downstream effects are unknown. E0105
• REQ-16-07 — Document assembly: Movement documents shall merge document blocks in ordinal order and generate annexes for annex-capable blocks when HasAnnex is true. Observed in MovementDocument.Merge; production template validity and rendering are unknown. E0457
• REQ-16-08 — Notification access: Requests that declare notification read, edit, or ownership permissions shall be subject to the corresponding authorization mechanism. Observed as intended metadata and selected repository checks; effective enforcement for every endpoint is unknown. E0054 E0182

State and data changes

Assessment state changes are accompanied by dates and events in the tested domain model. Submission, receipt, commencement, transmission, acknowledgement, consent, withdrawal, reassessment, and closure each have associated state or date effects in the test-derived contract. The evidence does not establish whether these changes are always persisted atomically with event dispatch. E0279 E0173

Movement processing records receipt and completion-related outcomes, quantities, dates, file identifiers, and rejection information. The domain includes separate external and internal paths, but the supplied material does not establish whether both paths apply identical guards or whether all status combinations are rejected consistently. E0105

Repositories provide selected persistence behaviour. For example, archiving invokes a parameterized archive stored procedure inside an explicit database transaction, commits on success, rolls back on exception, and returns an initial "false" value rather than visibly rethrowing the exception. Draft movement bulk upload also uses an explicit transaction and rolls back before rethrowing on failure. E0302

Domain-event timing is more qualified than a general statement that events are asynchronous. The synchronous save path blocks on event dispatch through Task.Run(...).Wait(), while the asynchronous save path awaits dispatch after the base save completes. This indicates post-save dispatch, but does not establish an outbox, retry, idempotency, or rollback mechanism. E0173

Exceptions and operational edge cases

The deletion flow contains a possible null dereference. The controller retrieves notification details, handles the case where the notification is not deletable, but then accesses notificationDetails.NotificationId if the lookup returned null. The mediator contract might guarantee a non-null result, but that guarantee is not shown. E0105

Client-posted identifiers are also material to deletion and notification switching. The visible controllers do not themselves prove that a posted notification ID belongs to the current user, matches the earlier lookup, or remains deletable at POST time. Downstream authorization may provide those protections, but the supplied controller evidence does not establish it. E0105

Notification-number lookup normalizes uppercase and removes ordinary spaces, then applies a regex that is not anchored at the beginning and end. A string containing a matching substring could therefore pass the visible test. The handler also catches Exception around authorization and returns null, potentially suppressing database or programming errors as well as authorization failures. E0008

Document generation is sensitive to template structure and data invariants. The implementation uses strict lookups such as Single() and First(). Facility annex generation requires exactly one actual facility; zero or multiple actual facilities cause an exception. It also mutates its internal facility list by removing the actual site, so repeated invocation may not be idempotent. E0457

Virus scanning has method-specific exposure. The scanner controller is authenticated, but its GET /Scan action is explicitly anonymous and returns "ok"; the POST /Scan action invokes file scanning. Therefore, the route cannot be described simply as authenticated without distinguishing HTTP methods. E0412

Characterisation scenarios — candidates for confirmation

These are not claims that the tests have been run; they are candidate scenarios for preserving current behaviour during handoff.

Provenance gap: This passage has no artifact/source citation.

Scenario: Submit a complete notification
  Given an assessment is in NotSubmitted
  And notification progress is complete
  When the user submits the notification
  Then the status becomes Submitted
  And submission events are raised

Scenario: Reject commencement without payment
  Given an assessment is in NotificationReceived
  And no payment-received date exists
  When commencement is requested
  Then commencement is rejected
  And the assessment remains in NotificationReceived

Scenario: Anonymous scanner health check
  Given a request uses GET /Scan
  When no authenticated identity is supplied
  Then the service returns HTTP 200 with "ok"

Scenario: Invalid facility annex data
  Given a facility document block has zero or multiple actual facilities
  When the annex is generated
  Then the operation fails rather than selecting an arbitrary facility

Open questions for Harten

Open question for Harten: Is notification deletion re-authorized and state-checked using the posted identifier at POST time? Inspected artifact: DeleteExportNotificationController.cs in E0105. Evidence needed: the DeleteExportNotification handler, AuthorizeActivity implementation, repository authorization, and an integration test using a mismatched or stale identifier.

Provenance gap: This passage has no artifact/source citation.

Open question for Harten: Are external and internal movement receipt/completion paths governed by identical guards? Inspected artifact: movement domain evidence summarized in E0105. Evidence needed: both path implementations and tests covering dates, quantities, file identifiers, status transitions, and invalid combinations.

Provenance gap: This passage has no artifact/source citation.

Open question for Harten: What happens when domain-event dispatch fails after persistence? Inspected artifact: ContextBase.SaveChanges and SaveChangesAsync in E0173. Evidence needed: transaction configuration, event-dispatcher implementation, retry/outbox mechanisms, and failure-path integration tests.

Provenance gap: This passage has no artifact/source citation.

Open question for Harten: Are all notification endpoints protected by effective ownership, competent-authority, and read-only checks? Inspected artifacts: request declarations in E0054 and repository authorization evidence in E0182. Evidence needed: authorization middleware/decorators, endpoint inventory, and negative authorization tests for reads, mutations, downloads, and deletion.

Provenance gap: This passage has no artifact/source citation.