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

06 — Conceptual information model

Purpose and scope

The current system represents information required to receive, assess, decide, monitor and report on import notifications. At the centre is an import notification, with associated parties, facilities, routes, waste classifications, shipments or movements, assessment information, financial guarantees, comments and audit or progress information. The evidence supports a structural model of these records and selected handling behaviour; it does not establish that the model is complete, that all cardinalities are enforced, or that every represented field is populated in every workflow. E0006 E0010 E0156

The primary actors evidenced by the source are external applicants and parties recorded on notifications, internal users who assess or administer notifications, and system handlers and repositories that read, change and persist records. Internal-user context is explicitly passed into assessment status auditing, while comment-user lookup resolves internal user IDs to full names. The precise roles and permissions of external parties are not established by the supplied excerpts. E0010 E0081

flowchart LR
    N[Import notification]
    A[Assessment]
    FG[Financial guarantee]
    M[Movement / shipment]
    W[Waste and operation data]
    P[Parties, facilities and route]
    C[Comments and audit/progress data]

    N --> A
    N --> FG
    N --> M
    N --> W
    N --> P
    N --> C
    A --> FG

The diagram shows relationships evidenced by handlers, models and schema scripts. It should not be read as a complete entity-relationship diagram: uniqueness, optionality and exact foreign-key coverage remain partly unresolved. E0006 E0007 E0191

Notification identity and business information

An import notification has a data shape containing an identifier, notification number, creation date, status and charge. The presence of NotificationId, NotificationNumber, CreatedDate, Status and Charge is directly evidenced in SubmitSummaryData. The source does not prove that the identifier is database-enforced as unique, that the charge is monetary, or that CreatedDate is the actual submission timestamp. E0006

The notification information is extended by competent-authority data, notification type, intended dates, quantity and shipment counts, consent dates, pre-consent state and interim status in reporting projections. The reporting view combines export and import notifications and exposes these values, but reporting joins can also determine whether a row appears in a report. Consequently, a missing row in a report cannot by itself be interpreted as a missing notification. E0081

Competent authorities are represented by an enumeration containing England, Scotland, Northern Ireland and Wales, with display metadata for the relevant environmental agencies. This establishes the vocabulary, not how an authority is selected or validated. Authority-specific notification-number sequences are also present in the database scripts, but their runtime use is not demonstrated in the supplied SQL evidence. E0006 E0156

Parties, facilities and movement context

The model and database scripts represent importers, exporters, producers, carriers, facilities, facility collections, transport routes, transit states, states of export and states of import. The scripts also contain nullable facility and importer registration-number columns. These records provide the context in which a notification’s waste is moved and treated. E0007

A notification may therefore describe several operational participants rather than a single organisation: an importer receiving the waste, an exporter arranging the shipment, one or more producers, carriers, and treatment or disposal facilities. A test fixture demonstrates an importer treatment site and another treatment site in the same facility collection, as well as multiple carriers and producers. This is evidence of a supported example, not proof that every notification must contain those records or that their cardinality is consistently enforced. E0226

Repository code confirms that notification searches apply a competent-authority restriction and search notification number or importer name. The same repository projects exporter, importer and status data, but the inspected search method does not visibly search exporter names. Whether another search path or caller supplies exporter searching is unknown. E0262

Open question for Harten: the inspected artefacts were ImportNotificationSearchRepository.SearchBySearchTerm and the visible import-notification schema scripts. Evidence needed: the complete search contract, all search implementations and integration tests, showing the supported searchable fields and the intended cardinality of importer, exporter, producer, carrier and facility records.

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

Waste classification and operations

Waste information is represented through category and code selections. The observed model includes Basel/OECD, EWC, Y, H and UN code selections, together with an optional waste category. A selection can be marked not applicable; otherwise it is empty when it contains no selected codes. WasteType aggregates these selections, while update-oriented data carries selected code IDs, available code data, flags and the import-notification identifier. E0093

Waste operations carry operation codes and technology employed. Recovery operation codes R1–R13 and disposal operation codes D1–D15 are represented with metadata identifying their category. The evidence establishes the code vocabulary and categorisation, but not permitted combinations with notification type or the validation algorithm that consumes the localised waste-validation messages. E0006 E0010

The system exposes six resource messages for Basel/OECD, EWC, H, UN, waste-name and Y-code validation. No validator implementation or conditional logic consuming those keys is shown in the inspected material. The messages therefore establish user-facing validation concepts, not the circumstances in which they are enforced. E0010

Shipments, movements and quantities

The current information model distinguishes intended shipments from actual movements and records movement numbers, dates, quantities, units, receipt information, rejection, recovery, cancellation and partial rejection. Domain code defines movement states including New, Submitted, Received, Completed, Rejected, Cancelled, Captured and PartiallyRejected; a separate audit vocabulary includes events such as prenotification, receipt, recovery, rejection, cancellation, editing and deletion. Enum presence does not by itself prove that every value is used or that the values form a single linear lifecycle. E0096

