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

03 — Actors and Value Streams

Purpose and scope

The application supports the preparation, assessment, authorization, and operational processing of waste-notification records. The visible source spans notification data, assessment decisions, financial guarantees, movements, receipts, comments, user administration, reporting, and authorization metadata. This chapter describes the current evidenced system rather than proposing a target design. The evidence establishes several application and handler-level flows, but not the complete runtime actor model, endpoint surface, authorization policy, or persistence semantics. E0010 E0001 E0419

The business purpose can therefore be stated cautiously: users and application processes create or manage regulated notification information, assess whether an import or movement may proceed, record financial-guarantee decisions, and follow shipments through receipt and completion. This is an interpretation of the combined source surface; the supplied excerpts do not provide a single business-purpose statement or an end-to-end process definition. E0013 E0162

Actors and responsibilities

Application users and administrators

Observed: The source contains concepts for external-user status, internal-user status, internal-user role, approvals, ownership transfer, notification sharing, and authorization checks. Request contracts include operations such as setting external-user status, setting approvals, updating internal-user role and status, and authorizing activities. These contracts carry authorization metadata, including permissions for reading or editing notifications and managing users. E0001 E0096

Inferred: The system consequently distinguishes at least two broad user populations:

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

• External users, associated with notification preparation and submission.
• Internal users and administrators, associated with assessment, approval, administration, and operational decisions.

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

An internal-user test fixture sets the job title to “IWS Administrator,” associates the user with a competent authority, and assigns an internal-user status. This demonstrates one concrete internal-user representation, but not the complete production role taxonomy. E0226

Unknown: The evidence does not establish which human roles can perform each operation at runtime, whether permissions are checked at controllers, mediator handlers, filters, or a shared pipeline, or how external-user ownership is enforced. Authorization attributes on request classes establish declarations, not successful runtime enforcement. E0001 E0419

Application request handlers

Observed: Application request handlers execute the supplied movement, consent, and financial-guarantee operations. The handlers use asynchronous request-processing patterns and delegate to repositories, domain methods, or persistence contexts. Examples include ConsentHandler, movement receipt/completion handlers, and financial-guarantee creation, approval, refusal, and release handlers. E0010 E0419 E0460

Inferred: These handlers are application actors in the value streams: they translate an incoming request into a domain operation and, in several cases, save the result. They are not necessarily human actors. The human or external caller behind each handler is not identified by the evidence. E0017

External systems and data services

Observed: The application uses repositories, mapping components, database procedures and reporting views. Report handlers pass competent-authority context to repositories, while the database reporting layer combines notification and movement information into reporting views and caches. E0162 E0218 E0081

Unknown: The evidence does not establish the complete set of external systems, integrations, queues, email services, document stores, or production deployment boundaries. The presence of a handler or database object does not prove that it is invoked in every production path. E0011

flowchart LR
    U[Application users and administrators] --> H[Application request handlers]
    H --> D[Domain and repositories]
    D --> DB[(Notification and reporting database)]
    H -. unresolved caller or integration .-> X[External systems]

The solid relationships represent source-supported layering and data access. The dashed relationship is intentionally unresolved because the supplied evidence does not identify the external caller or integration boundary. E0017 E0162

Value stream 1: Prepare and assess a notification

A notification value stream begins with notification data assembled from parties, facilities, routes, waste types, and related details. The request and mapping layers represent importers, producers, exporters, facilities, customs offices, waste codes, and transport routes. A test-data script creates a notification with importer, exporter, producer, carrier, facility, and route records, showing one concrete persisted example of this information being assembled. E0217 E0226

Waste information includes Basel/OECD, EWC, Y, H, and UN code selections, together with waste category and operation information. The source confirms model structures and some mapping rules, but not the complete validation algorithm. Localized resources expose messages for Basel/OECD, EWC, H, UN, waste-name, and Y-code validation; no supplied validator implementation shows when those messages are enforced. E0093 E0010

Observed: Assessment processing records consent by invoking a domain Consent operation with a notification ID, a DateRange constructed from the supplied start and end dates, conditions, and a date, then saving changes and returning true. E0010

Financial-guarantee processing has separate handlers for creation, approval, refusal, and release. Approval carries a reference, refusal carries a reason, and release has no additional decision detail in the observed call. The financial-guarantee status vocabulary includes awaiting application, application received, application complete, approved, refused, and released. E0010 E0093

Unknown: The evidence does not establish whether consent is permitted only for particular notification statuses, whether the supplied date range is validated for ordering or overlap, or what downstream effects follow an approval, refusal, or release. The handlers demonstrate selected persistence operations, not the complete assessment policy. E0010 E0419

Requirements derived from current evidence

