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

Application overview

Scope and system boundary

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

The evidence supports a source-level view rather than a proven production architecture. Components include ASP.NET MVC and Web API applications, Razor views, request handlers, domain and core models, repositories, Entity Framework, SQL and stored procedures, document-generation code, email and scanning services, middleware, migration utilities, and tests. Projects and dependencies target both .NET Framework 4.5.2 and 4.8 in the supplied material. A single application-wide target framework, deployment boundary, runtime process, hosting model, or production topology cannot therefore be confirmed.

The broad business interpretation is that external parties prepare and submit regulated notifications, while internal or competent-authority users assess notifications, record consent and financial-guarantee decisions, and process shipment movements. This interpretation is supported by the combined source surface but is not established as a complete end-to-end process.

Actors and access context

The evidence distinguishes the following actors and access contexts:

• External users, including applicants, exporters, importers, producers, carriers, notification owners, and users receiving shared access.
• Internal users associated with a competent authority.
• Competent-authority staff and administrators.
• Notification owners and users with explicitly shared access.
• Movement or shipment operators, although it is not established whether these are a distinct user population.
• System and deployment operators responsible for maintenance, migrations, scanning, email, and other technical services.
• Technical callers using Web API, mediator, repository, or client-library interfaces.

Internal users may be checked against their competent authority. External access may depend on notification ownership or sharing. The cited import-notification authorization path denies access to non-internal users, while export-notification paths are described as using ownership or sharing checks. These rules are visible only in selected paths; the complete role, claim, organization, tenant, and permission model is unresolved.

Authorization appears at several layers, including request metadata, controller attributes, filters, mediator decorators, authorization services, user context, repositories, ownership filters, and competent-authority checks. Some identifier-based repository operations do not show a repository-level access check. This does not prove that those operations are unprotected because enforcement may occur in a controller, handler, middleware, decorator, stored procedure, or caller.

Entry points and processing styles

The application exposes or represents several entry-point styles:

• Server-rendered MVC controllers and Razor views for user-facing workflows.
• Web API controllers and attribute-routed operations.
• Mediator-style requests and asynchronous handlers.
• Repository and Entity Framework operations.
• Raw SQL and stored-procedure calls.
• Database and migration utilities invoked from the command line.
• Client-side AJAX requests for lookup and partial-view updates.
• Supporting services for email, document generation, PDF conversion, virus scanning, and external company lookup.

The responsible human or system caller for several handlers is unknown. Controller tests showing navigation, returned views, mocked mediator calls, or redirects do not establish production persistence, route activation, or downstream processing.

Core data

Notifications represent identifiers and numbers, creation and intended dates, notification type, trade direction, competent authority, status, parties, organisations, producers, exporters, importers, facilities, carriers, routes, customs offices, waste, shipments, movements, assessments, payments, financial guarantees, documents, comments, audit records, and progress information.

Many values are nullable or represented through flags, including interim status, pre-consent, receipt, completion, rejection, cancellation, archive, withdrawal, objection, and key-date fields. The evidence does not establish the valid combinations of these values, whether every field is mandatory in every workflow, or whether uniqueness and referential integrity are enforced in the database, application, or both.

Draft data and bulk-upload records are represented separately from finalized notification and movement data. The supplied evidence indicates that drafts may be stored as serialized data and later used to create notification, shipment, waste, route, facility, producer, and movement entities. The complete draft-to-final promotion process and its transaction boundary are not established.

Notification and assessment processing

Notification creation may generate a competent-authority-specific notification number, construct a notification application, and raise a notification-created event. Separate evidence indicates that notification creation can initialize an assessment and a financial-guarantee collection before persistence. Whether these operations are always performed together is unresolved.

Assessment statuses represented in the evidence include:

NotSubmitted, Submitted, NotificationReceived, InAssessment, ReadyToTransmit, Transmitted, DecisionRequiredBy, Consented, ConsentWithdrawn, Resubmitted, Reassessment, Objected, Withdrawn, FileClosed, UnderProhibition, InDetermination, and related values such as AwaitingPayment and AwaitingAssessment.

