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

13. Candidate Characterisation Tests

In this document

Purpose and scope

This chapter records candidate characterisation tests for the current International Waste Shipments (IWS) system. The purpose is to preserve behaviour that is visible in source and tests before changes are made, particularly around notification assessment, movement processing, controller workflows, document generation, and access checks. These are not target-state requirements and do not certify production conformance. The strongest evidence comes from unit tests, which demonstrate expected outcomes under mocked dependencies rather than proven runtime behaviour. E0279 E0494

The system supports regulatory administration of waste shipments into and out of the country. Its model and request contracts represent notifications, assessments, movements, competent authorities, waste operations, documents, users, facilities, carriers, financial guarantees, and reporting data. These declarations establish the business vocabulary, but not necessarily the complete workflow or persistence behaviour. E0006 E0054 E0459

The principal actors evidenced by the inspected material are applicants or external notification users, internal or competent-authority users, administrators, and system components such as request handlers, repositories, document-generation blocks, and notification services. Authorization distinguishes internal users from external users in several repository paths: internal users are checked against competent-authority access, while external export-notification users are checked for ownership or sharing. Non-internal users are denied access to import-notification data in the cited authorization implementation. E0182

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

Preparing diagram…

View Mermaid diagram source

flowchart LR
    External[External notification user] --> Notification[Notification and movement workflows]
    Internal[Internal / competent-authority user] --> Assessment[Assessment and decisions]
    Notification --> Handler[Request handler]
    Assessment --> Handler
    Handler --> Repository[Repository / persistence]
    Handler --> Document[Document generation]
    Handler -. authorization semantics unresolved .-> Access[Effective endpoint enforcement]

Characterisation approach

The candidate tests below use explicit identifiers. “Observed” means directly supported by a cited implementation or test assertion. “Inferred” means a reasonable interpretation of that evidence, but not a demonstrated system-wide fact. “Unknown” identifies behaviour that the available excerpt cannot establish.

The tests should first be run against the current system without changing production code. Where a scenario depends on an unseen handler, database object, route, or authorization attribute, the scenario is a candidate rather than a confirmed executable test.

Notification assessment lifecycle

NotificationAssessment has a substantial test-defined lifecycle. The observed tests establish a default NotSubmitted status; submission requires the notification-progress service to report completion; successful submission changes the status to Submitted and raises notification status-change and notification-submitted events. Duplicate submission is rejected. Receipt is permitted from Submitted, records a receipt date, and changes status. Commencement requires receipt and a payment-received date, records commencement details, and changes status to InAssessment. Null or empty officer names are rejected. E0279

Further tested transitions include InAssessment to ReadyToTransmit, then Transmitted, then DecisionRequiredBy. Tests also cover consent withdrawal, unlocking, resubmission from consented-unlock or reassessment states, rejection of changes, and closure from several decision-made states. Prohibition can be entered from every status listed by the test, but the evidence does not justify the stronger statement that it is possible from literally every status, because UnderProhibition itself is not included in the test’s source list. E0279

CT-13-001 — Prevent incomplete submission

Observed rule: submission checks INotificationProgressService.IsComplete(...).
Given an assessment whose progress service reports incomplete,
When Submit is invoked,
Then the operation is rejected, the status remains NotSubmitted, and no successful-submission event is emitted.

This is a candidate scenario derived from the tested precondition. The exact exception type, message, and event behaviour should be confirmed from the test assertions and implementation.

CT-13-002 — Accept a complete first submission

Given an assessment in NotSubmitted and a progress service reporting complete,
When Submit is invoked,
Then status becomes Submitted, and both status-change and submitted events are raised.

CT-13-003 — Reject duplicate submission

Given an assessment already in Submitted,
When Submit is invoked again,
Then the operation is rejected and the existing status is preserved.

CT-13-004 — Enforce commencement prerequisites

Given an assessment that has not reached NotificationReceived, or has no payment-received date,
When Commence is invoked,
Then commencement is rejected.
Given an assessment in NotificationReceived with a payment-received date,
When Commence is invoked with a non-empty officer name,
Then status becomes InAssessment and commencement details are recorded.

The complete transition table remains unknown. The tested editability policy allows edits in NotSubmitted, Submitted, NotificationReceived, InAssessment, and Unlocked, and disallows edits in ReadyToTransmit, Transmitted, DecisionRequiredBy, and UnderProhibition. It does not cover Consented, Withdrawn, Objected, FileClosed, Reassessment, or ConsentedUnlock. E0279

Open question for Harten: Which status values are editable in production? The inspected artifact is NotificationAssessmentEditableTests.cs within the supplied domain-test range. A complete answer requires the production IsEditable implementation, tests for the omitted statuses, or a complete state-transition specification.

Movement receipt and completion

