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

Architecture and relationships

The supplied evidence describes an application family for managing international waste-shipment notifications under European and UK rules. Its represented domain includes export and import notifications, assessments, movements, shipments, waste and recovery information, competent authorities, organisations, facilities, carriers, transport routes, customs offices, financial guarantees, documents, comments, users, sharing, reporting, authentication, authorization, maintenance, email, document generation, and virus scanning.

The evidence supports a source-level view rather than a proven production architecture. Components include ASP.NET MVC and Web API, Razor views, MVC areas and routes, request handlers, mediator-style contracts, domain and core models, repositories, Entity Framework, SQL and stored procedures, document-generation code, email and scanning services, middleware, configuration, migrations, console utilities, and tests. Projects and dependencies target both .NET Framework 4.5.2 and 4.8 in different evidence sets; MVC versions are also reported as both 5.2.3 and 5.2.9. A single application-wide target framework, deployment boundary, runtime process, or hosting topology cannot therefore be confirmed.

Logical application areas

The visible application surface is divided into functional areas or components that may not all share one deployed runtime:

• Notification and assessment: creation, editing, submission, resubmission, receipt, commencement, assessment, consent, objections, withdrawal, prohibition, file closure, archive references, key dates, charges, and progress.
• Import-notification workflows: importer, producer, facility, shipment, waste, transport route, state-of-export, state-of-import, transit state, journey points, customs offices, draft completion, and address-book operations.
• Export-movement workflows: movement capture, submission, receipt, completion, rejection, partial rejection, cancellation, document upload, certificate handling, audit, and download.
• Financial guarantees and payments: guarantee application, completion, approval, refusal, release, supersession, payments, refunds, additional charges, and related reporting.
• Administration and reporting: internal-user approval and status management, organisation and area assignment, advanced search, archive and deletion workflows, comments, audit screens, FOI and operational reports, Excel generation, and cache-backed reporting.
• Supporting services: document generation and PDF conversion, email template rendering and sending, Companies House lookup, virus scanning, API mediation, maintenance mode, logging, configuration, and database or migration utilities.

These areas are evidenced through source files, declarations, views, tests, configuration, or summaries with different levels of confidence. Their end-to-end integration is not established. For example, an API startup description includes OWIN, IdentityServer middleware, bearer validation, claims transformation, Autofac, and Web API dispatch, while other evidence describes MVC workflows and a reusable core library. It is unresolved whether these are one application, separate applications in the same family, alternative versions, or different deployment boundaries.

Actors and trust boundaries

Supported or represented actors include:

• external applicants and notification owners;
• exporters, importers, producers, carriers, and other shared users;
• internal users associated with competent authorities or local areas;
• administrators and internal-user approvers;
• movement or shipment operators, although it is not established whether they are a distinct population;
• system, deployment, migration, and operational users; and
• technical callers, including MVC controllers, Web API clients, mediator handlers, background or maintenance processes, and external service callers.

The evidence indicates intended access distinctions. Internal users may be checked against competent-authority scope. External users may be checked against notification ownership or sharing for export notifications. The cited import-notification authorization path denies access to non-internal users. Request-level permission attributes, read-only attributes, ownership filters, sharing checks, activity authorization, and authorization services appear in different layers.

These observations do not establish a complete actor-to-permission matrix or universal enforcement. Authorization may occur in controllers, filters, middleware, mediator decorators, handlers, repositories, domain services, or database access, and the evidence does not show all of those paths together. The effective authentication mechanism, role and claim model, administrator boundary, tenant or competent-authority isolation, permission-registration completeness, and failure responses remain unresolved.

Entry points and request processing

MVC controllers, Web API operations, mediator-style request handlers, repositories, stored procedures, and direct database operations are all present in the supplied material. MVC areas and routes include examples such as:

• Notification-Application/{id}/{controller}/{action}/{entityId};
• Import-Notification/{id}/{controller}/{action}/{entityId};
• Notification-Movements/{notificationId}/{controller}/{action};
• Export-Movement/{Id}/{controller}/{action}/{entityId};
• Admin-Import-Assessment/{id}/{controller}/{action};
• Admin-Export-Assessment/{id}/{controller}/{action};
• Address-Book/{controller}/{action}/{id}; and
• reporting and administrative routes with varying defaults.