These values establish representable states, not a complete production state machine. Test-derived and source-visible transitions include:

• Submission after notification progress is complete.
• Receipt from a submitted state, with a received date.
• Commencement after receipt, payment receipt, and a non-empty officer name.
• Progression through assessment, transmission, acknowledgement, decision-related states, consent, withdrawal, unlocking, reassessment, prohibition, and closure.
• Resubmission from selected unlocked or consent-unlocked states.
• Editing in early or unlocked states and read-only behaviour in selected later states.

There is a material state-description ambiguity. One state-machine configuration shows NotificationReceived accepting submission and moving concretely to AwaitingPayment, while AwaitingPayment appears beneath a broader Submitted state. Describing this as a transition to Submitted is an abstraction over the hierarchy rather than the precise destination shown by that configuration. It is unknown which state is persisted, displayed, or used by each caller.

Submission may change status and raise status-change and submission events. Event persistence, dispatch, ordering, retries, consumers, and failure handling are not established. Commencement, consent, withdrawal, prohibition, archive-reference assignment, and key-date changes may similarly invoke domain methods and save through repositories or contexts, but the complete eligibility and authorization rules are not available.

Movements and shipments

Movement states include New, Captured, Submitted, Received, Completed, Rejected, Cancelled, and PartiallyRejected. Separate internal and external receipt and completion paths are represented.

Observed movement-creation and capture checks include:

• Movement-number availability or uniqueness within a notification.
• Notification consent status.
• Shipment and movement-date validity.
• Shipment-count and remaining-quantity limits.
• Active-load limits.
• An approved or released financial guarantee.
• Consent-period validity.
• Packaging and quantity requirements.
• Prenotification-date combinations.
• Movement-number generation.

The source describes movement numbers being generated by selecting an available positive number, sometimes filling gaps and starting at one. Concurrent allocation and database-level uniqueness are not established.

External receipt requires a non-default file identifier, a date, and a quantity. Internal receipt requires a valid date and quantity and rejects dates later than the current UTC date; it does not require a file identifier. External completion requires a non-default completion date and file identifier. Internal completion additionally rejects future dates and dates earlier than the receipt date. It is therefore directly supported only for the internal path that completion cannot precede receipt.

Rejection and partial rejection create rejection records and may remove or alter receipt data. Partial rejection requires a rejected quantity less than the actual quantity in the cited implementation; equality is rejected even where wording refers only to quantities exceeding the actual amount. A reason check based on IsNullOrEmpty does not reject whitespace-only text.

The evidence contains a material contradiction concerning receipt clearing. Some passages state that rejection and partial rejection clear a receipt when the movement was previously Received; another inspection reports that the receive methods do not show receipt clearing. This contradiction is unresolved. Partial rejection can subsequently transition to completion, but it is unknown whether a receipt must exist, is restored, or is not required.

Financial guarantees and payments

Financial-guarantee operations include creation, completion, approval, refusal, replacement, release, status retrieval, and history retrieval. Represented statuses include AwaitingApplication, ApplicationReceived, ApplicationComplete, Approved, Refused, Released, and Superseded.

Observed rules include:

• Approval requires a completed application.
• Approval requires a non-empty reference.
• Refusal requires a completed application and a non-empty, non-whitespace reason.
• Decision dates are subject to ordering and future-date checks in selected paths.
• Active-load and permitted-load values participate in approval validation.
• Blanket-bond, cover-amount, and calculation-continuation values are represented.
• Release is associated with approved guarantees in the cited state-machine evidence.
• A new approved guarantee may supersede or release an existing approved guarantee depending on the reference.

The relationship between guarantee status, decision, release date, validity period, and status-history records is not fully established. One release path preserves the approved decision while setting a release date, but the intended meaning of this state is unresolved. The complete authority and concurrency rules, including whether self-replacement or multiple approved guarantees are possible, are unknown.

