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

11. Current-State Design

11.1 Purpose and scope

Observed. The application is identified as the International Waste Shipments (IWS) Service. Its stated domain is managing compliance-related activity for shipping waste into or out of the country. The source evidence represents notification and movement workflows, assessments, shipments, waste and recovery information, customs offices, carriers, facilities, financial guarantees, reporting, users, routes, and documents. The evidence also shows web/MVC, Web API, request-handler, data-access, document-generation, email, virus-scanning, and test components. This establishes the represented application family, but not every runtime or deployment boundary. [[LRG-02-0002-cba7f9acf83a4290::claim::APP-CLM-001]] Provenance gap: artifact/source reference unresolved. [[LRG-02-0001-781f4f335c5c1c9b::claim::APP-CLAIM-001]] Provenance gap: artifact/source reference unresolved.

Inferred. The system appears to support regulators, competent authorities, operators, and other users through a shared record of notifications and movements. A notification is the principal business record, while movements, assessments, documents, users, and financial-guarantee data are related records or processes. The evidence does not establish the complete organisational operating model, the production deployment topology, or which actors perform each action.

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

The chapter describes observed current behavior and selected tested expectations. It is not a target design or a complete business-rule catalogue. The source evidence explicitly states that many conclusions are based on partial source chunks, tests, declarations, or selected handlers rather than end-to-end production execution. E0105 E0017 E0352

11.2 Actors and entry points

Observed. Users reach the system through MVC controllers and Web API endpoints. Many notification-editing controllers visibly combine authentication with a notification read-only filter, while selected requests carry activity or permission attributes. Request contracts also declare permissions such as reading or editing export notifications, deleting an export notification, or editing import movements. These declarations show authorization intent, but do not prove that every invocation path enforces it. E0017 E0054

Internal and external users are treated differently in data-access authorization. The available repository evidence indicates that internal users are checked against the notification’s competent authority, while external users are checked against ownership or sharing for export notifications. Non-internal access to import-notification data is denied in the cited authorization implementation. Several repositories perform authorization before notification-specific reads. E0182

The application also interacts with supporting actors and services:

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

• competent authorities and their officers participate in assessment and decision processing;
• operators provide notifier, exporter, importer, carrier, facility, waste, route, and shipment data;
• an email service sends approval and rejection notifications using configured templates and constructed approval links;
• a virus-scanning service scans uploaded files;
• document-generation components produce movement documents and annexes;
• SQL Server/Entity Framework data-access components persist or retrieve application data. [[LRG-02-0002-cba7f9acf83a4290::claim::APP-CLM-005]] Provenance gap: artifact/source reference unresolved. [[LRG-02-0002-cba7f9acf83a4290::claim::APP-CLM-008]] Provenance gap: artifact/source reference unresolved. [[LRG-02-0001-781f4f335c5c1c9b::claim::OBSERVED-DOCUMENT-MERGE-PIPELINE]] Provenance gap: artifact/source reference unresolved. [[LRG-02-0002-cba7f9acf83a4290::claim::APP-CLM-003]] Provenance gap: artifact/source reference unresolved.

Open question for Harten: The inspected controller, request-contract, and authorization artifacts do not establish the complete actor-to-permission matrix or whether authorization is enforced consistently on mutation, deletion, sharing, and download paths. Evidence that would resolve this is the effective request-attribute implementation, all relevant handlers, route configuration, and integration tests covering each actor and operation.

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

11.3 Triggers and processing pattern

Observed. User actions are represented as MVC requests or mediator-style requests. The supplied handlers commonly load a domain object or repository result, perform a domain operation, save through a context or repository, and return a result. The data-access evidence shows asynchronous Entity Framework operations, repositories, mappings, SQL queries, stored procedures, and selected explicit transactions. [[LRG-02-0001-781f4f335c5c1c9b::claim::APP-CLAIM-005]] Provenance gap: artifact/source reference unresolved. E0008 E0302

A notification can be created through a multi-step controller flow. Tests cover competent-authority selection, notification-type selection, valid-post redirects, and invalid-model returns to the same view. These tests establish expected controller navigation under mocks, not proven persistence or end-to-end creation. E0494

A notification can also be submitted, received, commenced, assessed, transmitted, acknowledged, consented to, resubmitted, or closed. Domain tests provide the strongest evidence for selected transitions and guards.

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

flowchart LR
    A[Notification data] --> B[Submission and assessment]
    B --> C[Consent or objection]
    C --> D[File closure]
    B --> E[Movement processing]
    E --> F[Receipt and completion]
    B -. unresolved production enforcement .-> G[Documents and notifications]

The dashed relationship indicates an unresolved production link, not an absence of capability.

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

11.4 Notification and assessment state

Observed. The notification assessment model represents statuses including NotSubmitted, Submitted, NotificationReceived, InAssessment, ReadyToTransmit, Transmitted, DecisionRequiredBy, Consented, FileClosed, Resubmitted, UnderProhibition, and InDetermination. The presence of enum values proves representability, but not a complete linear workflow. E0006

Observed from tests. The default assessment status is NotSubmitted. Submit requires notification progress to be complete, changes the status to Submitted, and raises notification status-change and submission events. Duplicate submission is rejected. NotificationReceived is permitted only from Submitted and records a received date. Commenced requires NotificationReceived and a payment-received date, records commencement details, and changes the status to InAssessment. Officer names must not be null or empty. E0279

