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

Behaviours

Behaviours

The system supports preparation and administration of international waste-shipment notifications, including export and import notifications, assessments, consent, financial guarantees, movements, shipments, waste and recovery information, facilities, carriers, routes, customs offices, documents, comments, reporting and user access. The evidence describes an application family using ASP.NET MVC and Web API components, mediator-style requests, repositories, Entity Framework, SQL Server procedures, document generation, email, scanning and identity services. It is not established that all components share one deployed runtime or application boundary.

Actors and access context

Supported actors include external applicants and notification owners, exporters, importers, producers, carriers, shared users, internal competent-authority users, administrators and system-operated services. Internal users may be associated with a competent authority and local area. External access is described as depending on notification ownership or sharing. The cited import-notification authorization path denies access to non-internal users, while export-notification access may check ownership or sharing.

Authorization is represented through controller attributes, request permissions, ownership filters, competent-authority checks, read-only filters and authorization services. A role-based component is described as denying unknown activities and granting configured permissions where user roles intersect. These mechanisms demonstrate intended access-control boundaries, but the complete role and claim model, registrations, enforcement coverage and effective permissions for each operation are not established. Some identifier-based repository methods do not show repository-level authorization; enforcement may occur in controllers, handlers, middleware, decorators, stored procedures or callers.

Notification creation and editing

A notification can be created with a notification type, competent authority and notification number or number-generation option. Notification data may include parties, facilities, producers, carriers, shipments, waste, routes, customs offices, dates, assessments, charges, guarantees, documents, comments and sharing information. Notification creation is associated with a notification-created event. One observed creation path creates an assessment and financial-guarantee collection before saving; other paths may save the notification and related data in separate operations.

The user interface supports multi-step entry and editing of organisation, address, contact, producer, facility, shipment, waste, transport and customs information. Some views display notifications as read-only after assessment or when their status is not editable. Test-derived expectations permit editing in early or unlocked states such as NotSubmitted, Submitted, NotificationReceived, InAssessment and Unlocked, and disallow editing in states including ReadyToTransmit, Transmitted, DecisionRequiredBy and UnderProhibition. Editability for several other states is unresolved.

Posted identifiers, status values, notification numbers, dates, selected facilities, selected users and charge values are often represented in hidden fields. The evidence does not establish consistently whether handlers reload authoritative state, verify ownership and membership, reconcile posted values or recheck deletion and edit eligibility.

Assessment lifecycle

Assessment statuses represented in the evidence include NotSubmitted, Submitted, NotificationReceived, InAssessment, ReadyToTransmit, Transmitted, DecisionRequiredBy, Consented, ConsentWithdrawn, Resubmitted, Reassessment, Objected, Withdrawn, FileClosed, UnderProhibition, InDetermination, AwaitingPayment and AwaitingAssessment. These values establish available representations but not a complete production state machine.

Observed and test-derived transitions include:

• A new assessment begins as NotSubmitted.
• Submission requires notification progress to be complete, changes the status to Submitted or a configured substate such as AwaitingPayment, and raises submission and status-change events.
• Receipt from a submitted state records a received date and changes the assessment to NotificationReceived.
• Commencement requires a received state, a payment-received date and a non-empty officer name, then changes the state to InAssessment.
• Further operations include completion, transmission, acknowledgement, consent, consent withdrawal, unlocking, reassessment, resubmission, rejection of changes, prohibition and file closure.
• Consent withdrawal records a date and reason.
• Archive-reference assignment is reported to require file closure.
• Setting prohibition records a current UTC time; removing prohibition uses a previous status and a current UTC time.

One state-machine description places AwaitingPayment beneath Submitted while showing NotificationReceived transitioning directly to AwaitingPayment. Other evidence uses Submitted as the concrete submission state. The relationship between parent and concrete states, and which value is persisted or displayed, is unresolved.

Submission and other state changes may raise domain events and may create status-history records containing status, user and timestamp information. Event publication, consumer behaviour, persistence, retry and failure handling are not established.

Consent and key dates

Consent processing accepts a notification identifier, validity start and end dates, conditions and a consent date, invokes a domain operation and requests persistence when successful. The evidence does not establish all eligibility rules, date-ordering rules, authority permissions, or downstream effects.

Key-date operations cover notification receipt, assessment commencement, notification completion, acknowledgement, transmission, decision-required-by, consent validity, withdrawal, objection, file closure, archive reference and prohibition. Some handlers update assessment dates and then conditionally update related consent, withdrawal or objection records. Separate implementations appear to coordinate these dates differently for import and non-import notifications.