Payment and refund operations represent credits, debits, payment dates, receipt numbers, payment methods, comments, charges, refunds, and balances. Cheque payments require a receipt number in the cited request validation. Payment completion can update an assessment’s payment-received date when the calculated balance is fully paid. Refunds are described as requiring prior payment, not exceeding an applicable limit, not being future-dated, and not preceding the first payment.

Different handlers and mappers classify transactions differently and may return different Boolean results for payment and refund operations. The authoritative calculation, transaction ordering, negative-value rules, currency, rounding, and reconciliation behaviour are unresolved.

Supporting data and documents

Waste processing supports Basel, OECD, EWC, Y, H, HP, UN, customs, national, custom, and not-applicable code representations. Waste operations distinguish recovery and disposal, and operation-code choices may depend on notification type and interim status. Chemical composition, physical characteristics, wood information, process of generation, technology employed, packaging, and additional waste information are also represented.

Validation messages and view models describe rules for required codes, not-listed and not-applicable states, code-type consistency, operation-code selection, mixed recovery and disposal codes, concentration values, minimum and maximum relationships, descriptions, annexes, and further information. Resource text does not prove that every corresponding validator is active or used on every processing path.

Documents are generated through ordered blocks and OpenXML or related document-generation components. Blocks can populate the main document, generate annexes, merge fields, clone table rows, and add table-of-contents or instruction content. Carrier, facility, customs-office, producer, waste-code, transit-state, and waste-composition data may be split between the main document and annexes.

Generation can fail when required template fields, rows, ancestors, facilities, or collection items are missing or duplicated. Some implementations use First() or Single(), and some mutate internal data while generating annexes, making repeated invocation potentially non-idempotent. Template validity, successful rendering, file persistence, transmission, download authorization, and recovery from generation failure are unknown.

Reporting and search

Search and reporting support notification numbers, notification types, trade direction, competent authorities, producers, exporters, importers, facilities, countries, local areas, dates, statuses, interim status, waste codes, operation codes, financial guarantees, and free-text criteria.

Searches may use SQL views, stored procedures, caches, raw SQL, Entity Framework queries, and DTO mappings. Some reports combine export and import data using UNION or UNION ALL, with different joins and status derivation. Inclusive BETWEEN date ranges are used in some paths, while another audit range uses an end-exclusive boundary. Caller normalization of date-only values is unknown.

Reporting caches represent shipment, producer, waste, consent, route, facility, rejection, officer, and freedom-of-information data. Cache population, refresh triggers, consistency, invalidation, retention, and visibility of newly changed records are unresolved. A report may omit a record because of joins, filtering, cache freshness, or result-set translation without proving that the underlying notification is absent.

External and technical services

The evidence represents integrations with:

• Identity and token services, including OWIN, bearer-token validation, IdentityServer-related middleware, OAuth clients, claims transformation, and user-information clients.
• Companies House lookup.
• Email infrastructure and templated email generation.
• WordprocessingML and PDF document generation.
• Virus-scanning services and local temporary-file scanning.
• SQL Server, stored procedures, reporting views, caches, and migration utilities.

These integrations are evidenced mainly through source structure, configuration, request construction, or project references. Production endpoints, credentials, scopes, certificates, contracts, ownership, availability, timeout, retry, cancellation, failure mapping, and monitoring remain unknown.

A virus-scanning API is described as exposing an authenticated scan operation and an anonymous health-style operation. One observed implementation returns "ok" for the health-style action. The deployed identity configuration, route activation, upload limits, temporary-file cleanup, scanner failure handling, and quarantine policy are not established.

Failure paths and consistency boundaries

Potential or observed failure paths include:

• Missing or duplicate records causing Single, SingleAsync, First, or FirstAsync failures.
• Null or incomplete nested objects causing dereference failures.
• Invalid dates, numbers, decimals, enums, identifiers, or JSON causing conversion exceptions.
• Missing or stale TempData and session values disrupting multi-step workflows.
• Malformed or tampered hidden fields affecting model binding or subsequent requests.
• Failed external lookup, token, email, scanner, document, or database calls.
• Missing or malformed document template fields.
• Migration failure during destructive changes, non-null alterations, lookup replacement, or backfill.
• Partial persistence where files, database records, audits, events, and email are processed separately.
• Event dispatch failure after database persistence.
• Cache refresh failure leaving reporting data incomplete or inconsistent.
• Authorization-related exceptions being converted to null or generic errors in selected paths.

Some operations use explicit database transactions and roll back on exceptions, including selected archive, draft bulk-upload, movement creation, or receipt/recovery paths. Other handlers perform multiple saves or combine file and database operations without a visible shared transaction. An outbox, coordinated event persistence, retry policy, compensation mechanism, and system-wide unit-of-work boundary are not established.

Current-system evidence limits

The supplied evidence does not establish the complete database schema, deployed topology, route inventory, authorization registrations, production callers, transaction boundaries, concurrency controls, retention, backup and recovery, logging, monitoring, alerting, integration behaviour, or operational ownership. Several source ranges, inventories, test names, migration descriptions, status mappings, and second-opinion summaries conflict.

The current-system description should therefore remain bounded to the observed source elements, test assertions, configuration fragments, and summarized evidence. Declared models, views, resources, request contracts, migrations, and tests demonstrate representability or intended behaviour; they do not by themselves prove successful deployment, complete lifecycle enforcement, production correctness, security effectiveness, or complete coverage.

Content quality review

Advisory; not approval. Review status: advisory.

Advisory review of overview.md

Overall assessment

The draft is broadly relevant to the requested purpose. It correctly treats the material as a partial, source-level description rather than a verified production architecture or complete specification. It also does a good job distinguishing representable states from proven lifecycle behaviour and repeatedly preserves uncertainty around authorization, persistence, deployment, integrations, transactions and runtime operation.

However, the draft is too expansive for an application overview and sometimes converts a large body of heterogeneous evidence into a more coherent system narrative than the evidence can safely support. It would be stronger if it separated:

• directly observed implementation behaviour;
• test-derived expectations;
• declarations or configuration indicating intended behaviour;
• secondary summaries and inferred interpretations; and
• unresolved contradictions or evidence gaps.

The draft should not be treated as complete or approved on the current evidence.

Relevance and scope

The draft is relevant in covering system boundary, actors, entry points, data, workflows, movements, guarantees, reporting, integrations and operational limits. Those are appropriate overview topics.

The stated scope is occasionally stronger than the evidence supports. For example:

> “The supplied evidence describes an application family for managing international waste-shipment notifications under European and UK rules.”

This should be softened to say that the evidence describes or appears to describe such an application family. The material contains regulatory wording and competent-authority data, but it does not independently establish the legal rules, their currency, or that every component belongs to the same deployed application.

Similarly, “System and deployment operators responsible for maintenance, migrations, scanning, email, and other technical services” describes inferred responsibilities, not clearly evidenced actors. It should be presented as a possible operational role or system concern, not as an established actor population.

“Technical callers using Web API, mediator, repository, or client-library interfaces” also risks conflating implementation layers with actual callers. A safer formulation would be “technical interfaces and internal components are represented; the production callers and invocation paths are unknown.”

Claims that need qualification or correction

Regulatory and business interpretation

The sentence describing external parties preparing and submitting regulated notifications and competent-authority users assessing them is a reasonable interpretation, but it should remain explicitly labelled as an inferred business interpretation. The supplied views, models and handlers support the interpretation, but do not establish a complete end-to-end operational process or the responsibilities of each actor.

The wording “under European and UK rules” should not imply that compliance with those rules has been established. It is safer to refer to “workflows and content referring to European and UK waste-shipment requirements.”

Authorization and actors