The movement domain represents captured, submitted, received, completed, rejected, cancelled, and partially rejected states, with separate external and internal receipt and completion paths. The cited source applies selected date, quantity, file-identifier, and state-transition guards, but does not establish that external and internal paths have identical rules. [[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.

CT-13-005 — Characterise movement receipt guards

Given a submitted movement with valid receipt information,
When the external receipt operation is invoked,
Then the movement enters the observed received state and receipt data is retained.
Given a movement in an ineligible state, or with invalid receipt dates or required identifiers,
When the same operation is invoked,
Then the operation is rejected and the movement state is unchanged.

CT-13-006 — Characterise completion quantities

Given a received movement with valid completion quantities,
When completion is recorded,
Then the movement enters Completed or the appropriate partial/rejection state according to the supplied quantity and decision data.
Given an invalid quantity or an ineligible movement state,
When completion is attempted,
Then the operation is rejected without persisting a completion state.

These scenarios express the observed existence of guards, not an inferred complete business rule. The evidence does not specify the boundary between completed, partially rejected, rejected, and cancelled outcomes, nor whether invalid requests are rejected by the domain, handler, repository, or controller.

Open question for Harten: What are the authoritative transition and quantity rules for each movement path? The inspected artifact is the movement domain implementation summarized by BR-CLAIM-002 and MOVEMENT-GUARDS. A full transition matrix, handler tests, and persistence-level tests would resolve the uncertainty.

Assessment handling includes consent with a date range, conditions, and a consent date. Financial-guarantee operations include creation, approval, refusal, and release. The observed handlers persist selected operations, but the complete eligibility policy, authorization requirements, downstream effects, and failure semantics are not established. [[LRG-02-0001-781f4f335c5c1c9b::claim::BR-CLAIM-003]] Provenance gap: artifact/source reference unresolved. [[LRG-02-0001-781f4f335c5c1c9b::rule::ASSESSMENT-DECISION-RULES]] Provenance gap: artifact/source reference unresolved.

CT-13-007 — Record consent

Given an assessment eligible for consent,
When consent is submitted with a valid date range, conditions, and consent date,
Then the consent operation is persisted and the assessment reflects the consent decision.
Given an invalid date range or an ineligible assessment,
When consent is submitted,
Then the operation is rejected and no partial consent decision is persisted.

CT-13-008 — Characterise guarantee decisions

Given a financial guarantee that can be decided,
When an authorized user approves it,
Then the approval operation is persisted.
Given a guarantee eligible for refusal or release,
When the corresponding operation is invoked,
Then the refusal or release is persisted.
Given an unauthorized user or an invalid guarantee state,
When a decision is attempted,
Then the operation is rejected and the previous decision remains.

The last negative cases are candidate tests only: authorization and invalid-state handling are not fully visible in the supplied handler evidence.

Request authorization and identifier trust

The system declares request authorization attributes, bearer-token validation, controller filters, ownership checks, and competent-authority or internal-user checks. However, effective enforcement for every endpoint, mutation, download, deletion, and client-supplied identifier is unresolved. [[LRG-02-0001-781f4f335c5c1c9b::rule::RULE-001]] Provenance gap: artifact/source reference unresolved.

A concrete current-system exception is visible in export-notification deletion. The controller looks up notification details from a submitted notification number, but if that lookup returns null, the visible code proceeds to access notificationDetails.NotificationId, permitting a possible null dereference. The POST also sends a client-supplied notification ID; the supplied controller excerpt does not prove that it matches the earlier lookup or that ownership and current deletability are rechecked. E0105

CT-13-009 — Unknown notification deletion

Given a notification number that cannot be resolved,
When the deletion page is requested,
Then the system should return a controlled not-found or validation result rather than dereferencing a null detail object.

This is a characterisation candidate for a visible defect boundary, not an assertion that production necessarily fails; an unseen mediator invariant could prevent the null result.

Open question for Harten: Does the deletion handler revalidate notification ownership, identifier correspondence, and current state? The inspected artifact is DeleteExportNotificationController.cs in E0105. The mediator handler, AuthorizeActivity implementation, and integration tests would resolve this.

Document generation

The observed document pipeline orders IDocumentBlock instances by OrdinalPosition, calls Merge() on each block, and calls GenerateAnnex(i) for annex-capable blocks whose HasAnnex value is true. Carrier, facility, and customs-office blocks deliberately divide work between the main merge and annex generation. Facility annex generation has a specific rule: with exactly two facilities, the actual site remains in the annex and the other facility is shown on the main document; with more than two, the main document receives a “see annex” representation. [[LRG-02-0001-781f4f335c5c1c9b::claim::OBSERVED-DOCUMENT-MERGE-PIPELINE]] Provenance gap: artifact/source reference unresolved. E0457

CT-13-010 — Ordered merge and conditional annex

Given blocks with known ordinal positions,
When a movement document is merged,
Then blocks are processed in ascending ordinal order.
Given an annex-capable block with HasAnnex == true,
When merging occurs,
Then GenerateAnnex is invoked with the next annex number.

CT-13-011 — Facility annex invariant

Given exactly one facility marked as the actual site,
When facility annex generation runs,
Then the actual-site data is moved to the annex representation and remaining facilities are represented according to the two- or more-than-two-facility rule.
Given zero or multiple actual sites,
When generation runs,
Then the operation fails in the observed implementation because it uses a strict single-match lookup.

Template validity, rendering success, persistence, transmission, and repeated invocation are not established. The implementation mutates the facility data list while generating the annex, so repeated invocation is a candidate robustness test rather than a known supported use case. E0457

Test-suite and evidence limitations

The supplied controller tests cover creation, navigation, shared-user validation, carrier/facility/producer flows, movement cancellation, bulk-upload routes, and selected date rules. They frequently verify redirects, views, mediator calls, or returned models, but they do not generally establish authorization, persistence, transactionality, or production integration. No test execution results were supplied. E0352 E0401 E0494

Consequently, these scenarios should be retained as characterization candidates with their evidence status preserved. Passing them would show that the current observable contract remains stable under the selected fixtures; it would not prove that omitted handlers, database procedures, deployment configuration, or endpoint authorization behave identically in production.

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.