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

05 — Business Rules and Decisions

Purpose and scope

The system supports regulatory administration of import notifications, their assessments, financial guarantees, and associated movements. At this level, the business purpose is to record assessment outcomes, determine or represent whether a notification may proceed, manage financial-guarantee decisions, and control the receipt and completion of movements. The evidence shows request handlers, domain methods, repositories, controllers, and view models, but not a complete end-to-end workflow. Consequently, this chapter documents observed implementation behaviour and marks broader interpretations as inferred or unresolved. E0010 E0013 E0436

The principal actors visible in the evidence are:

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

• an internal user or competent-authority user performing assessment and guarantee decisions;
• users submitting or receiving movement information;
• system handlers and domain objects applying date, quantity, identifier, and state checks;
• repositories and persistence services storing assessment, guarantee, movement, and audit data.

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

Authorization metadata and filters are present in request classes and controllers. Their presence establishes intended authorization boundaries, but not effective enforcement for every operation. E0001 E0017 E0436

Assessment and financial-guarantee decisions

Observed decision operations

The assessment area represents consent using a notification identifier, a consent date range, conditions, and a decision date. The observed consent handler constructs a DateRange from the submitted “from” and “to” values, invokes the consent operation, saves changes, and returns success. This indicates that consent changes both a period and related conditions rather than merely recording a Boolean decision. E0010

Financial guarantees have separate operations for creation, approval, refusal, and release. Creation persists an ImportFinancialGuarantee. Approval includes a reference; refusal includes a reason; release, in the observed handler call, carries no additional decision detail. These operations are represented as distinct commands and handlers, but the supplied handler evidence does not establish the full workflow ordering or all eligibility checks. E0010 E0232

The financial-guarantee view models provide more concrete date and field validation. Received dates must be present and must not be later than the current system time. Completion dates must be present, must not be future dates, and must not precede the received date. Approval, refusal, and release dates must be present, must not precede completion, and must not be future dates. E0516

Approval also visibly checks that active loads are permitted and positive, that a reference number is nonblank, that a blanket-bond choice is supplied, and that the “calculation continued” value is present where required. Monetary precision is checked. The source does not currently enforce the upper bounds of 9,999,999.99: those checks are commented out, even though corresponding resource messages remain. E0516

The domain tests provide additional evidence of decision behaviour. Approval is unavailable before completion; refusal requires completion, a sufficiently late decision date, and a reason; release is allowed for approved guarantees but not for completed, received, or refused guarantees. Approval of a guarantee with the same reference can supersede the existing guarantee, while a different reference can release it. These are test assertions, not proof that the tests currently pass or cover all production paths. E0299

State and data changes

A consent operation stores a date range, conditions, and a decision date. Financial-guarantee operations change guarantee status and retain decision information such as reference, refusal reason, decision, active-load allowance, and decision date. Status values include AwaitingApplication, ApplicationReceived, ApplicationComplete, Approved, Refused, Released, and Superseded; the declaration establishes the vocabulary, while the tests provide evidence for only selected transitions. E0010 E0376 E0299

Assessment and guarantee status changes are audited with source status, destination status, and the acting user context. Financial-guarantee audit records use DateTimeOffset.UtcNow. This supports an audit trail for observed status changes, but does not establish that every decision path emits an audit record or that audit persistence is atomic with the decision. E0010

flowchart LR
    A[Assessment consent] --> B[Consent date range and conditions]
    C[Guarantee creation] --> D[Approval / refusal / release]
    D --> E[Guarantee status and decision data]
    D -. audit coverage not fully established .-> F[Audit record]

Unresolved decision rules

Open question for Harten: The inspected artifacts are the consent and financial-guarantee handlers, view models, domain tests, and repository summaries cited in E0010, E0516, E0299, and E0262. They do not establish complete decision authority, whether all decisions require an internal or competent-authority role, whether approval must follow consent, or whether handler operations are transactionally atomic. Evidence that would resolve this includes the command authorization pipeline, handler implementations for all decision commands, domain transition methods, repository transaction boundaries, and integration tests covering invalid ordering and concurrent decisions.

Movement receipt and completion guards

Receipt

The movement domain distinguishes externally received movements from internally received movements. External receipt requires a non-default file identifier, a non-default date, and a quantity before the receive trigger is fired. The resulting receipt is created by OnReceived(...). Internal receipt validates date and quantity, rejects dates later than SystemTime.UtcNow.Date, and creates a receipt without a file identifier. E0013

These rules indicate that an external receipt is associated with an uploaded or otherwise supplied file, whereas internal receipt does not require that identifier. This is an inference from the different method signatures and guards, not a confirmed statement of operational policy. The evidence does not establish whether the file must belong to the same notification or movement, or whether external and internal handlers apply equivalent authorization checks. E0013 E0262

