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

02 — Current business capability map

Purpose and scope

The application is identified in the supplied material as the International Waste Shipments (IWS) Service. Its business domain concerns notifications and assessments for shipping waste into or out of the country, supported by models for notification identity, submission summaries, status, competent authorities, waste operations, recovery, disposal, and special handling. This establishes the business subject matter represented by the source; it does not, by itself, prove the complete operational scope of the deployed service. E0006

The current system is best understood as a set of collaborating capabilities rather than a single confirmed runtime boundary. The evidence shows web/MVC and Web API entry points, mediator-style request contracts and handlers, repositories using Entity Framework and SQL, document generation, email, virus scanning, and supporting authentication and maintenance functions. The project structure demonstrates that these components exist in the application family, but it does not establish which are deployed together or which component owns each production responsibility. E0011 E0054 E0412

flowchart LR
    A[Web/MVC and API users] --> B[Requests and handlers]
    B --> C[Domain operations]
    C --> D[Repositories and SQL/EF persistence]
    C --> E[Email and document generation]
    B --> F[Authentication and authorization]
    G[External scanner] --> B
    H[Runtime deployment boundary] -. unresolved .-> A
    I[External identity authority] -. unresolved .-> F

The relationships from controllers or API actions to requests, handlers, repositories, and external services are evidenced at selected points, but the complete call graph and deployment topology remain unknown. E0008 E0414 E0011

Actors and business entry points

Observed actors. The source distinguishes internal users, external users, notification owners, shared users, competent authorities, and service-to-service clients. Internal users may be checked against a notification’s competent authority; external export-notification access may depend on ownership or sharing, while non-internal access to import notifications is denied in the cited authorization repository. These are observed authorization branches, not a complete actor catalogue. E0182

Users interact through MVC controllers and Web API operations. Tested controller flows include creating a notification, selecting its competent authority and type, managing producers, carriers and facilities, recording movement information, cancelling movements, and handling receipt and recovery uploads. The tests demonstrate expected navigation and mediator interactions under mocked conditions, but they do not establish that every flow persists successfully in production. E0494 E0401

The system also interacts with external technical actors. A virus-scanning API exposes an authenticated POST scan operation, while its GET health-style Scan action is explicitly anonymous and returns "ok". The two HTTP methods therefore have different access rules even though they use the same route template. E0412 An identity authority is configured for bearer-token validation in the API, but the available evidence does not establish the deployed authority, accepted token format, or exact scope semantics. E0011

Notification and assessment capability

The central business capability is managing an export or import notification through preparation, submission, assessment, decision, and closure-related states. The model represents statuses including NotSubmitted, Submitted, InAssessment, Consented, FileClosed, Resubmitted, UnderProhibition, and InDetermination. The status enum proves that these values are representable; it does not prove that they form a linear workflow or that every value is used in production. E0006

The strongest lifecycle evidence comes from unit tests for NotificationAssessment. Those tests define a candidate sequence in which submission requires notification progress to be complete; successful submission moves the assessment to Submitted and raises status-change and submission events; receipt is permitted from Submitted; commencement requires receipt and a payment-received date; and completion, transmission, and acknowledgement lead through ReadyToTransmit, Transmitted, and DecisionRequiredBy. Duplicate submission is rejected, and null or empty officer names are rejected. These are test-derived behavioral contracts, not independent proof of production conformance. E0279

The same tests cover additional decision and correction paths. Consent may be withdrawn, transmitted or decision-made notifications may be unlocked, and resubmission can lead to Consented, Reassessment, or DecisionRequiredBy depending on retained dates. Notifications may eventually be closed from decision-made states. Prohibition is tested from a broad list of non-prohibition states, but the evidence does not support the stronger statement that it is valid from literally every possible state. E0279

Assessment processing also includes consent dates, validity ranges, conditions, and financial-guarantee operations. Observed handlers persist selected consent and guarantee operations, including creation, approval, refusal, and release. The complete decision policy, calculation rules, and downstream effects are not established in the supplied evidence. E0008 E0414

Movement and shipment capability

Movement processing represents the operational execution of an approved notification. The available evidence identifies states including Captured, Submitted, Received, Completed, Rejected, Cancelled, and PartiallyRejected, with separate external and internal receipt/completion paths. Selected domain operations contain transition guards, but the evidence does not establish every legal transition or every invalid-state response. E0017

The movement domain is supported by data models for shipment dates, rejected quantities and reasons, notification status, route, waste, and consent information. These declarations establish the information shape used by the capability, not that every field is always populated or calculated. E0459

Movement documents are generated by ordering document blocks by OrdinalPosition, invoking each block’s Merge, and conditionally invoking GenerateAnnex for annex-capable blocks whose HasAnnex value is true. Annex numbering starts at 2 when a carrier annex is present and otherwise starts at 1. Carrier, facility, and customs-office blocks may defer some main-document work until annex generation. E0457

