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

07 — System context and components

In this document

Purpose and scope

prsd-iws is an online notification-management system for waste shipments. The observed application supports creation and maintenance of export and import notifications, movement and shipment processing, assessment-related work, financial guarantees, reporting, address-book records, account administration, and notification sharing. The domain model represents a notification application with an owner, competent authority, notification number, assessment information, facilities, waste, charges, and completion progress. New notifications receive a competent-authority-specific number and raise a creation event. E0503 E0500

This chapter describes the current system as evidenced by the supplied source-analysis artifacts. “Observed” means that a source file or test directly demonstrates the behavior. “Inferred” means that the evidence supports a reasonable architectural interpretation but does not prove complete runtime behavior. “Unknown” means that the supplied excerpts cannot establish the behavior; an omitted excerpt is not treated as evidence that the behavior is absent.

External actors and systems

The principal observed human actors are:

Applicant or notification owner, who creates and edits notifications, manages producers and other parties, selects waste and shipment information, and may share or transfer access.
Administrator or competent-authority user, who searches notifications, reviews notifications requiring attention, performs administrative actions, and may archive, deactivate, or reactivate accounts.
User receiving shared access, who can be granted access to a notification and later removed from it.
Movement or shipment operator, an inferred role represented by the movement, receipt, recovery, rejection, cancellation, and certificate workflows. The supplied evidence does not establish whether this is a separate user population from applicants.
System operator, an inferred role responsible for configuration, maintenance mode, database migrations, and operational services. The evidence shows maintenance-mode configuration and a separate database migration runner, but does not identify the people or deployment process that invoke them. E0520 E0519 E0503 E0513

The application also interacts with external or adjacent technical systems:

an IWS/API client layer, including IwsClient, OAuthClient, UserInfoClient, and CompaniesHouseClient;
an identity and authentication service, represented by OWIN cookie authentication, OAuth clients, access-token expiry checks, and email-verification filters;
a Companies House lookup, used by the producer-edit page to retrieve a company name from a registration number;
a virus-scanning service or implementation, selected through configuration and used by upload-related infrastructure;
a SQL Server database, supported by migration scripts defining notification, lookup, movement, reporting, and audit structures;
AliaSQL.exe, used by a separate .NET Framework console utility to execute database operations and test-data actions. E0520 E0517 E0504 E0513

The relationship between these elements is evidenced at registration and source-structure level, but not all runtime calls are visible. In particular, the supplied material does not prove which database repositories are used by each web request, how API failures are translated at every boundary, or whether all configured clients are used in production.

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

Preparing diagram…

View Mermaid diagram source

flowchart LR
    Applicant --> Web["ASP.NET MVC/Razor web application"]
    Admin["Administrator / authority user"] --> Web
    Shared["Shared-access user"] --> Web
    Web --> Auth["Cookie/OAuth identity"]
    Web --> API["Configured API clients"]
    Web --> Scan["Virus scanner"]
    API --> DB["Application data / SQL Server"]
    Web --> DB
    Ops["Migration/test utility"] --> Alia["AliaSQL.exe"]
    Alia --> DB
    Web -. unresolved request paths .-> Companies["Companies House"]

The solid relationships in this diagram are supported by the cited component registrations, controllers, views, and migration utility. The dashed Companies House relationship is deliberately unresolved at the service boundary: the producer page visibly issues a request to GetCompanyName, while the endpoint implementation and its downstream client are not included. E0520 E0518 E0523 E0513

Application boundary and component structure

The web application is an ASP.NET MVC application using Razor views, GOV.UK styling, localized .resx resources, global filters, areas, routes, dependency injection, and bundled JavaScript and CSS. AutofacBootstrapper.cs registers controllers, model binders, HTTP abstractions, MVC filter providers, mapping modules, and API-client modules. FilterConfig.cs identifies maintenance-mode, HTTPS, email-verification, organisation, administrator-approval, API-error, anti-forgery, and virus-found filters in a defined order. Registration proves that these concerns are part of the request pipeline; it does not by itself prove every filter’s bypass conditions or runtime outcome. E0520 E0510

The principal functional components visible in the evidence are:

Notification application component.
The domain entity and factory create notifications, assign numbers, change ownership, manage waste types and waste codes, maintain special-handling information, and reject edits to read-only notifications. The source also records notification-created and user-changed events. The complete status-transition set is broader than any one page: the model contains states including NotSubmitted, Submitted, NotificationReceived, InAssessment, ReadyToTransmit, Transmitted, Consented, Withdrawn, FileClosed, and others. E0503 E0500
Notification web workflow component.
Razor pages provide multi-step entry and editing for exporters, importers, producers, facilities, chemical composition, waste codes, reason for export, entry and exit points, and site of export. Producer pages list, edit, remove, and select the site-of-export producer. A notification becomes read-only after assessment according to the view-level analysis, although the exact transition rule is not visible. E0518 E0501 E0511
Movement and receipt/recovery component.
The application models shipment movements, movement dates, quantities, receipts, recoveries, full and partial rejection, cancellation, certificate choices, signed-certificate uploads, and bulk-upload templates. Selection models require at least one shipment in some flows, while rejection uses a required selected movement. Cancellation pages communicate that only an unshipped prenotified shipment may be cancelled; the supplied views do not prove that the server enforces that restriction. E0521 E0514 E0502 E0512
Assessment and financial-guarantee component.
Assessment pages display guarantee status, decisions, dates, and links conditional on status. The supplied view models validate received, completion, approval, refusal, and release dates against ordering and future-date rules. Approval also checks active loads, a positive permitted-load value, blanket-bond selection, reference number, cover amount, continued calculation, and decimal precision. The apparent upper bounds for monetary values are commented out, so those limits are not currently evidenced as active enforcement. E0511 E0516
Administration, reporting, and access component.
Administrative pages search export and import notifications, show notifications requiring attention, link to movement views, archive notifications, and delete notifications. Separate flows support notification ownership transfer, sharing and removal of user access, external-user deactivation, and reactivation. The views establish presentation and submission steps; for deactivation and reactivation, they do not establish that the controller performs the state change or reallocates notifications. E0519 E0515 E0522
Address-book component.
The AddressBook area supports listing, paging, searching, JSON search, adding, editing, and deleting producer, carrier, and facility records. Its controllers use the mediator pattern. The home search path distinguishes null, non-empty, and whitespace-only search terms, but the precise user-visible result for each case depends on the surrounding view and is not fully shown. E0520 E0515
Data and integration infrastructure.
Migration scripts show SQL Server tables and relationships for competent-authority permissions, waste-code activation, company types and registration numbers, rejection data, status-at-file-closed values, and reporting caches. The scripts establish schema history, not necessarily current row contents or application consumption. API modules configure clients, OAuth-related services, logging, retry policies, and virus scanning; actual production configuration is not supplied. E0517 E0510 E0505