Completion

External completion validates a non-default completion date and file identifier before firing its state-machine trigger. The supplied code does not show the same “completion cannot precede receipt” check on the external path. Internal completion does check that completion does not precede the receipt date and rejects future completion dates. Therefore, the ordering rule is directly evidenced only for internal completion. E0013

The movement state machine permits, among other transitions, New or Submitted to Received, Received to Completed, and PartiallyRejected to Completed. Rejected and Cancelled have no outgoing configurations in the inspected state-machine definition and therefore appear terminal within that definition. Other persistence or application code could still affect the effective lifecycle. E0013

Rejection and partial rejection can clear a receipt when the prior state is Received. This creates an important edge case because PartiallyRejected can later transition to completion, while the supplied evidence does not prove that a receipt is restored or guaranteed to exist. E0013

stateDiagram-v2
    [*] --> New
    New --> Submitted
    New --> Received
    Submitted --> Received
    Received --> Completed
    Received --> PartiallyRejected
    PartiallyRejected --> Completed
    Received --> Rejected
    Received --> Cancelled
    Rejected -. further transitions not shown .-> Rejected
    Cancelled -. further transitions not shown .-> Cancelled

Movement rule requirements

The following requirements describe observed behaviour, not target design:

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

• BR-MOV-001 — External receipt inputs: Before external receipt is accepted, the movement operation shall reject a default file identifier, a default date, or an invalid quantity. E0013
• BR-MOV-002 — Internal receipt date: Internal receipt shall reject a date later than the current UTC date. E0013
• BR-MOV-003 — Internal completion ordering: Internal completion shall reject a completion date earlier than the recorded receipt date. E0013
• BR-MOV-004 — Internal completion future date: Internal completion shall reject a completion date later than the current system date/time as implemented by the domain method. E0013
• BR-MOV-005 — State transition: A movement shall only complete through a state transition permitted by the observed state machine; Received and PartiallyRejected are observed predecessors of completion. E0013
• BR-MOV-006 — Rejection data: Rejection and partial-rejection operations shall create their corresponding rejection entities and may clear the receipt when the movement was previously Received. E0013

Open question for Harten: The inspected artifact is Movement.cs and its state-machine methods in E0013. It does not establish whether external completion enforces receipt ordering, whether all paths use the domain methods, or how missing receipts are handled after partial rejection. Evidence needed includes external completion handlers, repository update paths, persistence constraints, and tests for completion-before-receipt and completion-after-partial-rejection.

Authorization and ownership rules

Authorization is declared in several layers. Request contracts carry permissions such as assessment-decision, movement-edit, movement-creation, and notification-read permissions. Controllers also use [Authorize], activity-specific authorization attributes, read-only filters, and ownership filters. One observed exception is WasteGenerationProcessController.Index(Guid id), which is marked [AllowAnonymous] despite controller-level authorization. The semantics of its read-only filter are not supplied. E0001 E0017 E0436

Repository evidence shows inconsistent visible authorization: some notification and movement retrieval methods call EnsureAccessAsync, while other identifier-based reads, deletes, comments, movement deletion, and receipt-update paths do not visibly do so. This is a source-level gap, not proof of an exploitable authorization failure, because callers or stored procedures may enforce access elsewhere. E0262 E0414

Open question for Harten: The inspected artifacts are the request contracts, controllers, repositories, and authorization service summaries in E0001, E0017, E0262, and E0414. Complete endpoint-to-handler authorization tests, authorization middleware configuration, and implementations of EnsureAccessAsync, ownership filters, and stored procedures would establish whether posted identifiers are independently checked for ownership, notification scope, and current state.

Characterisation scenarios

These are candidate scenarios derived from observed behaviour and require confirmation by executable tests:

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

CS-MOV-001 — Reject future internal receipt

• Given a movement eligible for internal receipt
• When the receipt date is later than the current UTC date
• Then the internal receipt operation rejects the request and does not create the receipt.

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

CS-MOV-002 — Reject completion before receipt internally

• Given a movement with a recorded receipt date
• When internal completion is submitted with an earlier date
• Then completion is rejected and the movement remains incomplete.

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

CS-FG-001 — Refusal requires a reason

• Given a completed financial guarantee
• When refusal is submitted with a null reason
• Then the operation raises the null-argument failure observed by the domain tests; an empty or whitespace-only reason raises the separate argument failure. E0299

CS-FG-002 — Approval requires a reference

• Given a financial guarantee eligible for approval
• When approval is submitted with a blank reference number
• Then approval validation fails and no approved decision is recorded. E0516