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

Business Rules

Business Rules

The application supports international waste-shipment notifications for external applicants, notification owners, shared users, internal users, competent-authority staff, administrators, and shipment or movement operators. The exact division of responsibility between these actors is not fully established. Internal users may be associated with a competent authority. External access is described as depending on notification ownership or sharing, while some import-notification paths deny access to non-internal users. The complete permission matrix and the point at which each rule is enforced are unresolved.

Notification creation and submission

A notification contains a notification number, notification type, competent authority, parties, facilities, shipments, waste and recovery information, transport routes, customs offices, financial guarantees, documents, comments, charges, and lifecycle dates. The evidence does not establish which fields are mandatory for every notification type or whether all fields are persisted in every workflow.

Creation can involve selecting a competent authority and notification type, generating or entering a notification number, and creating related assessment and financial-guarantee records. Notification creation is reported to raise a notification-created event. The event’s persistence, delivery, consumers and failure handling are not established.

Notification numbers are normalised in some paths by trimming or removing ordinary spaces and converting to uppercase. A reported format accepts GB followed by four and six digits, with optional spacing in some views. One validation expression is unanchored, so a matching substring may be accepted rather than the whole input. Other whitespace characters and the complete authority-specific numbering rules are unknown.

Submission requires notification progress to be complete in the tested assessment path. Successful submission changes the assessment from NotSubmitted to Submitted and raises status-change and submission events. Duplicate submission is rejected in the cited tests. Another state-machine configuration shows NotificationReceived accepting Submit and moving to AwaitingPayment, with AwaitingPayment represented as a substate of Submitted. Consequently, descriptions of this transition as moving to Submitted may describe the parent state rather than the concrete destination. The authoritative status representation is unresolved.

The user interface presents disclaimer, terms and conditions, payment, financial-guarantee, signing and document-upload steps. These views indicate intended workflow sequencing but do not prove that every step is mandatory or that displayed success means the corresponding database and file operations completed.

Assessment lifecycle and editability

Assessment statuses represented in the evidence include NotSubmitted, Submitted, NotificationReceived, InAssessment, ReadyToTransmit, Transmitted, DecisionRequiredBy, Consented, ConsentWithdrawn, Objected, Withdrawn, Reassessment, Unlocked, ConsentedUnlock, UnderProhibition, InDetermination and FileClosed. These values demonstrate representable states and selected transitions, not a complete lifecycle.

Test-derived transitions include:

• receipt from Submitted, recording a received date;
• commencement from NotificationReceived, requiring a payment-received date and a non-empty officer name;
• progression through assessment, transmission, acknowledgement and decision-related states;
• unlocking from selected transmitted or decision-related states;
• resubmission from ConsentedUnlock or Unlocked;
• reassessment following resubmission;
• consent withdrawal with a date and reason;
• closure from selected consent, objection and withdrawal states;
• entry into prohibition from a listed set of non-prohibition states.

Editing is permitted in NotSubmitted, Submitted, NotificationReceived, InAssessment and Unlocked in the cited tests. Editing is rejected in ReadyToTransmit, Transmitted, DecisionRequiredBy and UnderProhibition. Editability for Consented, Withdrawn, Objected, FileClosed, Reassessment and ConsentedUnlock is not consistently established. Some views describe notifications as read-only after assessment, but the exact enforcement condition is unknown.

Prohibition tests cover a broad list of non-prohibition states. A test described as allowing prohibition from “any state” excludes UnderProhibition itself and does not establish behaviour for every enum value. Lifting prohibition appears to restore a previous status, but selection of that previous status and handling of missing history are unresolved.

Consent and dates

Consent processing accepts a notification identifier, validity start and end dates, conditions and a consent date. The operation is invoked and then persisted when successful. The evidence does not establish complete authorization, date ordering, overlap handling, downstream effects or whether consent alone permits movement creation.

Date rules are distributed across views, validators, domain methods and handlers. Reported rules include:

• received dates cannot be in the future;
• assessment and decision dates may be required to follow earlier lifecycle dates;
• movement dates must fall within the consent period;
• movement dates cannot be in the past;
• completion dates cannot precede receipt dates on the internal completion path;
• recovery dates cannot precede receipt dates or be in the future;
• selected decision dates cannot precede acknowledgement or completion dates;
• shipment periods are bounded by notification and pre-consent status.

The prenotification-to-shipment rule is contradictory. Several executable paths reportedly permit an actual shipment date up to 60 days after prenotification, while resource text says 30 days or 30 calendar days. Other views describe a minimum of three working days and one consent-expiry view refers to three or four working days. The effective maximum, minimum, calendar basis and working-day calculation cannot be resolved from the supplied evidence.

Date handling also differs between UTC dates, local dates, DateTime, DateTimeOffset and date-only comparisons. Time components, daylight-saving changes, and boundary behaviour may therefore differ by path. The working-day implementation and holiday source are not fully supplied.

Movements and shipment processing

Movement states include New, Captured, Submitted, Received, Completed, Rejected, Cancelled and PartiallyRejected. A reported state machine permits creation or capture to lead to submission, receipt, rejection, cancellation or partial rejection; submission and receipt can lead to later rejection, cancellation, partial rejection or completion. Rejected and cancelled appear terminal in the inspected configuration, while partially rejected movements can proceed to completion. The complete state graph and whether database procedures apply the same rules are unknown.

Movement creation or capture may require:

• a valid movement date;
• a consented notification;
• an approved financial guarantee;
• available shipment quantity;
• available movement capacity;
• permitted active loads;
• a valid consent period;
• a valid or unused movement number;
• required packaging and quantity information.

Movement numbers are generated by selecting the smallest unused positive number in some paths. No complete concurrency or database uniqueness rule is shown. One path applies a maximum-movement check while the number generator does not, although the factory may normally prevent the discrepancy.

External and internal receipt paths differ. External receipt requires a non-default file identifier, a date and a quantity. Internal receipt requires a valid date and quantity but does not require a file identifier; it rejects dates later than the current UTC date. External completion requires a completion date and file identifier. Internal completion also rejects future dates and dates earlier than the receipt date. Equivalent checks for both paths are not established.

A movement may contain receipt, rejection, partial-rejection and completion data. One mapping gives partial-rejection data precedence over receipt data when both are present. Other evidence reports that rejection or partial rejection clears the receipt when the prior status is Received, while a separate review found no receipt-clearing logic in the inspected receive methods. This is an unresolved contradiction. Because partial rejection can later lead to completion, the requirement for a receipt at completion is also unclear. Repeated completion may create a duplicate receipt unless another invariant prevents it.

Partial rejection requires a rejected quantity less than the actual quantity in the cited domain path. Equality is rejected even though some wording refers only to exceeding the actual quantity. A reason is required, but one implementation rejects only null or empty text and therefore may accept whitespace-only reasons. Full rejection does not consistently show the same quantity comparison.

Cancellation supports selecting submitted or otherwise cancellable movements. The cited interface limits manually added movements to 20, rejects duplicate shipment numbers, restricts shipment numbers to a positive range, and checks movement status. Selection and confirmation state may be carried through TempData. The evidence does not establish whether posted movements are reloaded, remain associated with the route notification, or are protected against stale or concurrent operations.

Quantities, units and waste

Quantities may be expressed in tonnes, kilograms, litres and cubic metres. Compatible weight and volume conversions are represented, but the complete conversion and precision rules are not established. Tests and mappings suggest precision limits such as four decimal places for tonnes and cubic metres and one decimal place for kilograms and litres, although test names and related descriptions conflict.

Movement and notification quantities are compared against intended, consented, received, completed, rejected and remaining quantities. Remaining capacity may become negative when usage exceeds permitted capacity; whether this is a valid over-capacity result or an error is unknown. Unit normalisation and treatment of incompatible units are not consistent across all evidence.