Route registration, area constraints, ambient route-value behavior, and public reachability are not fully supplied. Identifier names vary between Id, id, NotificationId, ImportNotificationId, MovementId, and entityId. Several redirects omit identifiers and may rely on ambient route values, session state, TempData, or custom routing. The resulting URL generation, binding, context preservation, and risk of incorrect or empty identifiers cannot be determined from the supplied material.

The request layer uses IRequest<T> and IRequestHandler<TRequest, TResult> patterns in several namespaces, including Prsd.Core.Mediator and EA.Prsd.Core.Mediator. Requests return bool, Guid, nullable identifiers, Unit, byte arrays, collections, and structured data objects. These signatures establish contract shapes but do not establish what the results mean, whether handlers are registered, or whether they persist data successfully.

A central API mediator is described as serializing requests with an assembly-qualified type name and forwarding them to an API endpoint. The supplied evidence does not establish the complete allow-list, transport contract, type resolution policy, or the set of requests reachable through that path. One anonymous smoke-test or JSON endpoint and an anonymous scanner health-style operation are represented, but their intended deployment boundaries are unknown.

Data and persistence relationships

The domain and persistence evidence represents relationships among:

• notifications and assessments;
• assessments and notification dates or status changes;
• notifications and exporters, importers, producers, facilities, carriers, shipments, routes, waste, comments, guarantees, annexes, and shared users;
• movements and movement details, receipts, rejections, partial rejections, operation receipts, files, audits, and shipment history;
• transport routes and states of export, import, and transit, including countries, competent authorities, entry points, exit points, and customs offices;
• users, organisations, local areas, competent authorities, roles, claims, address books, and shared-user history; and
• reporting projections or caches for movements, producers, FOI data, finance, waste, consent, routes, and authority data.

Entity Framework mappings, raw SQL, stored procedures, explicit transactions, asynchronous saves, deferred saves, and repository methods are all evidenced. Some database structures use foreign keys, composite keys, row-version columns, generated identifiers, indexes, and required fields. These demonstrate intended relational structure, not necessarily the deployed schema or active enforcement. The final database state, migration order, foreign-key trust, uniqueness, cardinality, cascade behavior, and ORM configuration are not established.

Several relationships have unresolved cardinality or consistency. The evidence refers to exactly one actual treatment site in some paths, while other code uses Single, First, or FirstOrDefault without proving the underlying guarantee. Financial guarantees may allow multiple records, but some paths use SingleOrDefault for the approved guarantee. Notification-linked collection rows, recovery or disposal records, routes, assessments, annexes, customs offices, and operation receipts do not consistently show uniqueness constraints. Different mappings also use distinct import and general-notification schemas, so similarly named tables must not be assumed to represent one lifecycle or one relationship.

Domain lifecycle relationships

Assessment statuses and movement statuses form related but not fully reconciled state models.

Assessment values include NotSubmitted, Submitted, NotificationReceived, InAssessment, ReadyToTransmit, Transmitted, DecisionRequiredBy, Consented, ConsentWithdrawn, Objected, Withdrawn, Reassessment, UnderProhibition, FileClosed, AwaitingPayment, and AwaitingAssessment, among others. Tests describe submission after notification progress is complete, receipt from a submitted state, commencement after receipt and payment receipt, transmission, acknowledgement, consent withdrawal, unlocking, reassessment, resubmission, prohibition, and closure.

One state-machine description shows NotificationReceived accepting submission and moving concretely to AwaitingPayment, with AwaitingPayment beneath Submitted. Other descriptions use Submitted as the apparent destination. This may be a hierarchy abstraction, but the precise persisted and exposed state is unresolved.

Movement values include New, Captured, Submitted, Received, Completed, Rejected, Cancelled, and PartiallyRejected. Reported transitions include capture or creation to submission or receipt; submission to receipt, rejection, cancellation, or partial rejection; receipt to completion, rejection, cancellation, or partial rejection; and partial rejection to completion. Rejected and cancelled appear terminal in one state-machine definition, but other code may still affect those records.

Assessment and movement lifecycles are related through consent, payment, notification progress, financial guarantees, movement dates, receipt data, and quantity limits. The complete cross-entity transition graph, event ordering, status ownership, terminal-state enforcement, and atomicity between status records and related entities are not established.

Event and audit relationships

Notification creation, user changes, status changes, submission, interim-status updates, movement-date changes, financial-guarantee decisions, prohibition changes, and other domain actions raise event-shaped objects in the supplied source. Event payloads may contain notification IDs, movement IDs, old and new values, acting users, dates, or status information.