Triggers and state/data changes

A user request normally enters through a named route, an area route, or the default lowercase-dashed MVC route. Forms commonly include anti-forgery tokens, validation summaries, hidden notification identifiers, and localized labels. A successful notification-creation operation generates a number and raises a domain event; editing operations update notification-owned domain data, while attempts to edit a read-only notification can raise NotificationReadOnlyException. E0515 E0503 E0501

Movement operations change movement status and associated data. The visible application services retrieve a movement, invoke an operation, and add the resulting receipt, rejection, or partial-rejection record to a repository. In partial rejection, the visible condition rejects quantities greater than or equal to the actual quantity, meaning the accepted value is strictly less; a whitespace-only reason passes the shown IsNullOrEmpty check. When a standard receipt and partial-rejection record are both supplied to MovementTableData.Load, the partial-rejection block overwrites receipt quantity, unit, and received state. E0512

The current status machine requires care in documentation. The visible import-assessment configuration shows NotificationReceived accepting Submit and moving to AwaitingPayment, while AwaitingPayment is configured beneath Submitted. Therefore, the concrete destination evidenced by that excerpt is AwaitingPayment; describing the operation simply as moving to Submitted is an abstraction over the state hierarchy, not the precise observed destination. E0508

Rules and exceptions

The following rules are directly evidenced and should be treated as current requirements of the observed implementation:

REQ-SC-001 — Create notification number.
When a new notification is created for a competent authority, the system shall obtain the next authority-specific number, create the notification, and raise a notification-created event. E0503
REQ-SC-002 — Protect read-only notifications.
When an edit is attempted against a notification in the read-only condition represented by the domain, the system shall reject the edit with the notification-read-only exception path. The exact status that causes read-only behavior remains unresolved. E0503 E0518
REQ-SC-003 — Validate partial rejection quantity.
When a partial rejection is submitted, the rejected quantity shall be strictly less than the actual quantity, and a null or empty reason shall be rejected by the shown application-layer check. E0512
REQ-SC-004 — Validate financial-guarantee dates.
Received, completion, approval, refusal, and release dates shall be present where required, shall not be future dates, and shall respect the observed ordering constraints. E0516
REQ-SC-005 — Require movement selection.
The upload-choice flow shall reject submission when no shipment is selected. The rejection flow shall require a selected movement through its required selection field. E0514
REQ-SC-006 — Preserve access-control protections.
Confirmation forms for ownership transfer, account deactivation, and related operations shall include anti-forgery protection. This requirement establishes the observed form protection, not the completeness of authorization checks. E0522 E0519

Characterisation scenarios — candidates

Scenario CS-001 — Partial rejection equality

Given an import movement with an actual quantity of 10
When the user submits a partial rejection of 10
Then the application-layer partial-rejection operation should reject the request because the condition is rejectedQuantity >= actualQuantity. E0512

Scenario CS-002 — Notification creation

Given a competent authority and a request to create a new notification
When the notification factory creates the application
Then it should assign the next authority-specific notification number and associate a NotificationCreatedEvent. E0503

Scenario CS-003 — Empty shipment selection

Given the upload-choice page with no shipment selected
When the user submits the form
Then validation should report the localized shipment-required error and prevent progression. E0514

Open questions for Harten

Open question for Harten: What controller, service, repository, and authorization rules execute behind the principal MVC forms and API clients? The inspected artifacts are AutofacBootstrapper.cs, FilterConfig.cs, the cited Razor views, and the domain summaries; the evidence resolves component registration and view structure but not all request processing. Controller actions, service implementations, authorization policies, and integration tests would resolve this.

Open question for Harten: What exact event or status makes a notification read-only, and is the transition persisted atomically with related edits? The inspected artifacts are ReadOnly/Index.cshtml, NotificationReadOnlyException.cs, and the notification status evidence. State-machine configuration, command handlers, and persistence transaction tests would resolve it.

Open question for Harten: Does the GetCompanyName lookup handle transport failure, authorization failure, and malformed responses? The inspected artifact is Producer/Edit.cshtml; its success path is visible but no error callback or endpoint implementation is supplied. The endpoint, client implementation, and browser/API failure tests would resolve the behavior. E0523

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.