Decision-required dates may preserve an existing value, return no value without an acknowledgement date, or be calculated using seven working days for preconsented facilities and 30 calendar days otherwise. Financial-guarantee decision deadlines are separately described as using 20 working days after completion. The working-day implementation, holiday source, time-zone treatment and authoritative calculation are not established.

The evidence contains date-rule contradictions. A prenotification-to-shipment limit is implemented or tested as 60 days in some paths, while messages state 30 days. Other views describe a three-working-day minimum, while consent-expiry material refers to three or four working days. The effective rules and boundary inclusivity remain unresolved.

Financial guarantees

Financial guarantees support creation, completion, approval, refusal, release, replacement and history. Represented statuses include AwaitingApplication, ApplicationReceived, ApplicationComplete, Approved, Refused, Released and Superseded. Decisions include None, Approved, Refused and Released.

Observed rules include:

• Approval requires an application to be complete.
• Approval requires a nonblank reference and may require positive active-load and permitted-load values.
• Refusal requires completion, an appropriate decision date and a nonblank reason.
• Release is described as available for approved guarantees, although the complete eligibility rule is not established.
• A guarantee with the same reference may supersede an existing approved guarantee; a different reference may release it.
• Decision dates must be ordered relative to received or completed dates in the cited validation paths.
• Financial-guarantee status changes may record the source status, destination status, user and UTC timestamp.

One visible state description permits ApplicationComplete to transition to Approved or Refused, with Approved transitioning to Released; a direct transition from ApplicationComplete to Released is not evidenced. Approval, refusal and release may change aggregate state before a decision record is created, but transaction or rollback coordination is unknown. Multiple approved guarantees may be accepted in one path and fail in another path using a single-result lookup.

A monetary upper limit of 9,999,999.99 appears in related validation messages, but the corresponding checks are commented out in the supplied evidence. The active enforcement of that limit is therefore unresolved.

Movements and shipments

Movement states include New, Captured, Submitted, Received, Completed, Rejected, Cancelled and PartiallyRejected. A state-machine description shows captured or new movements progressing to submission or receipt; submitted and received movements can be rejected, cancelled or partially rejected; received movements can be completed; and partially rejected movements can subsequently complete. Rejected and cancelled appear terminal within that definition, but other code may still affect those records.

Movement creation or capture records a movement identifier and number, movement date, creator, creation time and prenotification information. Movement creation or movement-date validation may check:

• movement-date validity and consent-period membership;
• notification consent status;
• shipment and movement-count limits;
• active loads and remaining quantity;
• an approved financial guarantee;
• movement-number availability;
• shipment date relative to prenotification;
• future and past-date restrictions.

Movement numbers are generated by selecting an unused positive number or the next available number. The evidence does not establish database uniqueness or concurrency protection, so concurrent generation behaviour is unknown.

External and internal receipt paths differ. External receipt requires a non-default file identifier, date and quantity. Internal receipt requires a date and quantity and rejects dates later than the current UTC date; it does not visibly require a file identifier. External completion requires a date and file identifier. Internal completion additionally rejects future dates and dates earlier than the recorded receipt date. Equivalent validation and authorization across the two paths are not established.

Receipt, rejection and partial-rejection records can coexist in the supplied data structures. One mapper gives rejection data precedence over receipt data, while another path allows partial-rejection data to overwrite receipt quantity, unit and received state. Separate evidence says rejection or partial rejection may clear a receipt when a movement was previously received; another review did not observe receipt clearing in the receive methods. This is an unresolved contradiction.

Partial rejection requires a rejected quantity less than the actual quantity in the cited implementation, so equality is rejected despite wording that refers only to exceeding the actual quantity. A nonblank reason is required in some paths, although IsNullOrEmpty permits whitespace-only text. Completion after partial rejection may access a missing receipt, but an omitted invariant may prevent that state.

Movement creation, receipt, rejection and completion can save movement data, certificates, files and audit records in separate operations. Some bulk movement flows use explicit transactions and roll back on exceptions; transaction coverage for ordinary movement, file storage, audit writes and deletion is not established.

Waste, packaging and routes

Waste information includes waste types, EWC, Basel, OECD, Y, H, UN and customs codes, chemical composition, components, packaging, physical characteristics, operation codes, recovery and disposal information, technology employed and annex indicators.

Observed validation and mapping rules include:

• applicable code categories require a selected code unless marked not applicable or not listed;
• codes must have compatible code types;
• duplicate codes may be rejected;
• recovery and disposal operation codes cannot be mixed in cited validation;
• technology-employed text has a reported 70-character limit;
• an attached process document may satisfy a process-of-generation requirement;
• further details may be invalid when an annex is supplied;
• recovery percentages are represented on a 0–100 scale in some paths;
• disposal and recovery values may be removed when provider or percentage conditions change.

The complete combinations of code, not-applicable, custom-code and not-listed flags are not established. Some mappings give persisted codes precedence over custom or not-applicable representations, while other paths use custom-code precedence. Unknown code types can raise exceptions.

Transport routes contain state-of-export, state-of-import, transit states, entry and exit points, customs offices and competent authorities. Transit-state positions are represented by ordinal values. Observed rules reject duplicate positions, assign new positions after the current maximum and renumber remaining states after removal. Some validation checks that positions collectively contain all values from one through the number of states but does not require input order. The complete route and customs-office policy, including the contradictory internal-EU evidence, remains unresolved.

Documents, uploads and scanning

Documents are generated from ordered blocks and Open XML templates. Blocks may populate the main document or annexes. Carrier, facility, customs-office, producer, waste-code, transport and other blocks have authority- and data-dependent annex behaviour. Annex numbering, block order, facility cardinality and template fields are operationally significant.

Generation may fail when expected merge fields, tables, rows, document settings, facilities, carriers or producers are missing or duplicated. Some generation paths mutate internal collections or document state, so repeated invocation may not be idempotent. Saving, transmission, file persistence, rendering quality and downstream access are not established.

Uploads include certificates, movement documents, prenotification files, receipt-recovery files and supporting documents. Forms may validate file presence, declared content type, size or content rules, and some paths invoke a virus scanner. A file scanner can return outcomes such as unknown, clean, virus or error; one implementation treats a missing temporary file as a virus result. The evidence does not establish content-signature validation, quarantine, cleanup, scanner outage handling, upload limits, retention or access control.

Reporting and search

Reports and searches cover notification numbers, authorities, dates, statuses, notification type, trade direction, organisations, producers, importers, facilities, waste codes, operations and financial guarantees. Report outputs include spreadsheet files, with selected views using date-range filters, report-column selections and cached or delayed data.

SQL and repository paths use Entity Framework, raw SQL, stored procedures, joins, caches and date filtering. Some reporting uses inclusive BETWEEN ranges, while other audit paths use end-exclusive ranges. Some report queries use inner joins that may exclude notifications missing related data; other paths use left joins. Cache refresh timing and consistency are unknown.

Search and reporting errors may return empty results, model-state errors, HTTP errors or exceptions. One notification-number regular expression is not anchored, allowing a matching substring to pass if the inspected code is active. A search path is described as filtering by competent authority and importer name, without exporter-name filtering despite broader descriptions suggesting exporter search. These are bounded source observations rather than confirmed production defects.

Failure paths and evidence limits

Observed or possible failure paths include invalid model state, missing or duplicated records, strict Single or First lookups, malformed dates and numbers, invalid enum values, null collections, missing claims, missing files, scanner errors, document-template failures, database exceptions, migration failures, authorization denial and expired temporary state.

Failure handling is heterogeneous. Some handlers return false, null, empty objects or default values; some throw domain or argument exceptions; some catch broad exceptions and return null or a generic error; some repository paths roll back and rethrow; and some archive or configuration paths suppress exceptions and return a failure indicator. The system-wide error contract, logging, retries, monitoring and user-visible translation are not established.

The supplied evidence does not establish the complete database schema, deployed topology, route inventory, authorization registrations, transaction boundaries, concurrency controls, retention, backups, recovery, production callers, external integrations or complete lifecycle enforcement. Test assertions, source summaries, resource strings and candidate scenarios are evidence of represented or intended behaviour, not evidence that tests were executed or that all described behaviour occurs in production.

Content quality review

Advisory; not approval. Review status: advisory.

Review

Overall assessment

The draft is highly relevant to behaviours.md and is unusually careful about uncertainty. It distinguishes source observations, test-derived expectations, inferred architecture and unknown runtime behaviour in many places. It also preserves the principal contradictions in the evidence rather than silently selecting one interpretation. The coverage is broad enough to describe the major notification, assessment, guarantee, movement, waste, document, reporting and access-control areas.