Persistence hooks reportedly assign IDs, process removed relationships and audits, save through Entity Framework, and dispatch events after persistence. Other paths use a null event dispatcher, a static or deferred dispatcher, or Task.Run(...).Wait() around dispatch. The relationship between domain events, audit records, database transactions, event handlers, external notifications, and deployed registrations is unresolved. An event existing in source does not establish publication, delivery, replay, retry, idempotency, or durable auditability.

Auditing is visible for selected assessment, guarantee, movement, shipment, deletion, comment, and status operations. Audit records may contain user, event type, screen, record ID, original and new values, shipment number, and timestamps. System-wide audit completeness, immutability, retention, access control, and atomicity with the business mutation are not established. Some source paths save the business entity and audit in separate operations, while other database procedures perform related operations in an explicit transaction.

Supporting relationships and integrations

The application references or represents integrations with:

• IdentityServer, OAuth, bearer tokens, claims transformation, ASP.NET Identity, and user-information clients;
• Companies House lookup through an API client and AJAX endpoint;
• email infrastructure, SMTP or pickup-directory delivery, Razor templates, dynamic templates, and event-driven messages;
• document generation using WordprocessingML/Open XML, Aspose.Words, PDF conversion, templates, merge fields, and annexes;
• virus-scanning implementations, nClam or remote scanning clients, temporary files, bearer tokens, and scanner APIs;
• SQL Server procedures, views, caches, sequences, reporting objects, and maintenance utilities; and
• migration or test-data tooling invoked through AliaSQL.exe, PowerShell, or related scripts.

These integrations are evidenced mainly through source structure, package references, configuration, or selected handlers. Production URLs, credentials, scopes, contracts, certificates, ownership, availability, retry behavior, timeout behavior, response validation, and deployment activation are unknown. In particular, a configured endpoint or client class does not prove that a corresponding external service is active or reachable.

The email subsystem can construct HTML and text messages, apply configured recipient rules, load embedded templates, and return a sender Boolean result. Some handlers ignore that result. The scanning subsystem represents Unknown, Clean, Virus, and Error, but local-file behavior may infer a virus from the absence of a temporary file, and the remote scanner contract is incomplete. Document generation assumes strict template shapes and may fail on missing or duplicate fields. These are supported relationships and failure considerations, not claims of production incidents.

Failure paths and boundaries

Failure behavior is heterogeneous across the visible components:

• MVC validation may redisplay the current view; some actions return the posted model, while others reload a fresh model and may lose entered values.
• Missing or duplicate data may return null, an empty object, false, Unit.Value, an HTTP 404, a model-state error, or an exception, depending on the path.
• Single, SingleAsync, and First assumptions can fail for absent, duplicate, or empty records.
• Malformed dates, GUIDs, decimals, enums, JSON, route values, TempData, or uploaded-file content may cause parsing or conversion exceptions.
• Broad exception catches may suppress authorization, database, configuration, or programming failures and return null, a generic error, or an apparently normal result.
• Some stored procedures roll back and rethrow, while other paths return false, suppress exceptions, or continue after an individual item fails.
• Multiple saves, file writes, event dispatch, audit creation, email, and external calls are not uniformly coordinated. Orphaned files, partial updates, stale temporary state, mismatched audit records, and partially refreshed caches are possible where no shared transaction or compensation is evidenced.
• Maintenance mode can produce HTTP 503 in the tested filter path, but its effect on MVC routes, health endpoints, static content, background work, and administrative bypasses is unresolved.
• API error responses may include exception details when includeErrorDetail is enabled. The effective environment configuration and disclosure controls are unknown.

Potential source-level risks include raw HTML output, client-controlled hidden identifiers and status values, client-side-only read-only or disabled controls, SQL-like text interpolation, permissive or anonymous endpoints, temporary-state collisions, synchronous blocking on asynchronous calls, broad exception suppression, and unanchored or inconsistent validation expressions. The evidence does not establish exploitability, reachability, production impact, or absence of compensating controls.

Evidence limits

The supplied notes contain conflicting source ranges, hashes, file inventories, test names, migration interpretations, and claims of complete or omitted coverage. Some files are reported as absent in fleet summaries while appearing in the supplied material; other files and migration scripts are unavailable or unreadable. Tests are described but no test execution results were supplied, and characterization scenarios must not be treated as executed tests. The evidence does not establish a single deployed architecture, complete request inventory, final schema, active configuration, runtime callers, or complete business process.