Facility annex generation has an evidenced special case: with exactly two facilities, the actual treatment site remains in the annex while the other facility is shown on the main document; with more than two facilities, the main document receives a “see annex” representation. The implementation expects exactly one actual site and uses a strict Single() lookup, so zero or multiple actual sites can raise an exception. Template validity, persistence, transmission, and successful production rendering remain unknown. E0457

Supporting information and administration

The system provides supporting capabilities for producers, carriers, facilities, customs offices, routes, waste operations, waste recovery and disposal, shared users, documents, and reporting. Request contracts declare operations such as adding, updating, deleting, and retrieving facilities; setting exporters; selecting customs offices; and retrieving notification-related data. These contracts establish available request shapes and intended authorization metadata, but not their complete business effects. E0054

Shared-user management is represented through controller tests covering adding and removing external users, duplicate prevention, maximum-list validation, email-format validation, rejection of internal addresses, unknown-user handling, and already-shared users. The evidence supports these as tested controller outcomes. It does not establish that all mediator calls are prevented in invalid cases or that authorization is enforced consistently across every sharing, download, and deletion path. E0494 E0105

Reporting and search are represented by criteria and result models for EWC codes, producers, exporters, facilities, countries, consent dates, notification dates, statuses, notification type, trade direction, and operation codes. Repository evidence shows calls to reporting tables or procedures and search procedures, including finance, freedom-of-information, and notification searches. The object types, refresh mechanisms, and completeness of the reporting data are not established. E0459 E0182

State and data changes

At the persistence boundary, repositories use asynchronous Entity Framework operations, LINQ, raw SQL, stored procedures, and explicit transactions in selected paths. ContextBase applies identifier assignment, relationship cleanup, auditing, and event dispatch before persistence. The synchronous save path blocks on event dispatch; the asynchronous path awaits dispatch after the base save completes. This indicates event work around persistence but does not establish an outbox, rollback coordination, retry policy, or atomicity between database changes and events. E0173

Notification-specific authorization is sometimes performed before repository reads or mutations, including shared-user, shipment, transport-route, waste-disposal, and waste-recovery access. Other cited repositories perform identifier-based mutations without a visible authorization call. This is a repository-level observation, not proof of an endpoint vulnerability, because authorization may occur in handlers, controllers, or stored procedures outside the inspected artifacts. E0414 E0182

Email capability is configured to register event handlers, templates, message construction, SMTP-related components, and approval or rejection notifications containing generated approval links. The evidence establishes those implementation elements and demonstrated flows, but not delivery success, retry behavior, or whether all relevant lifecycle events send mail. E0105

Current-system requirements and candidate characterization scenarios

The following requirements describe observed or test-supported current behavior. They are not target-design requirements.

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

• REQ-IWS-001 — Notification submission guard: The system shall reject notification submission when the notification progress service reports that the notification is incomplete. E0279
• REQ-IWS-002 — Assessment transition: The system shall permit commencement only when the assessment is in NotificationReceived and a payment-received date exists. E0279
• REQ-IWS-003 — Duplicate submission: The system shall reject a second submission of an already submitted notification. E0279
• REQ-IWS-004 — Movement state handling: The system shall represent captured, submitted, received, completed, rejected, cancelled, and partially rejected movement states, while applying the selected transition guards evidenced in the domain code. [[E067185ee25c21ca1d28c573606f7120f2b4726ba2caca25ea4b60b9925867a85]] Provenance gap: artifact/source reference unresolved.
• REQ-IWS-005 — Document annex generation: The system shall merge document blocks in ordinal order and generate annexes only for annex-capable blocks whose annex condition is true. E0457
• REQ-IWS-006 — Scanner access: The system shall require authorization for the scanner POST operation and allow the evidenced anonymous GET health response. E0412

Characterisation scenario candidates

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

1. Given a notification whose progress is incomplete, When a user submits it, Then submission is rejected and the notification does not move to Submitted. E0279
2. Given a notification in Submitted with a payment-received date, When an authorized assessor records receipt and commences assessment, Then the notification progresses through receipt to InAssessment. E0279
3. Given a movement document containing ordered blocks and an annex-capable facility block with HasAnnex = true, When the document is merged, Then blocks are processed by ordinal position and the facility annex is generated. E0457

Exceptions and open questions

Known exception paths include a possible null dereference when deletion lookup returns no notification, broad exception suppression during notification-number authorization, strict Single() assumptions for facilities, and possible malformed TempData or posted-identifier handling in MVC flows. These findings are source-level risks, not confirmed production incidents. E0105 E0008 E0457

Open question for Harten: The inspected controller, handler, repository, and startup artifacts do not establish the complete production capability boundaries, authorization enforcement, transaction semantics, or deployment topology. Evidence that would resolve this includes deployed route and dependency-registration configuration, handler implementations for all cited requests, database schemas and stored procedures, integration-test execution results, and representative production configuration. E0011 E0414