Waste processing supports Basel, OECD, EWC, Y, H, HP, UN and national or customs codes, together with not-applicable, not-listed, custom-code and chemical-composition states. Observed rules include:

• applicable waste codes must be selected unless a permitted not-applicable or not-listed state is chosen;
• a code and an incompatible not-applicable flag should not be supplied together;
• operation codes must be present where required;
• recovery and disposal operation codes must not be mixed;
• operation-code availability depends on notification type and, in some paths, interim status;
• duplicate code identifiers may be rejected;
• waste descriptions, technology details and additional information have configured length limits;
• chemical-composition minimum values must not exceed maximum values in the relevant validation paths;
• percentage-like values may be constrained between zero and 100.

The complete validation matrix, code ownership, identifier existence checks and server-side enforcement are unknown. Some mappings give persisted codes precedence over not-applicable or custom representations, while another custom-code path gives the custom value precedence. These differences may conceal contradictory submitted representations.

Facilities, producers, carriers and routes

Facilities, producers, importers, exporters and carriers contain business, address and contact information. Limited companies may require a registration number; Other business types may require a description; other business types may use Not applicable for registration information. The complete requiredness and immutability of these fields are not established.

A facility collection is expected to contain at least one facility and exactly one actual treatment site in one validator. Other evidence describes at least one actual site without confirming the exact-one rule. Selecting a site may clear the flag from other facilities. Removing the actual site is restricted in some paths, but removal of the sole site and behaviour for multiple marked sites are unresolved.

Transport routes contain state of export, state of import, transit states, customs offices and entry or exit points. Transit ordinals are expected to be unique and consecutive, with removal causing later positions to be decremented. One validator checks that the set contains positions from 1 through the number of states but does not require the submitted list itself to be sorted. Entry and exit points and competent authorities must generally correspond to the selected country. Same-country export and import combinations may be allowed only for configured UK-authority combinations, but the configured values are not supplied.

Payments and financial guarantees

Payment transactions represent credits and refunds or debits. Cheque payments require a receipt number; other methods may use NA. Payment completion is reported when the balance is fully paid, and the payment-received date may be set from the relevant transaction. Deleting or refunding transactions can clear or recalculate that date. The calculation of charges, refunds, additional charges and remaining balances is not consistent across all handlers.

Financial guarantees support creation, application receipt and completion, approval, refusal, release and supersession. Approval may require a completed application, decision date, reference, active-load values, blanket-bond selection, cover amount and calculation-continuation data. Refusal requires a completion state, a decision date and a nonblank reason. Release is shown for approved guarantees; a direct transition from ApplicationComplete to Released is not evidenced.

Approval with a matching reference may supersede an existing approved guarantee; a different reference may release it. Multiple approved guarantees may pass one path and fail another through SingleOrDefault, so the cardinality invariant is unresolved. A monetary upper limit appears in messages but related enforcement is commented out in one path.

Business-rule failure paths

Failure outcomes vary by layer. Invalid values may return model-state errors, validation results, false, empty objects, null, HttpNotFound, HTTP 400/403/404/500 responses, or exceptions including ArgumentException, InvalidOperationException, SecurityException, FormatException and NullReferenceException. Missing records are sometimes treated as normal absence and sometimes passed to Single, SingleAsync, First or direct property access.

Persistence may occur through Entity Framework, repositories, raw SQL or stored procedures. Some operations use explicit transactions; others perform multiple saves, store files before database changes, or dispatch events after persistence. Atomicity between database records, files, audits, events, email and external services is not established. Retry, compensation, idempotency, concurrency handling, monitoring and recovery are also unresolved.

Content quality review

Advisory; not approval. Review status: advisory.

Overall assessment

The draft is broadly relevant to business-rules.md and is unusually careful about uncertainty. It correctly distinguishes many observed behaviours from inferred requirements, repeatedly notes that UI text and enum values do not prove enforcement, and preserves important contradictions rather than resolving them by assumption.