Accordingly, this section describes supported actors, logical components, relationships, triggers, and observable failure paths at the level evidenced. It does not claim that all components run together, that declared relationships are enforced, that tests passed, or that any proposed interpretation has been approved.

Content quality review

Advisory; not approval. Review status: advisory.

Overall assessment

The draft is broadly relevant to the subject matter and is unusually careful about uncertainty. It correctly distinguishes source-level evidence from proven runtime or production behaviour, preserves several important contradictions, and avoids treating declarations, tests, configuration, or resource text as proof of enforcement.

However, it does not yet fulfil the stated purpose of diagrams.md. It is principally a long narrative assessment. It contains no actual architecture, context, container, data-flow, deployment, lifecycle, trust-boundary, or relationship diagrams, and it does not provide a diagram legend or a consistent way to distinguish confirmed, inferred, and unresolved relationships. The main correction should therefore be structural: retain a shorter evidence-bounded narrative, but add explicit diagrams and clearly label their confidence.

Relevance and scope

The following parts are relevant and generally supported:

• identification of the application family and its waste-shipment domain;
• separation of MVC, Web API, mediator, domain, repository, Entity Framework, SQL, document, email, scanning, reporting, and migration concerns;
• recognition that the supplied material may describe multiple applications, projects, versions, or deployment boundaries;
• identification of external and internal user categories;
• description of notification, assessment, movement, guarantee, document, audit, and reporting relationships;
• preservation of uncertainty around route registration, schema state, dependency registration, runtime hosting, and external services;
• discussion of state-machine ambiguity and the difference between named statuses and proven transitions;
• distinction between event declarations and durable event publication;
• treatment of failure paths as possible source-level behaviour rather than confirmed incidents.

These are appropriate foundations for an architecture-and-relationships document.

Main purpose defect: no diagrams

The filename and purpose imply that the section should communicate architecture visually. The draft should include, at minimum:

1. System context diagram
   External applicants, internal authority users, administrators, identity services, Companies House, scanning, email, document conversion, databases, and reporting consumers.

2. Logical/container diagram
   MVC/Razor application, Web API, mediator layer, domain/core libraries, repositories, Entity Framework, SQL Server objects, document generation, scanning, email, reporting, and migration utilities.

3. Request-flow diagram
   Browser or API caller → route/controller/API operation → mediator/decorator/handler → domain/repository/context → database and external services.

4. Data relationship diagram
   Notifications, assessments, movements, shipments, facilities, parties, routes, waste, guarantees, documents, comments, users, audits, and reporting projections.

5. Assessment and movement lifecycle diagrams
   These should show only evidenced transitions, with uncertain or conflicting transitions explicitly marked.

6. Trust-boundary diagram
   External users, internal users, browser-controlled values, authentication middleware, application services, database, file store, and external integrations.

7. Failure/transaction boundary diagram
   Database saves, file writes, event dispatch, audits, email, scanning, and document generation, showing where atomicity is evidenced and where it is not.

The diagrams should not imply a single deployment topology. Where the evidence is ambiguous, use separate possible boundaries or dotted relationships rather than drawing all components as one confirmed system.

Claims that need tighter qualification

Some statements are well qualified, but a few should be narrowed further.

“Actors” and technical callers

The list of “system, deployment, migration, and operational users” and “background or maintenance processes” is plausible, but the supplied material more clearly establishes utilities, maintenance paths, console tools, and technical callers than actual human user populations or scheduled background workers.

Suggested correction:

> The evidence represents operational utilities, maintenance paths, console tools, and technical callers. It does not establish whether these are operated by distinct user populations, scheduled jobs, background workers, or deployment-only processes.

Similarly, “movement or shipment operators” should remain explicitly hypothetical because the evidence does not establish a distinct actor population.

“Logical application areas”

The functional areas are useful, but the headings may be read as confirmed system boundaries. The draft should label them as “logical groupings of observed functionality” rather than application modules or deployed components.

Suggested correction:

> The following are analytical groupings of observed functionality. They are not confirmed deployment containers, bounded contexts, or independently hosted services.

Anonymous endpoints

The scanner health endpoint and smoke-test/JSON endpoint have conflicting evidence strength across the notes. Some material describes them as observed implementations; other material describes them as candidate scenarios or test-derived observations.

Suggested correction:

> Some supplied evidence reports an anonymous health-style or smoke-test operation, including a response of "ok". This is evidence of a declaration or observed/tested path, not proof that the operation is publicly reachable in the deployed system.

Event dispatch