However, the draft is so comprehensive that it sometimes becomes an evidence catalogue rather than a focused behaviour description. It also occasionally uses “supports”, “can”, or “requires” where the evidence establishes only that a view, request, test, or source path represents the behaviour. The most important correction is to make the evidence status of each behaviour more explicit and to separate observed implementation, tested expectation, UI intent, and unresolved production behaviour.

This review is advisory; it does not establish that the draft is complete or verified.

Relevance and purpose

The draft is relevant to the requested purpose because it describes:

• actors and access context;
• notification creation and editing;
• assessment and consent;
• financial guarantees;
• movement and shipment processing;
• waste, packaging and routes;
• documents, uploads and scanning;
• reporting and search;
• failure behaviour and evidence limits.

The structure is generally sensible for a behaviour document. The opening architecture qualification is useful because the supplied material covers multiple projects and source ranges, and does not prove one deployed application boundary.

The principal scope problem is that the document mixes three different purposes:

1. a description of user and business behaviour;
2. a source-level technical findings catalogue; and
3. an evidence-gap and assurance assessment.

For example, regular-expression anchoring, Single versus SingleOrDefault, Open XML mutation, SQL join shape, migration syntax and Task.Run(...).Result are useful review findings, but they are not all behaviours in the same sense as “submission changes an assessment status” or “receipt requires a quantity”. They should either be explicitly labelled as implementation observations and risks, or moved to a separate findings section.

Supported or reasonably supported content

The following parts are broadly supported, subject to the draft’s own qualifications:

• The application family concerns international waste-shipment notifications and includes export and import material.
• The supplied source includes MVC, Web API, mediator-style requests, repositories, Entity Framework-related code, SQL Server objects, document generation, email, scanning and identity-related components.
• Internal and external access paths differ, including competent-authority, ownership, sharing and import-notification restrictions.
• Notification creation involves notification type, competent authority and notification-number handling.
• Assessment statuses and movement statuses are represented in the supplied material.
• Tests and source observations support selected lifecycle operations, including submission, receipt, commencement, transmission, acknowledgement, consent, withdrawal, unlocking, reassessment, prohibition and closure.
• Financial-guarantee operations include creation, approval, refusal, release, replacement or supersession, and history-related data.
• Movement processing has different internal and external receipt and completion paths.
• Waste and route data include the broad code, operation, facility, customs and authority concepts described.
• Document generation is block- and template-oriented and depends on ordered blocks, merge fields, annexes and expected document structure.
• Report and search paths use different joins, date ranges, caches and query mechanisms.
• Error and persistence handling is heterogeneous in the supplied source.
• The evidence does not establish deployment topology, complete schema, complete route coverage, effective permissions, transaction coverage, concurrency controls, retention, recovery or production execution.

The draft is also correct to say that test assertions, resource strings and source summaries do not prove that behaviour was executed or is complete in production.

Claims that should be narrowed

Several formulations are stronger than the evidence safely supports.

“The system supports…”

The opening sentence says:

> “The system supports preparation and administration…”

This is a reasonable high-level interpretation, but the evidence describes several projects, source ranges and possibly separate applications. A safer wording would be:

> “The supplied evidence describes components and workflows intended for preparation and administration…”

Similarly, statements such as “A notification can be created”, “A notification can be submitted”, “Documents are generated”, or “Uploads include…” should distinguish source-visible capability from demonstrated runtime capability.

Suggested pattern:

• “The evidence shows a creation path that…”
• “Tests expect submission to…”
• “Views present a workflow for…”
• “Source code attempts to generate…”
• “Production persistence or successful completion is not established.”

“These mechanisms demonstrate…”

The access section says the mechanisms “demonstrate intended access-control boundaries”. That is mostly fair, but “demonstrate” can imply effectiveness. Replace with:

> “These mechanisms represent intended access-control boundaries in the supplied source…”

The same distinction should be used for anti-forgery tokens, role attributes, filters, read-only views, upload validation and health endpoints.

Exact lifecycle claims

The lifecycle section lists many statuses and transitions together. Some are:

• visible enum values;
• state-machine configuration;
• unit-test expectations;
• controller branches;
• resource or summary descriptions.

They should not appear as one homogeneous set of “observed transitions”. The draft should identify the evidence class for each group. For example:

> “Unit tests support the following transitions…”
> “A separate state-machine configuration represents…”
> “Controller or view evidence indicates…”
> “The relationship between these representations is unresolved.”

This is particularly important for Submitted, AwaitingPayment, ReadyToAcknowledge, AwaitingAssessment, ConsentedUnlock and related substates.