However, it is substantially broader than a business-rules document. Large portions describe architecture, source layout, exception types, persistence technologies, deployment, logging, document generation, and operational risks rather than business rules. It also contains many detailed assertions without claim-level citations or a clear indication of which supplied note supports each statement. Because the evidence is itself a large set of partial summaries, tests, second opinions, and conflicting coverage statements, the draft should be treated as a cautious consolidation, not as a verified rule catalogue.

Relevance and structure

The strongest business-rule material concerns:

• notification submission and assessment status transitions;
• editability and prohibition;
• consent, dates, movements and shipment outcomes;
• quantity, unit and waste-code validation;
• facilities, routes, customs offices and actual-treatment-site rules;
• payment, financial guarantees and charges;
• actor access distinctions where they affect business permissions.

The sections on persistence, event delivery, HTTP response types, deployment, monitoring, migration tooling, raw SQL, exception classes and framework versions are relevant as evidence limitations or enforcement concerns, but they dominate the document. They would be better reduced to a short “enforcement and evidence limitations” section or moved to a technical-risk document.

The draft also repeats the same qualification in many places: that views do not prove persistence, that repository checks may exist elsewhere, that tests do not prove production behaviour, and that transactions and authorization are unresolved. These are important points, but repetition makes the actual rules harder to identify.

Claims that are well supported, subject to scope

Several claims are appropriately bounded and appear consistent with the supplied evidence:

• Submission is tested as requiring notification progress to be complete, changing NotSubmitted to Submitted, raising events, and rejecting duplicate submission.
• The distinction between the parent Submitted state and the concrete AwaitingPayment substate is correctly preserved as unresolved.
• The draft correctly treats the assessment status list as representable values and selected tested transitions, not a complete lifecycle.
• The stated editability results are appropriately limited to the cited tests.
• The “any state” prohibition claim is correctly qualified because UnderProhibition is excluded and not every enum value is demonstrated.
• The 30-day versus 60-day prenotification conflict is correctly identified as unresolved.
• The external/internal receipt and completion differences are accurately presented as path-specific rather than generalized.
• The partial-rejection strict inequality is correctly distinguished from wording that only says “exceeding”.
• The whitespace-only rejection-reason issue is appropriately described as an implementation gap or uncertainty, not as a confirmed business defect.
• The facility actual-treatment-site rule is properly presented as validator-specific.
• The route ordinal rule is carefully distinguished from list ordering.
• The guarantee cardinality conflict involving multiple approved guarantees and SingleOrDefault is appropriately retained as unresolved.
• The final paragraph correctly avoids claiming verified completeness.

These sections should remain, but each material rule should ideally identify its evidence basis, for example “unit test,” “domain method,” “validator,” “stored procedure,” “view text,” or “mapping.” The supplied note identifiers could be used internally for traceability even if they are not exposed in the final publication.

Unsupported or over-strong wording

Some wording is still stronger than the evidence described in the supplied material.

“Successful submission changes the assessment from NotSubmitted to Submitted” is supported for the tested assessment path, but should not be read as the universal submission rule. The draft generally qualifies this, but the sentence could say “the cited test path observes…” rather than presenting it as a general rule.

“Movement numbers are generated by selecting the smallest unused positive number in some paths” is supported as an implementation observation, but it is not necessarily a business rule. It should be labelled as an allocation strategy, with a separate statement that uniqueness and concurrent allocation remain unproven.

“Payment completion is reported when the balance is fully paid” needs to retain the qualification that one path uses a particular calculation or status condition. The evidence describes differing payment handlers and stored assessment dates, so this should not be presented as a single application-wide rule.

“Partial rejection requires a reason” should be qualified as applying to the cited domain path. The draft does this nearby, but the rule should not appear to cover all rejection interfaces or persistence procedures.

“External and internal receipt paths differ” is supported, but the draft should distinguish implementation differences from intentionally different policy. It does this later; the distinction should be made at first mention.

“Rejected and cancelled appear terminal in the inspected configuration” is appropriately cautious, but “appear terminal” may still be read as a domain conclusion. Prefer “the inspected state-machine configuration defines no outgoing transitions for…” and then state that other code may differ.