The draft says that persistence hooks “reportedly assign IDs, process removed relationships and audits, save through Entity Framework, and dispatch events after persistence.” This is reasonable but should make clear that the evidence is heterogeneous and may relate to different persistence implementations.

Suggested correction:

> In some supplied persistence descriptions, Entity Framework save processing assigns identifiers, handles removed relationships and audits, and dispatches events after persistence. Other paths use null, deferred, static, or synchronously blocked dispatch. It is not established that these mechanisms are part of one common save pipeline.

“The scanning subsystem represents…”

This is supported as a model or implementation representation, but the wording could be read as a unified subsystem. The evidence includes local-file scanning, nClam or remote scanning, API endpoints, and tests from potentially different components.

Suggested correction:

> Separate scanning-related components represent outcomes such as Unknown, Clean, Virus, and Error; their common interface, implementation selection, and deployment relationship are unresolved.

“SQL Server procedures, views, caches…”

The draft correctly says these are represented, but should avoid implying that all named objects belong to one final schema. The evidence specifically warns that import and general-notification schemas must not be merged without proof.

Suggested correction:

> SQL Server procedures, views, cache tables, sequences, and reporting objects appear across several evidence sets. Their final deployed schema, ownership, and relationship to one another are not established.

Contradictions that should be made more prominent

The draft records important contradictions, but some deserve a dedicated “Unresolved contradictions affecting the diagrams” subsection rather than being embedded in prose.

Assessment status destination

The distinction between Submitted and the concrete AwaitingPayment substate is important. A lifecycle diagram that shows only Submitted would be misleading. The diagram should show:

• NotificationReceived --Submit--> AwaitingPayment
• AwaitingPayment possibly nested under Submitted
• a note that some summaries describe the result as Submitted
• an explicit unresolved marker for persisted versus parent status.

Movement receipt clearing

The draft correctly identifies the contradiction between descriptions that rejection clears receipt data and evidence that receive methods do not visibly clear it. This should be shown as a conflict marker on the movement lifecycle diagram, not only described in prose.

30-day versus 60-day rule

The draft mentions the 30/60-day contradiction indirectly under failure and validation evidence, but this is one of the strongest recurring conflicts in the evidence. It should appear explicitly in the lifecycle/rules diagram:

> Prenotification-to-shipment limit: executable logic is reported as 60 days; user-facing text and some resources state 30 days; effective rule unresolved.

External versus internal movement paths

The draft identifies different receipt and completion requirements, but the architecture document should explicitly show these as separate branches. In particular:

• external receipt requires a file identifier;
• internal receipt does not visibly require one;
• internal completion checks future dates and ordering against receipt;
• equivalent external checks are not established.

Conflicting framework and MVC versions

The draft correctly states that a single target cannot be confirmed, but this should appear in the architecture diagram legend or evidence notes. Do not draw “.NET Framework 4.8” as the definitive platform for every component.

Unsupported or potentially over-broad relationship claims

The draft sometimes treats a broad domain summary as a relationship map. The following relationships need either direct evidence or an uncertainty marker:

• notifications to all listed child collections;
• assessments to all notification dates and status changes;
• movements to all receipts, rejections, audits, files, histories, and operation receipts;
• users to roles, claims, organisations, areas, authorities, and address books;
• reporting caches to all listed transactional entities;
• event objects to audit records, email, external notifications, or durable publication;
• API mediator requests to all handlers and reachable endpoints;
• migration utilities to production deployment.

A declaration, mapper, request, foreign key, or test fixture may suggest such a relationship, but it does not establish that the relationship is active, unique, enforced, or used in production. The diagrams should use labels such as:

• “declared relationship”;
• “source-observed call”;
• “test-described expectation”;
• “database relationship reported”;
• “runtime use unresolved”;
• “deployment boundary unresolved.”

Missing behaviours for an architecture document

Although the draft discusses many limitations, several relationship behaviours should be added explicitly because they affect architecture:

• Identity propagation: how browser identity, bearer tokens, claims, current-user context, and competent-authority scope move through MVC, API, mediator, repository, and database paths.
• Resource ownership: whether notification, movement, file, document, audit, and shared-user identifiers are revalidated against the current notification and user.
• Concurrency: movement-number generation, guarantee replacement, shared-user changes, temporary state, row versions, simultaneous submissions, and cache refresh.
• Idempotency: submission, completion, receipt, rejection, file upload, email, event dispatch, migration reruns, and document generation.
• Background processing: whether email, document conversion, scanning, cache refresh, and reporting are synchronous, queued, scheduled, or externally triggered.
• File lifecycle: upload, scan, temporary storage, permanent storage, document generation, download, replacement, deletion, retention, and orphan cleanup.
• Reporting freshness: source data, cache population, refresh trigger, stale-data warning, consistency during refresh, and failure recovery.
• Failure response mapping: domain exceptions, validation errors, authorization failures, API failures, database failures, and file failures to HTTP responses or views.
• Data classification and privacy: personal data, banking data, uploaded documents, audit records, logs, and analytics.