“Submission requires…”

The statement that submission requires notification progress to be complete is supported by tests and the cited handler descriptions, but it should remain explicitly test/source-local. It should not read as an application-wide invariant unless all submission paths have been checked.

The same applies to:

• commencement requiring payment and officer name;
• archive-reference assignment requiring file closure;
• approval requiring completion;
• release being available only for approved guarantees;
• movement creation requiring an approved financial guarantee;
• receipt and completion requirements.

These are often well supported in one path, but the evidence repeatedly says that other controllers, handlers, procedures or callers are absent.

“Rejected and cancelled appear terminal”

This is appropriately qualified, but it would be clearer to say:

> “The inspected state-machine definition shows no outgoing transitions from Rejected or Cancelled; this does not establish that all application paths treat them as terminal.”

That avoids implying a domain conclusion from one configuration.

Contradictions that are preserved but should be made more actionable

The draft correctly records several contradictions, but some need a clearer statement of the competing evidence and the required resolution.

Prenotification date limit

The 30-day versus 60-day contradiction is one of the strongest issues and is correctly identified. It should explicitly separate:

• executable comparison;
• exception text;
• resource text;
• test expectation;
• any fleet or documentation description.

The correction should not merely say “effective rules remain unresolved”; it should state that the authoritative rule cannot be identified from the supplied evidence and that boundary tests are needed for 30, 31, 59, 60 and 61 days, including date-only versus timestamp inputs.

Three- versus four-working-day wording

The draft mentions three- or four-working-day material, but the contradiction would benefit from specifying whether the difference is between:

• a consent-expiry view;
• a prenotification warning;
• a resource string;
• a controller rule; or
• a test.

Otherwise readers may treat all “three” and “four” references as one rule.

Customs-office internal-EU behaviour

The draft refers to “contradictory internal-EU evidence” but should state the concrete conflict: some test names or descriptions suggest None, while executable assertions require EntryAndExit. This is more useful than a general statement that the policy is unresolved.

Movement receipt precedence and clearing

This is one of the best-preserved contradictions in the draft. It distinguishes mapper precedence, rejection clearing, receive-path observations and database-side behaviour. It should additionally state that these may be different layers rather than logically inconsistent implementations. The unresolved question is not only “does rejection clear receipt?” but also:

• whether receipt and rejection records are allowed to coexist;
• which representation is authoritative;
• whether the mapper is reconstructing a state or merely selecting display precedence; and
• whether database procedures and domain handlers operate on the same tables.

Financial-guarantee release

The draft says release is available for approved guarantees but also notes uncertainty about the complete eligibility rule. It should explicitly preserve the distinction between:

• a state-machine transition;
• a handler precondition;
• a view link;
• a domain method; and
• a database decision record.

Otherwise the text could imply that the state machine and handlers agree.

Missing or underdeveloped behaviours

Despite its length, the draft underrepresents several behaviour areas that appear repeatedly in the supplied evidence.

Registration and account lifecycle

The draft mentions user access and identity, but does not provide a consolidated account behaviour section covering:

• applicant registration;
• organisation selection and organisation creation;
• email verification;
• password reset and password update;
• test-email behaviour;
• internal-user approval and rejection;
• role assignment;
• activation, deactivation and reactivation;
• lockout behaviour;
• account ownership and user claims.

These are material behaviours, not merely security implementation details. They should be added or explicitly stated as outside the intended scope.

Ownership transfer, sharing and copying

Sharing is mentioned, but ownership transfer and notification copying are comparatively thin. The evidence describes:

• selecting an owner;
• confirmation through temporary state;
• shared-user limits and duplicate handling;
• removal of shared users;
• copying notifications;
• preservation and exclusion of particular child data;
• same-authority and different-authority route-copy behaviour;
• audit effects.

These should be consolidated into a dedicated “Ownership, sharing and copying” section. They are important because they cross workflow, authorisation, data integrity and persistence boundaries.

Payments, refunds and charges

The draft discusses charges and financial guarantees, but payment and refund behaviour is largely absent as a coherent area. The supplied evidence includes:

• payment transaction creation;
• refund validation;
• cheque receipt requirements;
• payment-completion and balance calculations;
• payment-received-date updates;
• transaction deletion;
• additional-charge display and possible payment gating;
• inconsistencies between payment and refund return values;
• possible negative remaining balances.

These should be described separately from financial guarantees. A financial guarantee is not the same behaviour as payment or refund processing.

