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

Acceptance Criteria

These criteria describe the behaviour evidenced for the current system. They are bounded by the supplied source observations, test expectations and configuration descriptions. They are not evidence that the complete production system satisfies every criterion, and no test execution is claimed here.

Notification submission and assessment

• A new assessment is represented as NotSubmitted.
• Submission is permitted only when the associated notification is considered complete by the available progress-validation path.
• A successful submission changes the assessment to Submitted or, in one state-machine configuration, to the concrete substate AwaitingPayment beneath Submitted.
• Submission raises status-change and notification-submitted events in the observed domain path.
• A duplicate submission is rejected in the tested behaviour.
• Receipt is permitted from Submitted and records a received date.
• Commencement requires NotificationReceived, a payment-received date, and a non-empty officer name. A null or empty officer name is rejected.
• Editing is permitted in at least NotSubmitted, Submitted, NotificationReceived, InAssessment, and Unlocked.
• Editing is rejected in at least ReadyToTransmit, Transmitted, DecisionRequiredBy, and UnderProhibition.
• The complete editability rules for Consented, Withdrawn, Objected, FileClosed, Reassessment, and ConsentedUnlock are not established.
• Consent accepts a notification identifier, validity start and end dates, conditions, and a consent date, then invokes the assessment operation and requests persistence.
• Withdrawal, unlocking, reassessment, resubmission, prohibition, rejection of changes, acknowledgement, transmission and closure are represented, but their complete transition guards and downstream effects are not established.

The evidence contains a state-description ambiguity: one configuration shows NotificationReceived transitioning to AwaitingPayment, while other descriptions refer to the resulting state as Submitted. The concrete persisted and user-visible status representation is unresolved.

Notification data and validation

• Notification creation obtains or generates a competent-authority-specific notification number and raises a notification-created event in the observed domain path.
• A notification can contain parties, facilities, producers, importers, exporters, carriers, routes, customs offices, waste information, shipments, assessments, documents, comments, charges, financial guarantees and lifecycle dates.
• A notification number is normalised by uppercasing and removing ordinary spaces in the described validation path.
• The expected GB format is described as GB followed by four digits and six digits, although one implementation uses an unanchored regular expression and may accept a matching substring within a larger value.
• A notification type and competent authority are required in the observed creation and import-notification paths.
• A reason for export is limited to 70 characters in the domain evidence.
• Comments have a reported maximum of 500 characters, although some views expose only a hint and do not visibly render a corresponding maxlength.
• Hidden identifiers, status values, dates, charges and selected records are submitted by several views. The evidence does not establish whether all such values are reloaded and checked against authoritative server state.

Movement creation and numbering

• Movement creation or capture records a notification reference, movement number, movement date, creator, creation time and prenotification information.
• A captured movement can be represented as Captured; another creation path initializes a movement as New.
• A movement associated with a notification must satisfy the notification’s consent and financial-guarantee conditions in the observed factory path.
• Movement creation checks, in selected paths, movement-date validity, notification consent, consent-period validity, shipment or movement limits, active loads, remaining quantity, an approved financial guarantee and movement-number generation.
• A movement number is generated by selecting an available positive number, with evidence describing gap-filling and starting at 1 when no movement exists.
• Duplicate movement or shipment numbers are rejected in the tested or controller-level paths.
• The available evidence does not establish database-level uniqueness or concurrency-safe number allocation. Concurrent requests could therefore have different behaviour unless an unseen constraint or transaction prevents duplication.
• Movement creation can reject a disabled-prenotification flag when a prenotification date is supplied.
• Shipment details require a positive actual quantity and at least one packaging item in the directly described constructor.
• Carrier order values must be positive in the described movement-carrier model.
• The maximum movement and shipment limits are not consistently represented across all number-generation and creation paths.

Movement receipt, rejection and completion