The draft correctly notes that authorization is distributed and incomplete. It should be more precise that a missing repository-level check is an evidence gap rather than necessarily a design defect. The draft generally does this well, but the repeated treatment of identifier-based operations could be consolidated to avoid suggesting that the repository layer is expected to be the authoritative security boundary.

The distinction between external users, notification owners, shared users, competent-authority staff and administrators is supported in selected paths, but the draft should avoid implying that these are complete or mutually exclusive roles. It should state that the full role, claim, organisation and competent-authority model is unresolved.

Notification lifecycle

The assessment-state discussion is one of the stronger parts of the draft. It appropriately identifies that the concrete state AwaitingPayment may be nested below Submitted, and that describing the transition as merely “Submitted” loses information.

That ambiguity should be elevated earlier and connected to its consequences: persisted status, displayed status, authorization decisions, reporting filters and movement eligibility may all differ depending on whether callers use the parent or concrete state.

The draft should also make clear that the listed states are drawn from multiple source contexts and tests. The evidence contains several status vocabularies, mappings and migration values that may relate to different notification domains or application versions.

Missing important contradiction: 30 days versus 60 days

The draft does not sufficiently highlight the repeated and material contradiction concerning the prenotification-to-shipment limit. The supplied evidence repeatedly reports that executable logic allows up to 60 days, while messages or business wording refer to 30 days. This is one of the most important unresolved business-rule conflicts and should appear in the notification or movement overview, not only implicitly under general date uncertainty.

A correction could state:

> “The evidence contains a material 30-day versus 60-day contradiction for the interval between prenotification and shipment. Some executable paths and tests indicate 60 days, while resource text and other descriptions indicate 30 days. The authoritative rule, boundary inclusivity and applicable workflow are unresolved.”

This should not be presented as a confirmed defect without identifying the authoritative requirement and the active production path.

Receipt clearing contradiction

The receipt-clearing contradiction is correctly included and appropriately unresolved. The draft should make the provenance distinction clearer: one source or analysis reports receipt clearing in rejection paths, while another inspection of the receive methods did not show it. These observations may concern different methods or stages rather than necessarily describing the same code path.

Movement completion and partial rejection

The draft correctly identifies that internal completion checks future dates and receipt ordering, while the same check is not visible for external completion. It should also cross-reference the unresolved possibility that rejection or partial rejection clears receipt data while later completion expects a receipt date. This relationship is important enough to state as a single unresolved invariant rather than in separate paragraphs.

Financial guarantees

The guarantee section is generally well bounded, but it omits some material evidence conflicts:

• monetary upper-bound checks around 9,999,999.99 are reportedly commented out while related validation messages remain;
• release may preserve an approved decision while adding a release date;
• self-replacement and multiple approved guarantees are unresolved;
• some tests and source descriptions use different meanings for status values and release or supersession.

The draft should include the commented-out upper-limit issue as a source-level inconsistency, while making clear that this is not evidence that the limit is required or that a production defect exists.

Payments and refunds

The draft appropriately notes inconsistent Boolean results and unresolved calculation rules. It could be more precise that a Boolean result alone does not demonstrate inconsistency: different handlers may have different contracts. The correction should say that the handlers appear to return different Boolean conventions, and that callers or request contracts are needed to establish whether this is a defect.

The distinction between credit and debit transaction classification, negative values, refunds, payment-received dates and balance calculation is important and could be stated more directly as an unresolved accounting contract rather than dispersed across several paragraphs.

Documents

The document-generation discussion is relevant and supported at source level. It should distinguish more clearly between:

• document block ordering;
• annex construction;
• rendering and template manipulation; and
• successful file generation, storage, transmission or download.

The draft does this in parts, but “Generation can fail…” could be read as an operational conclusion. Use “the shown implementations contain failure paths in which…” and retain that actual reachability and production incidence are unknown.

The statement that repeated invocation may be non-idempotent is reasonable as a code-level risk, but it should not imply that the generation service promises repeatability. The draft does mention that repeated invocation may not be supported; that caveat should be placed immediately next to the concern.