The draft mentions most of these as gaps, but it should connect them to the relationships being documented rather than leaving them as a general list.

Evidence and citation weakness

The supplied evidence contains many note and section identifiers, but the draft contains no evidence references. For an evidence-bounded architecture document, each diagram and major relationship should have a short prose evidence annotation. Atelier owns IDs and filenames, so the review need not prescribe a particular identifier format, but the document should distinguish evidence source types.

For example:

> Evidence basis: source declarations and mappings; runtime registration and deployed use unresolved.

> Evidence basis: test-described transition; no execution result supplied.

> Evidence basis: migration text; final schema and execution outcome unresolved.

This is preferable to presenting a large consolidated statement followed only by a general disclaimer at the end.

Excessive breadth and repetition

The draft is materially longer than necessary for diagrams.md. It repeats the same caveats about:

• source-level evidence;
• missing deployment topology;
• absent test execution results;
• authorization not being universal;
• configuration not proving active integrations;
• raw HTML and hidden fields being conditional risks;
• event declarations not proving publication;
• mappings not proving deployed schema.

Those caveats are valid, but repeated restatements reduce the usefulness of the architecture description. Consolidate them into:

1. a short confidence legend;
2. diagram-specific evidence notes;
3. a final limitations section.

The detailed security, migration, validation, and test-quality observations would be more suitable for dedicated review sections than for the main architecture-and-relationships narrative.

Specific corrections recommended

Revise the document so that it:

• begins with a short scope and confidence legend;
• states that the diagrams are analytical, not authoritative deployment diagrams;
• separates confirmed/observed relationships from inferred and unresolved ones;
• includes actual Markdown-compatible diagrams, such as Mermaid or carefully formatted text diagrams;
• separates the MVC application, Web API, core libraries, data-access components, utilities, and external services unless evidence proves they share a runtime;
• shows database schemas as distinct where the evidence distinguishes them;
• draws identity, authorization, file, event, and transaction boundaries explicitly;
• represents the assessment and movement states with conflict annotations;
• removes or relocates detailed source-risk catalogues that do not contribute to understanding architecture;
• adds a compact relationship table or prose legend explaining each line style;
• adds evidence notes beside each diagram rather than relying on one global disclaimer;
• preserves the 30/60-day, receipt-clearing, status-destination, framework-version, route, and scanner-boundary uncertainties prominently.

Unresolved questions

The following questions remain material before the diagrams can be treated as a reliable architecture description:

1. Which source projects belong to the current system, and which represent older versions, test utilities, separate applications, or related libraries?
2. Are MVC and Web API hosted together, separately, or only represented in different evidence sets?
3. Which components are deployed in the same process or application boundary?
4. Which database schemas and tables are part of the final deployed database?
5. Which relationships are enforced by foreign keys, unique constraints, or application logic?
6. What is the authoritative persisted assessment status when AwaitingPayment is nested under Submitted?
7. What is the effective prenotification-to-shipment limit: 30 or 60 days?
8. Does rejection or partial rejection clear receipt data, and can a partial rejection subsequently complete without a receipt?
9. Are external and internal movement paths intentionally subject to different file, date, quantity, and authorization rules?
10. Which mediator requests are reachable through the API mediator, and is there a complete allow-list?
11. Which filters, decorators, handlers, repositories, or database procedures provide the effective authorization boundary?
12. Are events durable and retried, and are they inside or outside the database transaction?
13. Are email, scanning, document generation, and cache refresh synchronous, background, scheduled, or externally driven?
14. What is the authoritative file lifecycle and orphan-cleanup process?
15. Which configuration is active in production, including secrets, endpoints, scopes, TLS settings, error detail, and maintenance mode?
16. Which tests were actually executed, and against which source revision and database schema?

The draft is a useful evidence-bounded narrative foundation, but it should not be treated as a completed diagrams.md until those uncertainties are represented visually and the narrative is shortened around the diagrams.