• Movement states include Captured, New, Submitted, Received, PartiallyRejected, Completed, Rejected and Cancelled.
• Observed transitions include submission, receipt, rejection, cancellation, partial rejection and completion. Rejected and Cancelled appear terminal in one state-machine definition, but this is not established system-wide.
• External receipt requires a non-default file identifier, a date and a quantity.
• Internal receipt requires a valid date and quantity and rejects a date later than the current UTC date.
• External completion requires a non-default completion date and file identifier.
• Internal completion rejects future completion dates and dates earlier than the recorded receipt date.
• Completion requires a receipt or equivalent waste-received evidence in the directly described internal path.
• Partial rejection requires a rejected quantity strictly less than the actual quantity in the cited domain rule. Equality is therefore rejected, although some text describes only quantities greater than actual quantity as invalid.
• Rejection and partial rejection require a reason that is non-null and non-empty in the visible checks. Whitespace-only reasons may pass where IsNullOrEmpty is used.
• Rejection and partial rejection create corresponding rejection records and may create audit records.
• Completion creates a completed-receipt record and may store an associated certificate file.
• Repeated completion is guarded in at least one handler when a completed receipt already exists. Other evidence describes a completion path without the same visible guard, so duplicate-completion behaviour is not uniform.
• Receipt, rejection and partial-rejection information may be combined for display. One mapping gives partial-rejection data precedence over receipt data when both are present.
• Several analyses state that rejection, partial rejection or cancellation clears receipt data when the prior movement was received. Other supplied analysis reports that the inspected receive methods do not show receipt clearing. The effective receipt-clearing rule is unresolved.
• A partial-rejection movement can transition to completion in one state-machine definition. It is unresolved whether completion then requires an existing receipt or another invariant prevents a missing-receipt state.
• Movement date changes are restricted in the observed path to submitted movements, must satisfy a movement-date validator and must not exceed ten working days after the original date. The lower date boundary is not established.
• Date checks use a mixture of UTC dates, local DateTime values and date-only comparisons. Time-zone and boundary semantics are unresolved.

Financial guarantees

• Financial-guarantee operations include creation, approval, refusal, release and, in some state descriptions, supersession.
• Represented statuses include AwaitingApplication, ApplicationReceived, ApplicationComplete, Approved, Refused, Released and Superseded.
• Approval requires a completed application in the observed state-machine and validation paths.
• Approval requires a non-empty reference number.
• Refusal requires a completed application and a non-empty, non-whitespace refusal reason.
• Release is evidenced for approved guarantees; release from completed, received or refused guarantees is rejected in the cited tests.
• Approval can supersede an existing approved guarantee when the reference number matches. A different reference can release the existing guarantee.
• The system records decision dates, release dates, active-load allowances, blanket-bond selection, cover amounts and calculation-continuation values in selected paths.
• Decision dates must not be earlier than the relevant preceding date in the observed validation.
• The decision-required date is calculated using a working-day calculator for a 20-working-day period after completion in one financial-guarantee description. The holiday calendar and exact boundary behaviour are not supplied.
• Approval, refusal and release raise or record status-change information in selected domain paths, but the relationship between events, persisted history and transaction boundaries is unknown.
• The complete eligibility rules, authority restrictions, concurrency rules, uniqueness constraints and self-replacement behaviour are unresolved.
• A monetary upper bound of 9,999,999.99 appears in related validation messages, but the corresponding checks are commented out in one area. The upper bound must therefore not be treated as active system-wide enforcement.

Uploads, scanning and documents