Reporting

The reporting section is useful but broad. It combines search, reports, caches, raw SQL, views, stored procedures and DTO mapping without always identifying which facts belong to which path. In particular, date-boundary behaviour differs between inclusive BETWEEN queries and end-exclusive audit ranges. This should be explicitly described as path-specific rather than as a general reporting rule.

The overview should also retain the important evidence that reports may omit records for several distinct reasons—joins, filters, cached data and result translation—and that absence from a report is not proof of absence from transactional data. The draft includes this point well.

External services and scanner

The scanner section needs stronger provenance wording. The evidence is inconsistent: some material describes an authenticated POST and anonymous health-style GET as observed implementation, while another account treats the health action as a candidate scenario. The draft currently says:

> “A virus-scanning API is described as exposing…”

That is mostly safe, but it should add that route activation, deployment and the relationship between the cited controller and the deployed scanner remain unverified.

The wording “returns \"ok\" for the health-style action” should be explicitly restricted to the observed implementation, not the deployed service.

Missing behaviours or underrepresented topics

The draft is extensive, but several important behaviours from the supplied evidence are absent or underemphasised.

Draft-to-final promotion

The draft mentions serialized drafts and says the promotion process and transaction boundary are unresolved. This should be a more prominent lifecycle gap. The evidence describes draft completion involving exporters, importers, facilities, producers, shipments, routes, waste data, assessment submission and address-book operations, but does not establish:

• which draft fields are authoritative;
• whether promotion is atomic;
• whether the draft is deleted after successful promotion;
• whether repeated promotion is idempotent;
• how partial promotion is recovered; or
• whether draft identifiers and notification identifiers are cross-checked.

Ownership transfer and sharing

The draft mentions sharing and ownership but gives less detail than the evidence supports. It should identify that sharing uses temporary state, posted user identifiers and email addresses, and that confirmation paths may not visibly revalidate the expected state. It should also distinguish:

• adding a shared user;
• removing shared access;
• transferring notification ownership; and
• changing or deactivating users.

These are different behaviours with different evidence and should not be grouped as one “sharing” capability.

Account and identity flows

The overview mentions authentication and authorization, but it underrepresents the evidence gaps around:

• email verification;
• password reset and email delivery;
• user deactivation/reactivation and lockout;
• claims transformation and claim loss;
• administrator approval;
• session and cookie behaviour; and
• custom TempData serialization using BinaryFormatter.

The BinaryFormatter-based cookie TempData provider is a material source-level security and reliability concern in the evidence and should either be included as a qualified risk or explicitly excluded from this overview with a pointer to a security-specific review. If included, it must be described as a conditional risk dependent on whether attacker-controlled object graphs can influence deserialization and on deployment key and cookie handling.

Configuration and deployment concerns

The draft says deployment topology, credentials, scopes and secrets are unknown, but omits several concrete configuration concerns in the evidence:

• plaintext or apparently embedded API and client-credential values;
• development-oriented configuration and uncertain release-transform application;
• permissive or potentially exposed Elmah settings;
• very large request limits and long timeouts;
• TLS 1.1 being enabled alongside TLS 1.2;
• mixed target frameworks and package versions;
• migration tooling that may ignore process exit codes or use fragile path and quoting assumptions.

These should not all be placed in the overview, but the current draft’s “External and technical services” section is too generic compared with the evidence. A short “representative configuration risks” paragraph would make the overview more useful while preserving uncertainty.

Migration and schema evidence

The draft discusses migration uncertainty generally but does not identify representative concrete migration risks. The evidence includes potential trailing commas in SQL, destructive column/table changes, nullable-to-non-null conversions, WITH NOCHECK, ambiguous TOP 1, unguarded inserts, NOT IN with nullable subqueries, lossy date and quantity conversions, and possible broad duplicate cleanup.