The draft states that “approval with a matching reference may supersede an existing approved guarantee; a different reference may release it.” This should remain explicitly scoped to the observed path, because the evidence also contains conflicting guarantee descriptions and does not establish whether the references must belong to distinct guarantees.

The draft describes “a reported format accepts GB followed by four and six digits”. This is reasonable, but it should explicitly say that this is one expression or path, not the complete authority-specific notification-number format. The following sentences partly address that issue.

Internal clarity and possible contradictions

The draft preserves contradictions but sometimes places both sides far apart, which makes the result difficult to interpret. The most important conflicts should be consolidated in a clearly labelled “Unresolved rule conflicts” subsection:

1. Prenotification timing: executable paths reportedly allow 60 days, while resource text says 30 days; other views refer to three or four working days.
2. Assessment destination: some descriptions use parent Submitted, while the state machine uses concrete AwaitingPayment.
3. Receipt clearing: rejection and partial rejection reportedly clear receipt data, while other inspected receive methods do not.
4. Completion after partial rejection: partial rejection can proceed to completion, but receipt requirements are unclear.
5. Quantity precision: tests, mappings and descriptions disagree on the precision for tonnes, cubic metres, kilograms and litres.
6. Custom versus persisted waste-code precedence: different mappings appear to give different representations precedence.
7. Financial-guarantee cardinality: one path allows or observes multiple approved guarantees while another assumes one.
8. Customs-office requirements: some test names suggest None, while executable assertions require EntryAndExit.
9. Actual treatment site cardinality: evidence includes both “at least one” and “exactly one.”
10. Payment-received date: handlers recalculate it differently and may rely on a stored assessment date rather than the latest transaction.

The draft currently mentions most of these, but not all are elevated equally. Their importance to a business-rules document warrants a compact consolidated treatment.

Missing business behaviours

Although the draft is very long, important behaviours remain absent or insufficiently explicit.

Actor and permission behaviour

The opening acknowledges that the permission matrix is unresolved, but it does not present even a provisional operation-by-actor summary. The evidence appears to support at least these distinctions:

• external applicant or owner;
• shared external user;
• internal user;
• competent-authority user;
• administrator;
• possible read-only user;
• movement or shipment operator, whose distinct status is uncertain.

The draft should state which operations are evidenced for each actor and which are merely inferred. In particular, the following remain open:

• whether an owner can transfer ownership;
• whether a shared user can edit, submit, delete or only view;
• whether internal users can act across competent authorities;
• whether administrators bypass ordinary authority restrictions;
• whether inactive or pending users can access existing records;
• whether movement operators are distinct from notification users;
• whether permission checks are resource-specific or only activity-specific.

Notification lifecycle

The draft lists many states and transitions but does not identify the missing lifecycle semantics clearly enough. It should explicitly call out the absence of rules for:

• notification creation versus draft creation;
• notification-number uniqueness and assignment authority;
• whether submission is idempotent;
• whether submission is reversible;
• whether consent changes notification status;
• whether withdrawal, objection, prohibition and reassessment are mutually exclusive;
• what timestamps are set on each transition;
• whether an assessment can be reopened after closure;
• whether FileClosed is terminal;
• whether archive and deletion are distinct operations;
• whether notification copying includes all business-relevant data.

Cross-entity invariants

The draft identifies many individual validations but does not consistently group the cross-entity invariants that are central to the business:

• movements must belong to the selected notification;
• shipment numbers must belong to the route or notification;
• waste-code identifiers must belong to the permitted code type and active catalogue;
• facilities and producers must belong to the notification;
• routes, countries, authorities and entry/exit points must agree;
• guarantees must belong to the notification and have valid status;
• payment transactions must belong to the assessment or notification;
• uploaded files must be associated with the intended movement or notification;
• posted charges, statuses, dates and identifiers must be reconstructed or reconciled from server state.

These are not merely technical security checks; they determine whether the business rules can be violated through inconsistent records.

Date and calendar semantics