• Upload workflows accept multipart files for prenotifications, receipt and recovery data, supporting documents, certificates and shipment movement documents.
• Missing or zero-length files are rejected by the visible upload models.
• Some individual upload models apply an allowed-file-type validator. Equivalent enforcement on bulk uploads is not established.
• Bulk validation can report file-level and content-level errors and prevents draft saving when the configured content validation fails.
• Bulk receipt and recovery processing validates notification numbers, shipment numbers, quantities, units, dates, duplicate records and required receipt or recovery fields in selected paths.
• A reported maximum of 50 rows applies to a receipt/recovery content-validation path. Other upload row and size limits are unknown.
• A virus-scanning API exposes an authenticated POST scan operation and an anonymous GET health-style operation in the observed implementation. The health-style operation returns "ok" in that implementation.
• Scanner outcomes include unknown, clean, virus and error in the broader scanning abstraction. Temporary-file scanning reports clean when the file remains and virus when it has been removed, but the evidence does not establish whether removal necessarily means malware detection.
• Scanner timeouts, quarantine, file cleanup, maximum upload sizes, scanner failures, certificate validation and retention are unresolved.
• Documents are generated from ordered blocks and OpenXML templates. Blocks can merge main-document content and generate annexes.
• Annex numbering and main-document versus annex placement depend on block order, ordinal positions, carrier counts, facility data, customs offices and content length.
• Missing or duplicated template fields, missing or multiple actual-treatment facilities, empty movement collections and unsupported authorities can raise exceptions or produce incomplete output.
• Generated files may be stored before later movement or audit persistence succeeds. The evidence does not establish coordinated file/database rollback or orphan-file cleanup.
• PDF generation is optional in some paths. When unavailable, a DOCX result may be returned instead. The deployed generator and output contract are unknown.

Search, reporting and exports

• Search supports notification numbers, party names, producers, exporters, importers, facilities, competent authorities, countries, local areas, dates, statuses, notification type, trade direction, operation codes and waste-code conditions.
• Export-notification search visibly filters by the current user’s competent authority in at least one path and may search notification number or importer name.
• One inspected path does not visibly search exporter name despite broader descriptions suggesting exporter search. The effective search predicate is unresolved.
• Report inputs generally require a date range with a start date no later than the end date.
• Reports include import statistics, producer, shipment, finance, export-notification, import-notification, compliance, FOI and EA data reports.
• Report outputs may be XLSX files generated through ClosedXML or another spreadsheet component.
• Some reports use inclusive BETWEEN date predicates, while other audit queries use start-inclusive and end-exclusive ranges. Boundary behaviour is therefore not uniform.
• Some reporting data is described as a copy of live data one day behind, and cache tables are used for selected reports. Refresh timing, completeness and failure recovery are not established.
• Reports can filter or hide columns based on selected report types or competent authority. The exact workbook schema and formula-value handling are unknown.
• Search and reporting failures may return validation errors, not-found responses, generic errors or exceptions depending on the path. A consistent error contract is not established.

Users, sharing and access

• Actors represented in the evidence include external applicants and notification owners, producers, exporters, importers, carriers, shared users, internal users, competent-authority users and administrators.
• Internal users may be scoped to a competent authority. External users may be scoped by notification ownership or sharing.
• Import-notification access is denied to non-internal users in the cited implementation.
• Shared-user flows validate an email address, reject self-sharing, resolve the target user, require an external user, reject duplicates and use temporary state during confirmation.
• Sharing has a reported maximum of five users in one validation path. Whether the limit includes existing users, duplicates or the new user is unresolved.
• Ownership transfer, shared-user removal, deactivation, reactivation, archiving and deletion are represented, but the complete authorization, audit and recoverability rules are not established.
• Request and controller authorization attributes identify read, edit, create, delete, owner and administrative permissions. Their registration, evaluation order, resource checks and coverage are incomplete.
• A permissive authorization default is reported for request types without cached authorization attributes. The completeness of that cache and any higher-level deny rules are unknown.
• Hidden user, notification, movement, status and entity identifiers are client-controlled. The evidence does not establish that all mutation handlers verify membership, ownership, current state and authority scope.
• Some actions are visible as anonymous or health-style endpoints. The full endpoint inventory and whether global filters compensate are unresolved.

Failure paths and evidence limitations