The overview need not enumerate every migration, but it should state that migration evidence contains both ordinary schema evolution and potentially destructive or non-idempotent transformations, with no supplied execution logs, postconditions, rollback evidence or reconciliation results. At least one or two examples should be retained to show why the gap is material.

Error and HTTP response behaviour

The draft lists possible failure paths but does not consolidate the evidence around HTTP handling:

• custom 403, 404 and 500 routes;
• anti-forgery failures mapped to HTTP 400;
• virus errors;
• maintenance-mode HTTP 503;
• API error filters;
• selected authorization failures converted to null or generic errors; and
• scanner exceptions potentially returned with detailed error contents.

A system overview should state that error mapping is path-specific and incomplete, rather than only listing exceptions that may occur.

Contradictions and evidence gaps in the draft itself

The draft is internally cautious, but some wording is still more definitive than the evidence.

• “The evidence distinguishes the following actors…” should be changed to “The evidence refers to or supports the following possible actors and access contexts.”
• “The application exposes or represents several entry-point styles” is safer than saying it exposes them, because route activation and deployment are unresolved. The draft currently uses both formulations; standardize on “source represents” unless a route is directly evidenced.
• “Core data” says notifications represent many relationships and statuses. This is supported as a model surface, but not necessarily as a deployed schema or active data model. Add “in the observed models, mappings or queries.”
• “Movement states include…” should state that these are representable or observed in selected state-machine configurations and tests, because the evidence contains different status sets.
• “Search and reporting support…” should be scoped to selected implementations and declarations rather than the application as a whole.
• “A virus-scanning API is described as exposing…” needs the contradictory provenance caveat noted above.
• “Some operations use explicit database transactions…” is supported, but the draft should distinguish database transactions from coordinated transactions across file storage, event dispatch, email and external calls.

The evidence itself contains many conflicting source ranges, hashes, inventories and second-opinion summaries. The draft mentions this at the end, but it should explain that these conflicts affect claim provenance, not merely completeness. A claim supported only by a secondary summary should not be presented at the same confidence level as a claim supported by a directly quoted implementation or executed test.

Evidence gaps versus defects

The draft generally distinguishes these, which is a strength. It should preserve that distinction consistently using labels such as:

• Observed source behaviour
• Test assertion or expected behaviour
• Potential defect
• Contradiction
• Absent evidence
• Runtime or production status unknown

For example:

• A missing repository authorization check is an evidence gap unless the complete call path shows no higher-level protection.
• A Single() call is a potential failure path, not a defect unless zero or multiple records are valid or reachable.
• A commented-out monetary limit is an implementation inconsistency, not proof that the business rule is required.
• A trailing comma in a migration is a conditional syntax concern until the executable bytes and execution result are confirmed.
• A raw HTML call is a security-sensitive sink, not a confirmed XSS vulnerability without input provenance and rendered-output evidence.
• A source-level NotImplementedException is a concrete implementation limitation, but its production impact remains unknown unless reachability is shown.
• The 30-day/60-day difference is a genuine evidence contradiction, but not necessarily a defect until the authoritative rule is identified.

These distinctions should be applied in headings or short status phrases rather than only in closing caveats.

Recommended structural corrections

The overview would be clearer and less repetitive if reorganized into a shorter hierarchy:

1. Purpose and evidence confidence
2. Observed system scope
3. Possible actors and access contexts
4. Observed components and entry points
5. Business data and major workflows
6. Selected lifecycle and movement rules
7. Documents, reporting and integrations
8. Representative unresolved risks
9. Contradictions requiring resolution
10. Evidence gaps and questions

The current draft repeats “not established,” “source-level,” “does not prove,” and “unknown” throughout almost every paragraph. Those qualifications are necessary, but repetition makes the substantive findings harder to identify. Put a concise confidence statement at the start of each section and use shorter

section-level qualifiers instead of repeating the same limitation after every sentence. For example, a paragraph headed Source-observed movement rules can state once that the observations are limited to cited implementations and tests, then list the rules and remaining uncertainties.