The draft identifies inconsistent date types, but it should more directly state the missing normative behaviours:

• whether dates are calendar dates or instants;
• the authoritative time zone;
• whether “today” is UTC, UK local time, or authority local time;
• whether date ranges are inclusive;
• whether “30 days” means calendar days or working days;
• the holiday calendar by competent authority;
• treatment of daylight-saving changes;
• whether a date at exactly the boundary is valid;
• whether dates can be cleared;
• how partial dates are handled;
• whether date histories preserve time and offset information.

Quantities and units

The draft identifies conversions and precision conflicts, but it does not provide a clear unresolved matrix for:

• allowed units by notification and movement type;
• compatible versus incompatible dimensions;
• conversion factors;
• rounding mode;
• precision at input, domain, database and report layers;
• negative, zero, null and overflow values;
• whether remaining capacity may be negative;
• whether tolerance is 50%/150% and whether boundaries are inclusive;
• whether quantities are compared before or after conversion.

Payments and guarantees

The payment section should distinguish more clearly between:

• charge calculation;
• payment capture;
• balance calculation;
• payment-received status;
• refund eligibility;
• transaction deletion;
• financial-guarantee approval;
• guarantee refusal;
• release;
• supersession.

The evidence does not establish their relationship. In particular, it remains unresolved whether a fully paid assessment is sufficient to commence assessment, whether an approved guarantee is required to create a movement, whether release affects movement eligibility, and whether refunds alter payment completion.

Corrections recommended

A revised version should:

1. Add an opening scope statement saying that this is an evidence-bounded rule inventory, not a normative specification.
2. Separate content into: - observed or tested business behaviours; - inferred or UI-indicated rules; - contradictions; - missing behaviours; - enforcement and evidence limitations.
3. Label each rule by evidence type: test, domain code, validator, handler, database procedure, mapping, view, resource text, or second-opinion summary.
4. Replace broad verbs such as “requires,” “permits,” and “changes” with “the cited test/path requires,” “the inspected implementation permits,” or “the view indicates” where universal enforcement is not established.
5. Move most framework, deployment, HTTP error, logging and architecture detail out of the business-rules body.
6. Add a provisional actor/operation matrix, clearly marked as incomplete.
7. Consolidate the major contradictions into one section rather than repeating them across multiple domains.
8. Add explicit cross-entity invariants and unresolved date, quantity and payment semantics.
9. Reduce repeated generic caveats and use one concise evidence-limit section.
10. Attach traceability to the supplied evidence. Without that, readers cannot distinguish a claim supported by an executable test from one derived from a resource string or review summary.

Evidence gaps and questions requiring resolution

The most important unresolved questions are:

• Which status model is authoritative: the flat enum, the hierarchical state machine, database status IDs, or a combination?
• Is AwaitingPayment the persisted concrete destination after submission, with Submitted only its parent state?
• Is the prenotification maximum 30 or 60 days, and are the minimum and maximum measured in calendar or working days?
• Which working-day calendar and time zone apply for each competent authority?
• Are shipment, movement, receipt, rejection and completion records mutually exclusive or allowed to coexist?
• Can partial rejection be completed without a receipt, and what data is required at completion?
• Is there exactly one approved financial guarantee per notification?
• Are movement numbers unique per notification under database constraints and concurrency?
• Are all quantity comparisons performed in normalized units?
• What are the authoritative precision and rounding rules?
• Are hidden identifiers, statuses, dates, charges and selections reloaded and checked server-side?
• Which actor may perform each read, edit, submit, approve, release, delete, archive, share and override operation?
• Are consent, payment, guarantee approval and movement creation linked by enforced business rules?
• Which operations are atomic across database records, files, audits and events?
• What is the authoritative behaviour when a record is missing, duplicated or stale?
• Are the cited tests executed and passing, or are they only source assertions and characterization scenarios?
• Which source snapshot, migration sequence and deployment configuration represent the current system?

The draft is therefore a useful cautious consolidation, but it should not be treated as a definitive or complete business-rules specification.