The tested sequence continues from InAssessment to ReadyToTransmit, then Transmitted, and then DecisionRequiredBy, through Complete, Transmit, and Acknowledge. Other tested operations include consent withdrawal, unlocking, resubmission, reassessment, rejection of changes, and closure from decision-made states. These are test-derived behavioral contracts rather than independent confirmation that every production path behaves identically. E0279

Prohibition is broader but not unlimited in the evidence: tests permit transition to UnderProhibition from every listed non-prohibition state and test lifting prohibition back to listed prior states. The evidence does not justify saying that prohibition is reachable from literally every possible state. Editability is also only partially covered: tests allow editing in early states and disallow it in ReadyToTransmit, Transmitted, DecisionRequiredBy, and UnderProhibition, but do not cover every status. E0279

11.5 Movement receipt and completion

Observed. Movement processing represents captured, submitted, received, completed, rejected, cancelled, and partially rejected states. It has distinct external and internal receipt and completion paths, with selected transition and date guards. The source therefore supports a movement receipt-and-completion lifecycle, but not a complete state-transition table. [[LRG-02-0001-781f4f335c5c1c9b::claim::BR-CLAIM-002]] Provenance gap: artifact/source reference unresolved. [[journey::movement-receipt-completion-lifecycle]] Provenance gap: artifact/source reference unresolved.

Inferred. A typical movement begins as captured data, is submitted, receives an external or internal receipt, and is subsequently completed or rejected. Cancellation and partial rejection represent alternative outcomes. The evidence does not establish which actor may perform each transition, whether a movement must belong to a particular notification status, or how repeated or out-of-order submissions are handled.

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

Open question for Harten: The inspected movement status and handler evidence does not establish every valid and invalid transition, concurrency behavior, or the authoritative source of receipt/completion dates. A complete answer requires all movement domain methods, request handlers, persistence procedures, and tests for repeated, stale, cancelled, rejected, and partially rejected movements.

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

Candidate characterisation scenarios

• Given a notification assessment is NotSubmitted and its progress is incomplete, When a user submits it, Then submission is rejected and the status remains unchanged.
• Given an assessment is Submitted, When a valid notification-received operation is executed, Then the received date is recorded and the assessment moves to NotificationReceived.
• Given a movement is in a state that permits receipt, When an authorized external receipt operation is submitted with valid dates, Then the movement enters its received state and the receipt data is persisted.
• Given a movement is already completed, When completion is submitted again, Then the operation is rejected or handled idempotently; the exact current behavior remains to be confirmed.

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

11.6 Financial guarantees, documents, and notifications

Observed. Assessment processing includes consent with a date range, conditions, and a date. Handlers also represent financial-guarantee creation, approval, refusal, and release operations, and selected operations are persisted. The complete decision policy and downstream effects are not established. [[LRG-02-0001-781f4f335c5c1c9b::claim::BR-CLAIM-003]] Provenance gap: artifact/source reference unresolved. [[journey::assessment-consent-financial-guarantee-decisions]] Provenance gap: artifact/source reference unresolved.

Observed. Movement documents are generated by ordering document blocks by OrdinalPosition, invoking Merge on each block, and generating annexes for annex-capable blocks whose HasAnnex is true. Carrier, facility, and customs-office blocks can defer or alter their main-document work when an annex is required. Facility annex handling includes a specific rule for exactly two facilities and requires exactly one actual treatment site. [[LRG-02-0001-781f4f335c5c1c9b::claim::OBSERVED-DOCUMENT-MERGE-PIPELINE]] Provenance gap: artifact/source reference unresolved. E0457

Exception. The document code uses strict lookups and Single/First-style operations. Missing template fields, unexpected table structures, or zero or multiple actual facilities can therefore cause failures. Production template validity, rendering success, persistence, transmission, and retry behavior are not established. E0457

Email approval and rejection flows are represented using named templates and approval links, but delivery success and failure handling are not established. [[LRG-02-0002-cba7f9acf83a4290::claim::APP-CLM-005]] Provenance gap: artifact/source reference unresolved.

11.7 Data changes, failure handling, and known gaps

Observed. Data changes generally pass through repositories or contexts. ContextBase applies identifier, relationship-deletion, and audit-related processing before saving; event dispatch occurs after persistence returns, with different blocking/awaiting behavior for synchronous and asynchronous saves. This does not establish an outbox, rollback of downstream events, or retry semantics. E0173

The evidence identifies several consequential exceptions. Unknown notification numbers may lead to a null dereference in export-notification deletion after the lookup result is not found. A controller POST also accepts a client-supplied notification identifier, while notification-specific ownership and current-state checks are not visible in the inspected controller. These may be protected by unseen handlers, so they are risks requiring verification rather than confirmed bypasses. E0105

Open question for Harten: The inspected controller excerpts cannot establish whether deletion rechecks ownership and deletability at command execution, whether failed event dispatch leaves committed data, or whether email and document failures are retried or surfaced. Evidence that would resolve this is the complete handler, authorization service, transaction/event-dispatch implementation, and production integration tests.

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