• Missing records may return null, an empty object, an empty collection, false, Guid.Empty, 404, 403, a security exception or an unhandled exception, depending on the path.
• Single, SingleAsync, SingleOrDefault, First and FirstOrDefault assumptions can fail when records are missing, duplicated or empty.
• Malformed dates, numbers, GUIDs, enum values, JSON, posted identifiers and temporary state can produce parsing or null-reference exceptions where local handling is not shown.
• Some authorization-related calls catch broad Exception and return null, potentially treating infrastructure or programming failures as missing data.
• Some repository, email, scanner, document and event failures are suppressed, converted to Boolean results or mapped to generic responses; the complete logging and retry behaviour is unknown.
• Multiple-save operations, file storage, audit writes, event dispatch and database changes may fail independently unless an unseen transaction or unit-of-work coordinates them.
• Maintenance mode can return HTTP 503 in the tested filter path, but its effect on all MVC, API, health and administrative routes is unknown.
• Anti-forgery, API, virus and custom error filters are present in selected evidence, but their registration, order, response content and coverage are incomplete.
• The evidence contains unresolved contradictions, including 30-day versus 60-day shipment limits, receipt clearing after rejection, external and internal movement-path parity, concrete notification submission states, financial-guarantee bounds, customs-office expectations, and inconsistent source-coverage inventories.
• Test names, fixtures, mocked dependencies and assertions sometimes conflict or verify only calls and redirects. No test execution result, build result, deployment result or production observation was supplied.

Content quality review

Advisory; not approval. Review status: advisory.

Advisory review

Overall assessment

The draft is highly relevant to the supplied material and is unusually careful about uncertainty. It repeatedly distinguishes source observations, tests, configuration, inferred behaviour and missing runtime evidence. It also preserves the major contradictions in the evidence rather than silently resolving them. That is a strong fit with the stated purpose of reviewing a current system from incomplete evidence.

However, it is not yet well-shaped as an acceptance-criteria document. It is primarily a broad evidence inventory and risk register. Many bullets describe source structures, possible behaviour, implementation concerns, security gaps and operational unknowns rather than criteria that could be accepted or rejected through a defined test. It also combines evidence from many apparently different projects, source ranges and possibly application areas without a clear evidence boundary for each claim.

The document should not be treated as a complete acceptance specification or as evidence that the described production system satisfies the criteria.

Relevance to the requested purpose

The opening qualification is appropriate:

> “They are not evidence that the complete production system satisfies every criterion, and no test execution is claimed here.”

That limitation is consistent with the evidence. The draft also correctly retains uncertainty around:

• the NotificationReceived to AwaitingPayment versus Submitted representation;
• the 30-day versus 60-day shipment rule;
• receipt clearing after rejection;
• external versus internal movement paths;
• financial-guarantee monetary bounds;
• customs-office expectations;
• reporting date boundaries;
• file/database transaction coordination;
• authorization coverage; and
• incomplete or conflicting source inventories.

Those are material and relevant issues.

The main relevance problem is scope. The draft includes extensive material on:

• deployment topology;
• TLS and configuration;
• operational monitoring;
• error conventions;
• raw HTML and possible injection;
• report cache freshness;
• migration tooling;
• endpoint inventories;
• database constraints;
• document templates;
• scanner behaviour; and
• test-quality limitations.

These topics may be important for a system review, but they do not naturally belong in acceptance criteria unless the requested purpose is explicitly “characterization and assurance criteria for the whole application.” For a file named acceptance-criteria.md, the document should focus on externally observable behaviours and the conditions under which those behaviours can be accepted.

Form and testability problems

Most bullets are not acceptance criteria in a testable form. For example:

> “A notification can contain parties, facilities, producers, importers, exporters, carriers, routes, customs offices, waste information, shipments, assessments, documents, comments, charges, financial guarantees and lifecycle dates.”

This describes a data model, not an acceptance criterion. It does not identify an actor, precondition, action, expected result, persistence expectation or evidence boundary.

Similarly:

> “Documents are generated from ordered blocks and OpenXML templates.”

This is an implementation observation. It does not state what output must be produced, for which input, or what failure behaviour is acceptable.

And:

> “Search supports notification numbers, party names, producers, exporters, importers, facilities, competent authorities, countries, local areas, dates, statuses, notification type, trade direction, operation codes and waste-code conditions.”

This aggregates several source descriptions into a broad capability claim, although the evidence explicitly says that individual search paths differ and that exporter searching is not visible in at least one inspected path.