Archive and deletion semantics

The draft mentions archive reference and file closure, but archive and deletion as user-visible operations need more explicit treatment:

• archive selection and limits;
• per-notification failure handling;
• whether archive is all-or-nothing;
• archive masking or removal of data;
• export versus import deletion;
• deletion scope;
• deletion irreversibility;
• audit and recovery implications.

The evidence does not establish these semantics, but their absence is itself important for a behaviour document.

Consultations, feedback and message banners

Consultation creation/retrieval, feedback submission, and message-banner retrieval appear in the evidence but are not meaningfully represented in the draft. These can be included briefly as “additional workflows represented in the evidence, with runtime effects unresolved”.

Maintenance and health behaviour

The draft mentions maintenance mode and scanning health, but it should distinguish:

• an anonymous scanner health-style GET returning "ok";
• a scanner POST operation;
• maintenance-mode 503 responses;
• exempt endpoints;
• whether these are production routes;
• whether health checks test dependencies or only process availability.

The current wording is cautious but the behaviours are dispersed.

Evidence gaps versus defects

The draft generally distinguishes these correctly, but a few phrases should be revised.

A missing repository-level authorization check is not a defect by itself. The draft says this in several places, but should consistently classify it as:

> “Not evidenced at this layer; may be enforced by a caller, handler, decorator, middleware, stored procedure or database.”

Likewise:

• an uninitialised collection is an implementation risk, not necessarily a defect if binding or ORM materialization supplies it;
• a missing SaveChanges call is not necessarily a defect if the repository or unit of work saves;
• a view without an anti-forgery token is not automatically a CSRF defect if the action is read-only or protected elsewhere;
• Html.Raw is an output-encoding risk, not proof of XSS without provenance and sanitisation analysis;
• a missing transition in one state-machine configuration is not proof that the whole application disallows it;
• a commented-out monetary check is evidence that the check is inactive in that path, not proof that no other layer enforces the limit.

The draft should avoid calling some issues “possible production defects” unless it states the exact preconditions and missing evidence.

Evidence provenance and auditability

The evidence supplied to the draft contains many notes, source ranges and internal contradictions, but the draft does not map major claims to identifiable evidence locations. Because behaviours.md is intended to be reviewable, major assertions should be traceable to the supplied evidence at least by source area, test area or evidence reference.

This is especially important for:

• the assessment transition list;
• exact date calculations;
• financial-guarantee transition rules;
• external/internal movement differences;
• the scanner route and health response;
• report joins and date boundaries;
• database transaction claims;
• document annex thresholds.

No citations or identifiers should be invented. The correction is to attach available provenance where it exists and otherwise label the statement as a synthesis of multiple supplied notes.

Duplication and prioritisation

The draft repeats the same limitation in many sections:

• complete authorization is unresolved;
• persistence and transaction boundaries are unknown;
• source and test evidence do not prove production behaviour;
• omitted implementations may exist elsewhere.

These points are valid but repeated too often. A shorter global evidence statement would allow each section to focus on its specific uncertainty.

The draft also gives similar weight to major business contradictions and minor source-quality observations. The 30/60-day rule, movement receipt consistency, financial-guarantee state integrity, hidden-identifier revalidation and migration safety are materially more important than spelling anomalies, regex anchoring or resource-key typos. Consider classifying findings as:

• directly observed behaviour;
• tested expectation;
• contradiction requiring resolution;
• conditional implementation risk;
• absent evidence.

That would make the document more useful without asserting severity or approval.

Suggested structural correction

A clearer structure would be:

1. Scope and confidence
2. Actors and access context
3. Notification creation, editing and ownership
4. Assessment, consent and key dates
5. Payments, refunds and financial guarantees
6. Shipments, movements, receipts and rejection
7. Waste, packaging, routes and customs
8. Documents, uploads and scanning
9. Reporting, search and cached data
10. Account and administration workflows
11. Failure, persistence and event behaviour
12. Known contradictions
13. Evidence gaps and unresolved questions

Within each section, use a consistent distinction such as:

• Observed in source
• Supported by tests
• UI or resource intent
• Not established
• Correction or question

This would prevent source-level observations from being mistaken for system-wide behavioural claims.

Specific wording corrections

Examples of safer replacements include:

• Replace “The system supports preparation…” with “The