The domain state machine provides more concrete evidence. It allows, among other transitions, New to Submitted, Received, PartiallyRejected or Rejected; Submitted to Received, Rejected, Cancelled or PartiallyRejected; Received to Completed, Rejected, PartiallyRejected or Cancelled; and PartiallyRejected to Completed. Rejected and Cancelled appear terminal within the inspected state-machine definition, although other application code could affect stored records. E0013

Movement creation is gated by several checks in MovementFactory: movement-date validity, movement-count limits, active-load limits, remaining quantity, notification status, an approved financial guarantee, consent-period validity and movement-number generation. The evidence does not establish that these separate reads and the eventual creation are transactionally atomic. E0372

Quantity summaries derive received quantities from received or completed movements, movement receipts, partial-rejection records and separately retrieved partially rejected movements. The implementation uses the first partial-rejection record in one path, so multiple partial-rejection records may not be fully aggregated by that path. E0372

Assessment, consent and financial guarantees

Assessment information includes status, milestone dates, officer name, decision history, consent information, objections, withdrawal, prohibition history and interim status. The status vocabulary includes notification received, submitted, awaiting payment, awaiting assessment, in assessment, decision required, consented, consent withdrawn, objected, withdrawn, file closed, resubmitted and under prohibition. These values are represented in the model; the complete transition policy is established only where state-machine code is visible. E0093 E0259

The observed submission path is significant: in the assessment state machine, NotificationReceived accepts the Submit trigger and is configured to move to AwaitingPayment, while also raising ImportNotificationSubmittedEvent. Submitted is represented as a broader state or hierarchy context, but the concrete destination shown is AwaitingPayment, not necessarily the literal Submitted value. E0508

Consent persists a date range, conditions and a consent date, followed by SaveChangesAsync. The handler establishes the data change and persistence request, but not the domain validation for dates, conditions or eligibility. E0010 E0482

Financial guarantees have statuses including AwaitingApplication, ApplicationReceived, ApplicationComplete, Approved, Refused and Released. Creation, approval, refusal and release have separate handlers. Approval includes a reference; refusal includes a reason; release carries no additional decision detail in the observed call. Status changes are audited with source and destination status, user ID and, for financial guarantees, a UTC timestamp. E0093 E0010

The visible guarantee state machine shows ApplicationReceived to ApplicationComplete, then Approved or Refused, and Approved to Released. A direct transition from ApplicationComplete to Released is not evidenced. Date view models require received, completion and decision dates to be present, non-future and correctly ordered, but the behaviour of the underlying optional-date parser is not supplied. E0508 E0516

Comments, audit and reporting information

Comments are associated with notifications and can include comment type, shipment number, user and timestamps. Retrieval supports notification, type, date, shipment and user filters, paging and total or filtered counts; the observed page size is 10. A separate handler resolves comment user IDs to internal-user full names. E0010

Assessment status changes record the old and new status and the acting user. Movement audit categories are defined, but the supplied model excerpt does not prove that every category is emitted or persisted as an audit record. Reporting procedures rebuild shipment, producer and freedom-of-information caches by deleting existing cache rows and repopulating them from report sources. E0096 E0218

Current-system requirements and characterisation candidates

The following requirements describe observed current behaviour, not a target design:

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

• REQ-IM-001 — Represent notification identity. The system shall expose an import-notification identifier, notification number, creation date, status and charge in the submission-summary data shape. E0006
• REQ-IM-002 — Record consent details. When consent is handled, the system shall pass a notification ID, consent date range, conditions and consented date to the consent operation and request persistence. E0010
• REQ-IM-003 — Record guarantee decisions. The system shall represent approval with a reference, refusal with a reason, and release as a separate guarantee operation. E0010
• REQ-IM-004 — Audit assessment status changes. The system shall record source status, destination status and acting user for an assessment status change. E0010
• REQ-IM-005 — Page and filter comments. The system shall support the observed comment filters and return page, total and filtered results using the observed page size of 10. E0010
• REQ-IM-006 — Apply movement creation gates. The movement creation path shall evaluate movement date, count, active loads, remaining quantity, consented status, approved guarantee and consent-period validity before generating a movement number. E0372

Candidate characterisation scenarios:

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

Scenario: Submit a notification awaiting payment
  Given an assessment is in NotificationReceived
  When the Submit trigger is handled
  Then the assessment enters AwaitingPayment
  And an ImportNotificationSubmittedEvent is raised

Scenario: Consent an import notification
  Given a notification has a consent date range and conditions
  When the consent handler is invoked
  Then the consent operation receives the range, conditions and consent date
  And changes are requested through SaveChangesAsync

Scenario: Retrieve filtered comments
  Given comments exist for a notification
  When notification, type, date, shipment or user filters are supplied
  Then the handler returns mapped comments with total and filtered counts
  And the observed page size is 10

Open question for Harten: the inspected handlers, domain models and SQL scripts do not establish complete cardinality, uniqueness, transaction boundaries or end-to-end validation. Evidence needed: deployed schema constraints, ORM mappings, command-handler integration tests and representative production workflow traces.

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