A better acceptance criterion would identify the specific path and outcome, for example:

> Given an export-notification search request in the inspected search path, when the current internal user searches by notification number or importer name, then results are restricted by that user’s competent authority and the supplied search terms are applied. Exporter-name matching remains unresolved for this path.

The existing draft should either:

1. convert each supported behaviour into a testable criterion; or
2. be renamed and reframed as a “bounded behavioural evidence review” or “characterization criteria and evidence gaps” document.

Evidence-strength issues

The draft is generally cautious, but some claims remain stronger than the evidence supports.

Notification submission

The statement:

> “A new assessment is represented as NotSubmitted.”

is supported by test evidence and notification-created observations, but it should be limited to the tested construction or creation path. The evidence also contains several creation paths and test fixtures. A safer formulation is:

> “In the supplied assessment tests and notification-created path, a newly created assessment is initialized or observed as NotSubmitted; initialization is not established for every creation or import path.”

The statement that successful submission changes the assessment to Submitted is supported by tests, but the concrete destination ambiguity means the criterion should distinguish the abstract parent state from the persisted concrete state.

Notification number validation

The draft correctly notes the unanchored expression. It should also distinguish the normalization path from the creation-number generator. The evidence describes both authority-specific sequence generation and validation/formatting, but does not establish that every generated number passes through the same normalization and validation method.

Comment lengths

The statement that comments have a maximum of 500 characters is supported in domain mappings and some validation evidence, but the draft appropriately notes that some views expose only a hint. It should avoid presenting the limit as a universal acceptance rule unless the specific server-side path is identified.

Movement numbering

The draft says:

> “A movement number is generated by selecting an available positive number, with evidence describing gap-filling and starting at 1 when no movement exists.”

This is reasonable for the described generator, but it should not be written as an acceptance requirement for production unless the generator’s persistence and concurrency behaviour are established. The later caveat about database uniqueness and concurrent allocation is important and should be attached directly to the criterion rather than left in a later bullet.

Partial rejection

The draft properly identifies the conflict between the strict < actual quantity rule and wording that only refers to quantities greater than actual. It should make clear that this is a contradiction in the evidence, not a confirmed product defect. The phrase:

> “Equality is therefore rejected”

should be scoped to the cited domain rule or test, for example:

> “In the cited domain rule, equality is rejected; other movement paths and user-facing wording are not consistent enough to establish a system-wide rule.”

Scanning

The scanner section needs stronger qualification. The evidence is inconsistent: some notes describe an observed authenticated POST and anonymous health-style GET implementation, while another explicitly treats the same behaviour as a candidate scenario rather than confirmed runtime behaviour. The draft says:

> “A virus-scanning API exposes an authenticated POST scan operation and an anonymous GET health-style operation in the observed implementation.”

That should be amended to state that this is source-level behaviour in one inspected implementation and that deployment exposure and route activation are unresolved.

The statement that a file being removed means “virus” is appropriately cautious. It should not be converted into an acceptance criterion without confirming the scanner contract.

Search claims

The broad search list is too strong. The supplied evidence includes general descriptions suggesting exporter search, but one inspected predicate visibly searches notification number or importer name and not exporter name. The draft notes this contradiction, but the broad positive list still reads as a system-wide capability statement. It should separate:

• supported search fields evidenced in a named path;
• fields mentioned only in summaries; and
• fields whose effective predicate is unresolved.

Authorization

The draft correctly distinguishes attributes and visible checks from effective enforcement. It should avoid treating the following as acceptance criteria:

> “Request and controller authorization attributes identify read, edit, create, delete, owner and administrative permissions.”

This establishes declarations only. A criterion should require a specific request, actor, resource and expected denial or allowance. The permissive default should be described as a source-level risk or verification target, not as a system behaviour unless the dispatch path and registration are established.

Reports and caches

The claims about reports being one day behind and using cache tables are supported as descriptions or warnings, but not as a universal reporting contract. The draft should identify which reports use copied data and which use live or mixed sources. The existing wording correctly says refresh timing and completeness are unknown; that uncertainty should be reflected in the criterion itself.