supplied evidence describes components and workflows intended for preparation and administration…” - Replace “A notification can be created” with “A notification-creation path is represented in the supplied source…” - Replace “Submission requires…” with “The cited submission tests and handler path require…” - Replace “Documents are generated” with “The supplied document-generation code attempts to generate…” - Replace “Uploads include…” with “The supplied upload views and handlers represent uploads for…” - Replace “These mechanisms demonstrate…” with “These mechanisms provide source-level evidence of intended…” - Replace “Release is available for approved guarantees” with “The cited state-machine or handler path permits release from an approved state; equivalent enforcement across other paths is not established.” - Replace “The system-wide error contract is heterogeneous” with “The supplied handlers exhibit different local failure conventions; a system-wide error contract is not established.”

The draft should also avoid implying that a named status is necessarily persisted. For example, “changes the status to Submitted” should become “the cited test or domain path changes the in-memory or handled assessment status to Submitted; the persisted value and downstream display are not established,” unless the persistence step is directly shown.

Additional missing behaviours to add or explicitly scope out

The proposed structure would improve the document, but several behaviours should be added before treating it as a usable behavioural account.

Account and administration

A separate account and administration section should consolidate the registration, verification, password, internal-user and lockout evidence. It should distinguish:

• view and controller presentation;
• tested validation expectations;
• identity-service calls;
• role or status changes;
• lockout-date updates;
• claims creation or removal;
• email delivery;
• persistence and failure handling.

The evidence includes possible differences between approval status and administrator privilege, role claims and internal-user status claims, and activation or reactivation paths that may not symmetrically clear lockout. These should remain unresolved questions rather than being presented as one coherent account lifecycle.

Ownership, sharing and copying

Ownership transfer, shared access and copying should be described together because they all affect notification access and related data. The section should state which parts are directly visible: email or user selection, confirmation, temporary state, duplicate checks, removal controls, copy requests, selected fields copied, excluded intended shipments, and route differences when authorities differ. It should separately state that final authorization, ownership checks, copied-data completeness, audit atomicity and persistence are not established.

Payments, refunds and additional charges

Payment transactions, refunds, charges and financial guarantees should not be treated as one behaviour. The evidence indicates distinct concerns:

• payment and refund amounts, dates, comments and receipt numbers;
• calculation of paid, billable, remaining and refund amounts;
• payment-completion and assessment-date effects;
• deletion of payment transactions;
• additional-charge calculation or display;
• possible payment gating for shipment-count increases;
• differing handler return values.

The draft should not infer that a displayed charge is calculated, invoiced, paid or enforced. It should also preserve the unresolved meaning of negative balances and the reported difference between payment and refund handler results.

Archive, deletion and retention

Archive and deletion need separate descriptions. A deletion warning or resource string establishes user-facing intent, not deletion scope or execution. Archive processing appears in some evidence to process records individually and continue after failures, while other paths use explicit transactions for selected operations. The document should state that the relationship between archive masking, physical deletion, file removal, audit retention and recoverability is not established.

Consultations, feedback and message banners

These can be short subsections. The evidence represents consultation retrieval or creation, feedback forms and confirmation pages, and active-message-banner retrieval. It does not establish their persistence, audience, expiry, authorization, delivery, or whether a banner endpoint is intentionally public.

Maintenance and health

The scanner health-style action, scanner POST and maintenance-mode response should be described as separate behaviours. The supplied evidence supports an anonymous GET returning "ok" in one implementation and a maintenance filter capable of returning HTTP 503 in a tested path. It does not establish that either is deployed, that the health action tests dependencies, or that maintenance mode covers all routes and background work.

Evidence-status labelling

The draft would benefit from visibly tagging claims by evidence class. A compact convention could be used throughout:

• Source observation: directly visible in supplied code, configuration or SQL.
• Test expectation: asserted or configured in a supplied test; execution is not shown unless explicitly recorded.
• UI/resource intent: represented by a view, label, message or route.
• Synthesis: combined interpretation of multiple supplied notes.
• Unresolved: competing evidence or missing implementation prevents a conclusion.

For example:

> Source observation: the inspected movement state-machine definition has no outgoing transitions from Rejected or Cancelled.
> Test expectation: selected tests permit editing in NotSubmitted, Submitted, NotificationReceived, InAssessment and `Unlocked.
> Not established: whether all controllers, handlers and database paths enforce the same restrictions.

This would be more auditable than placing all claims in the same declarative voice.

Evidence and citation correction

The current draft refers to “observed”, “cited”, “test-derived” and “one implementation” without identifying the relevant evidence unit. That is acceptable for a narrative synthesis only if the document makes clear that the claim is aggregated from the supplied notes. For major claims, add the available evidence reference or source-area description in prose, for example:

> “The supplied assessment tests describe…”

> “A separate movement state-machine description shows…”

> “The supplied SQL-procedure analysis reports…”

> “The view-level evidence indicates…”

Where no precise source identifier is available, the document should say so rather than imply precise traceability. The evidence metadata contains identifiers, but those identifiers should only be used where their association with the claim is known; they should not be guessed from nearby material.

Internal consistency corrections

The draft should reconcile or explicitly preserve several distinctions:

1. Assessment versus notification status. Do not treat Submitted, AwaitingPayment, NotificationReceived and parent or substate representations as interchangeable.
2. Movement outcome versus movement status. Accepted, Received, PartiallyRejected, Rejected and Completed may be represented by different flags, records or display mappings.
3. Notification completion versus financial-guarantee completion. The word “completed” is used for different aggregates and should always be qualified.
4. Receipt records versus receipt display precedence. A mapper selecting rejection data over receipt data does not prove that the underlying receipt was deleted.
5. Financial-guarantee decision versus guarantee status. Approval, release and supersession may update separate fields and records.
6. Internal and external operations. Different validation requirements may be intentional policy, implementation divergence or incomplete evidence; parity should not be assumed.
7. Database schema history versus current schema. Migration statements describe changes over time and should not be presented as one final schema unless the migration order and final state are established.
8. Source presence versus behavioural coverage. A file appearing in one supplied range corrects an omission claim but does not prove that its callers, registrations or downstream consumers were reviewed.

Prioritisation

The draft should foreground the matters most likely to affect interpretation of business behaviour:

• the 30-day versus 60-day shipment rule;
• three- versus four-working-day rules;
• internal-EU customs-office requirements;
• assessment parent-state and substate persistence;
• receipt, rejection and partial-rejection coexistence;
• financial-guarantee transition and decision-record atomicity;
• hidden-identifier and ownership revalidation;
• transaction boundaries across database, files, audits and events;
• migration data-loss and rerun risks;
• report cache freshness and join-dependent omissions.

Lower-impact source-quality observations—misspellings, stale comments, minor label inconsistencies and isolated regex concerns—should be retained only where they affect binding, routing, validation, security or interpretation. Otherwise they can be grouped under a short “secondary implementation observations” paragraph.

Unresolved questions requiring targeted evidence

The following questions remain open and should be stated explicitly:

• Which projects and components are deployed together, and which are separate applications or historical versions?
• What is the authoritative notification and assessment state model, including parent states, substates and persisted values?
• Which operation is authoritative for the 30-day or 60-day prenotification limit?
• Are working days based on UTC, local authority time, date-only values or timestamps, and which holiday calendar is used?
• Are movement numbers protected by a database constraint or concurrency-safe allocation mechanism?
• Can receipt, rejection, partial rejection and completion records coexist, and which record is authoritative?
• Are external and internal receipt and completion paths intentionally different?
• What prevents duplicate completion, submission, receipt or rejection?
• Are financial-guarantee state changes, decision records and audit records atomic?
• Are posted identifiers, selected facilities, selected movements, charges, statuses and temporary-state values reloaded and checked against authoritative records?
• What is the exact ownership and sharing permission matrix for every read, mutation, deletion and download?
• What data is copied when notifications are duplicated, and what is intentionally excluded?
• What does deletion remove, is it recoverable, and how are files, audit records and reporting caches treated?
• Which report joins and date-range conventions are authoritative?
• How and when are reporting caches refreshed, and can consumers observe partial refreshes?
• What upload limits, content-signature checks, malware outcomes, quarantine, retention and access controls apply?
• What are the production registrations for event dispatch, scanning, email, document generation and authorization?
• Which exceptions are logged, translated to user responses, retried or suppressed?
• What migration runner, transaction policy, backup process and post-migration reconciliation are used?
• Which tests were actually executed, with what build and deployment configuration?

Recommended final correction

The draft should be revised into a behaviour-led document with a short global evidence statement, then focused sections for account administration, ownership and copying, payments and refunds, archive and deletion, and maintenance and health. Within each section, separate observed source behaviour, test expectations, UI intent and unresolved production behaviour. Keep the strongest contradictions prominent, reduce repeated generic caveats, and move low-level implementation observations into clearly labelled risk paragraphs.

The draft is therefore a useful and cautious working synthesis, but it should not be presented as a verified specification, complete system inventory, security assessment, or production behaviour record.