The overview should also avoid presenting every observed defect candidate. A separate risk register or detailed evidence log would be a better location for individual null dereferences, spelling anomalies, resource mismatches, CSS concerns and test-fixture weaknesses. The overview should retain only risks that materially affect system interpretation, such as:

• the unresolved 30-day versus 60-day shipment rule;
• the ambiguous assessment-state hierarchy;
• receipt and partial-rejection consistency;
• draft-to-final promotion and transaction boundaries;
• incomplete authorization and identifier-scope evidence;
• file, database, event and email consistency boundaries;
• migration safety and final-schema uncertainty;
• identity, cookie, TempData and configuration concerns; and
• reporting-cache and date-range semantics.

Specific corrections are therefore:

1. Replace statements that the system is or exposes a capability with statements that the supplied source represents, contains, or describes that capability, unless route activation or execution is directly evidenced.
2. Add a concise provenance convention distinguishing implementation observations, tests, declarations, summaries and inference.
3. Elevate the 30-day/60-day contradiction and identify its affected workflows and unresolved boundary inclusivity.
4. Expand the draft-to-final section to describe the unresolved promotion, deletion, retry, idempotency and transaction questions.
5. Separate ownership transfer, shared access, shared-user removal, deactivation and reactivation.
6. Add a bounded paragraph on account, claims, cookie and TempData behaviour, including the conditional risk associated with BinaryFormatter.
7. Add representative configuration and migration concerns rather than referring only to generic deployment uncertainty.
8. Add a short explanation that HTTP error and status handling is path-specific and not shown to be uniform.
9. Recast payment and refund differences as unresolved contract differences until callers or request specifications establish that the Boolean results are intended to have the same meaning.
10. Move low-impact presentation and naming observations to a detailed findings section or appendix.
11. Avoid treating repeated summaries as independent corroboration. Where provenance is unclear, state that the claim is supported only by secondary analysis.
12. Standardize terminology: use “representable,” “observed in a selected path,” “test-derived,” “declared,” “potential,” and “not evidenced” consistently.

Unresolved questions requiring evidence

The following questions remain material to the purpose of an application overview:

• Which projects, databases, APIs, libraries and migration sets belong to the same deployed release?
• What is the authoritative production target framework, hosting model, route inventory and application boundary?
• Which concrete status is persisted after submission from NotificationReceived, and how do parent and child state values affect permissions, reporting and movement eligibility?
• Is the prenotification-to-shipment limit 30 or 60 days, and does the rule use calendar days, working days, date-only values or timestamps?
• Can rejection or partial rejection remove receipt data, and can a partially rejected movement subsequently complete without a valid receipt?
• What invariant limits approved financial guarantees, and how are replacement, release and supersession distinguished?
• What are the authoritative payment, refund, balance, currency and rounding rules?
• How are drafts promoted into final notifications and movements, and what happens after partial failure or repeated promotion?
• Which layer authorizes every read, mutation, deletion, download, sharing operation and identifier-based request?
• Are posted notification, movement, user, facility and charge identifiers reloaded and checked against authoritative state?
• Which events are persisted or dispatched, and what are the retry, ordering, idempotency and post-commit failure rules?
• Are files, database changes, audit records, email and document generation coordinated or compensating independently?
• Which migration files actually ran, against which schema version, with what transaction, backup, validation and rollback evidence?
• Are reporting caches refreshed atomically, and what freshness guarantees apply to reports?
• Are scanner, email, Companies House, OAuth and document-generation integrations active in production, and what are their timeout, failure and monitoring contracts?
• Are the apparent secrets, development settings, Elmah access settings, request limits and TLS settings active, transformed or overridden in deployment?
• What tests were actually executed, against which source revision and database state, and which results were obtained?

Until those questions are answered, the draft is best treated as a bounded advisory overview of supplied evidence. It is not a verified current-system description, a complete architecture record, a security assessment, a legal interpretation, or evidence that the implementation is fit for production use.