Missing behaviours

The draft identifies many unknowns, but several important behaviours should be made explicit as missing acceptance areas rather than scattered caveats.

Idempotency and replay

The document mentions duplicate submission and repeated completion, but does not provide a coherent cross-workflow criterion for:

• repeated notification submission;
• repeated movement receipt;
• repeated completion;
• repeated rejection;
• repeated cancellation;
• repeated file upload;
• repeated shared-user addition;
• repeated archive requests; and
• repeated migration or cache refresh execution.

These need separate criteria because the evidence suggests different outcomes in different paths.

Authorization matrix

The draft lists actors and permissions but does not present a usable matrix for:

• external owner;
• external shared user;
• unrelated external user;
• internal user in the same competent authority;
• internal user in another competent authority;
• administrator;
• read-only user; and
• unauthenticated caller.

At minimum, each destructive or sensitive operation needs an explicit unresolved question about these actors.

Client/server consistency

The draft notes hidden identifiers, readonly, client-side flags, route values and dynamic forms, but does not consolidate the required behaviour:

• whether server-side state is reloaded;
• whether posted notification and movement IDs are cross-checked;
• whether posted status and charge values are ignored or validated;
• whether client-only restrictions are repeated server-side;
• whether stale forms are rejected; and
• whether concurrent updates use row-version or other conflict handling.

These are central acceptance concerns for this system.

Error contract

The failure-path section is valuable, but it is not yet expressed as acceptance behaviour. The evidence indicates that missing records may produce nulls, empty objects, 404s, security exceptions or unhandled exceptions. The document should explicitly state that no consistent error contract is established and identify the affected operation classes. It should not imply that all such outcomes are acceptable.

Persistence and transaction boundaries

The draft repeatedly says that transactions are unknown, but it does not distinguish:

• explicitly transactional database paths;
• multiple-save paths with no visible transaction;
• file-before-database paths;
• event-after-save paths;
• email-after-save paths; and
• operations delegated to repositories whose transaction behaviour is unknown.

This distinction is important because “transaction not visible” is an evidence gap, whereas a visible multi-step operation without coordination is a concrete implementation concern.

Date and time policy

The draft notes UTC, local DateTime, date-only and working-day differences, but a useful acceptance document should identify the unresolved policy questions directly:

• Are dates calendar dates or timestamps?
• Which timezone is authoritative?
• Are boundaries inclusive?
• Does “20 working days” exclude the start date?
• Which holiday calendar applies?
• Are future dates evaluated against UTC or local time?
• Are equal start and end dates allowed?

Documents

The document records many document-generation failure conditions, but it does not distinguish required output contracts from source assumptions. Missing acceptance areas include:

• exact output type when PDF generation is unavailable;
• document naming and collision handling;
• template version;
• annex numbering;
• treatment of missing merge fields;
• repeated generation;
• authorization for download;
• retention and replacement of files; and
• whether generated files are legally or operationally authoritative.

Contradictions and internal presentation

The draft preserves contradictions, which is appropriate, but it sometimes states both sides as positive criteria before explaining the contradiction later. This can make the document appear internally inconsistent.

Examples include:

• Submitted versus AwaitingPayment;
• 30 versus 60 days;
• receipt clearing versus no receipt clearing;
• completion with versus without an existing receipt;
• one versus multiple approved guarantees;
• active versus commented-out monetary bounds;
• external versus internal completion ordering;
• exporter search supported versus absent;
• customs-office expectations;
• report inclusive versus exclusive ranges.

A better pattern is to use explicit labels such as:

• Observed in path A
• Observed in path B
• Contradiction
• Not established
• Required clarification

This would distinguish a genuine contradiction from mere absence of evidence.

The draft also repeats the evidence limitations many times. Repetition is understandable given the source, but it makes the criteria harder to audit. One global evidence note followed by concise per-section confidence labels would be clearer.

Traceability and provenance gaps