• REQ-03-AVS-001 — Record consent data. When the consent operation is handled, the system shall pass the notification identifier, consent start date, consent end date, conditions, and consent date to the domain consent operation and save the changes. Status: observed handler behaviour. E0010
• REQ-03-AVS-002 — Represent financial-guarantee decisions. The system shall provide distinct application operations for creating, approving, refusing, and releasing a financial guarantee; approval shall accept a reference and refusal shall accept a reason. Status: observed handler/request surface; downstream policy unknown. E0010 E0093
• REQ-03-AVS-003 — Validate waste selections. The system shall apply the intended Basel/OECD, EWC, H, UN, waste-name, and Y-code validation rules before treating a waste selection as valid. Status: required characterization of current intent, not established enforcement. E0010

Value stream 2: Submit, receive, reject, and complete a movement

The movement lifecycle is implemented as a state machine. The observed transitions include New to submitted, received, partially rejected, or rejected; Submitted to received, rejected, cancelled, or partially rejected; Received to completed, rejected, partially rejected, or cancelled; Captured to received, rejected, submitted, cancelled, or partially rejected; and PartiallyRejected to completed. No transitions out of rejected or cancelled were identified in the supplied definition, although other application code could still affect those records. E0013

A captured movement initializes its notification ID, number, date, captured status, prenotification flag, creator, and creation timestamp. Capture rejects the combination of “no prenotification” and a supplied prenotification date. An internally constructed movement begins in New. E0013

Observed: External receipt requires a non-default file ID, date, and quantity before the receive trigger fires. Internal receipt validates date and quantity and rejects a date later than the current UTC date. Receipt creation differs by path: external receipt creates a receipt with a file ID, while internal receipt creates one without a file ID. E0013

Completion is also split. External completion visibly validates a non-default completion date and file ID. Internal completion checks for a future date and rejects a completion date earlier than the receipt date. The supplied source does not show the same receipt-ordering check on external completion. E0013

Rejection and partial rejection create corresponding rejection entities and fire state-machine triggers. When the current status is Received, both operations clear the receipt. The evidence also shows that a partially rejected movement may transition to completed, but does not establish whether a receipt is always available at that point. E0013

A database procedure provides a separate operational path for updating movement data. When a movement is marked received, it requires either an existing receipt or non-null receipt date, quantity, and unit; it removes rejection rows and creates or updates receipt data. A supplied recovery date sets movement status to 4, while its absence removes the operation receipt and sets status to 3. E0218

Requirements and characterization candidates

• REQ-03-AVS-004 — Guard internal receipt dates. When an internal receipt date is later than the current UTC date, the system shall reject the receipt operation. Status: observed domain behaviour. E0013
• REQ-03-AVS-005 — Require receipt evidence. When a movement is marked received through the database update path, the system shall require an existing receipt or receipt date, quantity, and unit, otherwise it shall roll back and raise an error. Status: observed database behaviour. E0218
• REQ-03-AVS-006 — Distinguish external and internal receipt. The system shall preserve the observed distinction that external receipt includes a file identifier while internal receipt does not. Status: observed domain behaviour. E0013

Characterization scenario candidate — external receipt

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

• Given a movement in a state that permits receipt, a valid file identifier, a receipt date, and a quantity
• When the external receive operation is handled
• Then the movement shall fire the receipt transition and create a movement receipt containing the observed receipt data.

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

Characterization scenario candidate — internal completion

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

• Given a movement with an existing receipt date
• When internal completion is requested with a completion date earlier than the receipt date
• Then the operation shall be rejected.

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

These scenarios describe evidenced candidates, not confirmed automated tests. E0013

Exceptions and open questions

The current evidence shows several non-uniform missing-data behaviours: some handlers return null, some return empty data objects, and some leave nullable fields unset. This means callers cannot safely assume one common “not found” convention. E0010

Open question for Harten: For each value-stream request, what is the authoritative response for a missing notification, movement, assessment, receipt, or guarantee? The inspected artifacts are the assessment, movement, and financial-guarantee handlers cited in E0010, plus the movement state machine in E0013. Repository contracts, handler tests, and API/controller responses would resolve whether empty objects, null, exceptions, or validation errors are the intended outcomes.

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

Open question for Harten: What is the complete authorization matrix for external users, internal assessors, administrators, owners, and shared users? The inspected artifacts are request authorization declarations and controller observations in E0001, E0017, and E0419. Runtime authorization-pipeline implementation, permission registrations, and representative end-to-end tests would resolve this.

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

Open question for Harten: Is external completion deliberately allowed without the internal receipt-date ordering guard? The inspected artifact is Movement.cs, CreateStateMachine(), and completion methods summarized in E0013. A direct comparison of external and internal completion tests or the complete domain implementation would establish the intended rule.

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