The supplied evidence includes note IDs and section IDs, but the draft provides no claim-level traceability. Because the draft contains hundreds of assertions, a reviewer cannot determine which source observation supports each bullet or whether a bullet is based on a direct source extract, a test summary, a second opinion or a characterization proposal.

This is a significant evidence gap, not necessarily a defect in the system. The document should add compact source references for material claims, especially for:

• state transitions;
• date boundaries;
• monetary bounds;
• upload limits;
• scanner routes;
• authorization outcomes;
• report freshness;
• database constraints;
• transaction behaviour; and
• migration concerns.

Where precise source locations are unavailable, the document should identify the evidence note or section and state that the reference is to a summarized observation rather than a directly inspected implementation.

Specific corrections

1. Retitle or restructure the document.
   Either rename it as a bounded characterization/evidence review, or convert it into actual acceptance criteria with actors, preconditions, actions, expected outcomes and evidence status.

2. Separate requirements from observations.
   Use distinct sections such as: - Observed behaviour; - Test-derived expectations; - Source-level risks; - Absent evidence; - Contradictions; - Acceptance criteria requiring confirmation.

3. Scope every positive claim to a path.
   Replace “the system” with “the cited factory path,” “the inspected controller,” “the supplied test,” “one state-machine configuration,” or “the described validation path” where appropriate.

4. Avoid presenting model structure as behaviour.
   Replace phrases such as “can contain” or “operations include” with “the supplied model declares fields for” unless execution or persistence is evidenced.

5. Make unresolved issues non-criteria.
   Bullets such as “complete transition guards are not established” are useful review findings but should not be mixed with acceptance assertions.

6. Correct scanner wording.
   Mark the authenticated POST and anonymous GET as source-level observations from one implementation, with deployment and route activation unresolved.

7. Correct broad search wording.
   Separate the broad search vocabulary from the inspected predicates and explicitly state that exporter-name searching is unresolved in the inspected path.

8. Qualify event and persistence claims.
   “Raises an event” should mean the event is raised in the cited method or test, not that it is delivered, persisted or consumed.

9. Qualify limits.
   The 50-row upload limit, 500-character comments, 70-character reason, 50-user sharing limit and monetary limits should each identify the exact validation path and whether the limit is active, merely displayed, commented out or inferred.

10. Add explicit negative and replay criteria.
    These are material to the supplied evidence and are not adequately consolidated.

11. Add a claim traceability convention.
    Each significant criterion should refer to the relevant supplied evidence note or section, while preserving that the reference is not independent runtime verification.

12. Reduce duplication.
    The repeated evidence disclaimers can be consolidated into one scope statement and a short confidence note per section.

Unresolved questions requiring clarification

The following questions remain open from the evidence and should be retained rather than answered by inference:

• Is AwaitingPayment a concrete persisted substate of Submitted, or do different application paths persist different status values?
• Is the prenotification-to-shipment boundary 30 days or 60 days, and is it calendar-day or working-day based?
• Does rejection, partial rejection or cancellation clear receipt data in the effective application path?
• Can a partially rejected movement complete without a receipt, and what invariant prevents that?
• Are external and internal receipt and completion operations intentionally subject to different guards?
• Are movement numbers unique at the database level and allocated safely under concurrency?
• What is the authoritative actor and permission matrix for each mutation?
• Are client-posted identifiers, statuses, dates, charges, selections and hidden fields reloaded and checked?
• Which reports use live data, cached data or delayed projections?
• What are the inclusive/exclusive date semantics for each report?
• Is the scanner GET endpoint intentionally anonymous, and is it a health check or a scan route?
• Are file storage, database writes, audit records, event publication and email coordinated transactionally or by compensation?
• What is the deployed document output contract when PDF generation is unavailable?
• Which migration files and schema state are authoritative?
• Which reported source ranges belong to the deployed application, and which describe tests, utilities or separate applications?
• Which cited tests actually execute, compile and pass?

Overall, the draft is a strong uncertainty-preserving evidence consolidation, but it should not be presented as acceptance criteria without substantial restructuring and claim-level scoping.