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

Operations

Operations

The supplied evidence describes operational capabilities around maintenance mode, database and migration tooling, reporting and cache refresh, document and email generation, virus scanning, logging, backups, and external-service calls. These capabilities are distributed across ASP.NET MVC, Web API, OWIN, console utilities, Entity Framework, SQL Server procedures, file storage, and supporting libraries. The evidence does not establish that all components belong to one deployed runtime, process, host, or operational boundary.

Operational actors and entry points

Supported operational actors appear to include application and deployment operators, database administrators, internal or competent-authority users, administrators, external applicants, and system-operated components. The distinction between operational responsibilities is not established.

The application exposes MVC and Web API routes, including maintenance, health-style, scanning, reporting, administration, and error paths. A virus-scanning API has an authenticated POST scan action and an anonymous GET health-style action that is reported to return "ok". A maintenance filter can return HTTP 503 ServiceUnavailable when maintenance mode is active. The scope of maintenance handling is not known: MVC routes, Web API routes, static content, health endpoints, and administrative bypasses may not all behave identically.

A console database utility provides operations described as update, create, rebuild, test-data, baseline, and exit. It invokes AliaSQL.exe using values derived from configuration and the current working-directory layout. A separate schema-comparison PowerShell script creates a temporary database, extracts or compares schemas, generates SQL, and removes temporary artefacts. The supplied material does not establish who may invoke these tools, whether they are suitable for production use, or whether an approval or change-control process surrounds them.

Configuration and startup

Configuration is read from Web.config, connection strings, cloud-configuration facilities, and application settings using an Iws. prefix. Some settings have DefaultValue fallbacks, while missing settings may raise ConfigurationErrorsException. Reported settings include environment, site root, culture and UI culture, session timeout, maintenance mode, database connection details, API and scan-service endpoints, OAuth values, email delivery settings, proxy values, upload paths, and retry or timeout-related values.

Several configurations are development-oriented, including local HTTPS endpoints, local SQL Server Express, integrated security, debug compilation, and a local email pickup directory. Release transforms remove explicit debug compilation settings and alter error handling, but the evidence does not establish that those transforms are applied during deployment or what the final deployed configuration contains.

The application is associated with .NET Framework 4.8, while other project or generated-resource evidence refers to .NET Framework 4.5.2 or runtime metadata such as 4.0.30319.42000. Package references also cover more than one target framework. These observations may describe different projects, compatibility settings, or historical configurations; a single application-wide target and deployed runtime cannot be confirmed.

Startup and composition evidence includes OWIN, Autofac, IdentityServer middleware, bearer-token validation, claims transformation, MVC and Web API routing, global filters, Entity Framework modules, logging registrations, and request decorators. The complete registration set and effective ordering are not established. A no-op event dispatcher exists in one context, while another context registers active event-dispatcher and deferred-dispatcher components; whether these are alternative deployments or separate applications is unresolved.

Maintenance and service availability

Maintenance mode is represented by a request filter that can return 503 ServiceUnavailable, with an exception path for a maintenance endpoint. The filter may also be excluded for child actions or selected routes, but the complete bypass rules and registration scope are not supplied. The maintenance page contains user-facing service-unavailability and contact information.

Error routes and filters cover selected 403, 404, 500, API-error, anti-forgery, virus-found, and maintenance outcomes. The anti-forgery filter can clear the response, set HTTP 400, and render a cookie-error view. Some error responses include exception details or use includeErrorDetail: true; the exact production setting and disclosure boundary are unknown.

The Web API health-style endpoint is anonymous, but the evidence does not establish whether it verifies database access, dependency availability, scanner availability, or broader readiness. A database Exists() check is used in one smoke-test or health-related path, but this does not prove that it is deployed as a production health check.

Database operations and migrations

Entity Framework, IwsContext, raw SQL, stored procedures, SQL Server views, reporting objects, and migration scripts are all present. Persistence is asynchronous in many paths, but some operations stage entities synchronously or use synchronous saves. Selected operations use explicit transactions, including archive processing, draft bulk movement processing, notification copying, and some movement procedures. Other multi-step operations do not show a surrounding transaction.

The archive path invokes a parameterized stored procedure inside a transaction and is described as committing on success and rolling back on exception. One observed path returns false after a failure rather than visibly rethrowing it, and logging failures may be suppressed. The precise stored-procedure transaction boundary and interaction with the application transaction are unavailable.

Some movement and reporting procedures use transactions and re-raise errors, while other procedures do not show equivalent error handling. Export and import movement procedures differ in their treatment of conflicting outcome flags: one processes the first matching outcome branch, while another rejects multiple selected outcomes. Cache refresh procedures repopulate several reporting caches without an evidenced encompassing transaction, so intermediate or partially refreshed states remain possible but unconfirmed.

Migration scripts perform schema creation, table rebuilding, backfills, lookup insertion, relationship changes, column removal, status changes, constraint creation, filegroup and file-table creation, and data cleanup. Some scripts use XACT_ABORT, SERIALIZABLE, conditional object checks, or checked foreign keys; others use unguarded inserts, deletes, ALTER TABLE, GO batches, or destructive replacement operations. Rerun safety, migration ordering, backup and rollback procedures, preconditions, row-count checks, reconciliation, and post-migration validation are not established.

Several migration paths have conditional risks reported in the evidence, including dropped or recreated shipment fields, null-to-NOT NULL changes, nondeterministic TOP 1 selection, nullable NOT IN predicates, missing ELSE branches, lossy text or date conversion, heuristic quantity conversion, possible duplicate relationships, and broad duplicate cleanup. These are source-level or migration-level risks; migration execution and production impact are unknown. Some SQL files are unavailable as text because of NUL bytes or unsupported encoding.

Database utility and schema comparison

The database utility derives script locations from Environment.CurrentDirectory and parent-directory traversal. It assumes a particular build-output layout and may resolve incorrectly when launched from another location. The utility captures child-process standard output but does not visibly inspect standard error, enforce a timeout, or consistently inspect the child exit code. A non-zero exit may therefore be poorly surfaced if no useful output is emitted; this is an inspected failure-reporting concern, not a confirmed execution result.

The supplied command construction appears to contain an incomplete quote around the script path. Whether the invoked executable accepts or repairs the resulting argument depends on its command-line parser, which is not supplied. The utility also pauses for confirmation and returns to an interactive menu, but the evidence does not establish unattended execution, locking, backup requirements, or rollback behavior.

The schema-comparison script assumes a fixed database name and a SQL Server tooling path, creates a temporary database, generates a DACPAC and difference script, enables DropObjectsNotInSource=true, and disables blocking on possible data loss. It filters generated SQL using textual matching rather than SQL-aware parsing and does not show try/finally cleanup. Failures could leave temporary databases or files, although no execution failure is evidenced.

Reporting and cache operations

Reporting uses DTOs, Entity Framework queries, raw SQL, stored procedures, views, and denormalized cache tables. Report inputs include dates, competent authorities, organisations, notification types, trade direction, statuses, local areas, waste codes, operation codes, text fields, operators, and selected output columns. Outputs include Excel workbooks and mapped reporting data.

Reported report names and outputs include import statistics, producer, shipment, finance, compliance, freedom-of-information, export-notification, import-notification, and EA data reports. ClosedXML or similar workbook-generation code is present. Some reports use culture-dependent date formatting in filenames, while another increments the submitted end date before querying and constructing a filename. The intended date-boundary semantics are not established.

Reporting queries use different date conventions. Some use inclusive BETWEEN ranges, while other repositories use start-inclusive and end-exclusive ranges. A date-only upper bound may exclude records later on the same day, and adjacent reports may overlap or leave gaps. Cache freshness warnings state that some reports use a copy of live data one day behind, but cache population, refresh scheduling, invalidation, failure handling, completeness, and reconciliation are unknown.

Cache refresh procedures rebuild multiple cache areas and may mark rows as actioned by external users. There is no supplied evidence of an atomic refresh, reader isolation, retry policy, monitoring, or recovery from a partial refresh. Reporting results can also be affected by inner joins, UNION ALL, optional relationships, aggregate queries, and nondeterministic TOP 1 selection. These query observations do not establish incorrect production reports without deployed schemas, data, callers, and execution results.

Documents and file handling

Document generation uses Open XML or WordprocessingML templates, block factories, merge fields, annex generation, and, in some components, optional PDF conversion. Documents include notification, movement, interim movement, financial-guarantee, postage-label, preview, receipt, recovery, and disposal outputs.

Document blocks are processed in collection or ordinal order. Main-document blocks and annex generation may use different ordering. Duplicate ordinals are present in the evidence, and no explicit tie-breaker is shown. Output ordering may therefore depend on factory registration or collection order.

Document generation assumes expected templates, merge fields, tables, rows, ancestors, and facility or producer cardinalities. Single() and First() calls may fail when fields or data are missing or duplicated. Facility annex generation expects exactly one actual treatment site and mutates internal data while producing annexes, so repeated invocation may not be idempotent, although repeated generation is not shown to be supported.

Templates are loaded from a physical documents directory in at least one component. The evidence does not establish template versioning, template validation, document persistence, transmission, download authorization, rendering success, file naming collision handling, retention, retry, or recovery. Generated files may be stored before later movement or audit persistence, leaving a possible file/database consistency boundary.

File operations include upload, temporary-file creation, scanning, storage, retrieval, deletion, document generation, and Excel export. File identifiers are passed through route values or hidden fields in several views. Ownership, notification membership, path handling, filename sanitization, size limits, quarantine, retention, and access checks are not consistently evidenced.

Virus scanning

Virus scanning is represented by an authenticated scan operation, an anonymous health-style operation, local or client-based scanner implementations, and outcomes such as Unknown, Clean, Virus, and Error. A file-based scanner writes content to a temporary file, waits for a configurable period, and interprets the file’s continued existence as clean and its absence as virus. This does not establish that file content was actually inspected or that deletion necessarily represents malware detection.

The scanning API accepts a byte array. The evidence does not establish streaming, application-level size limits, throttling, quarantine, cleanup, scanner timeouts, cancellation, certificate validation, network retry, malformed-response handling, or scanner outage behavior. A scanner may be registered as a singleton while its file-access dependency lifetime is unclear. The consequences for shared state and concurrent scans are unresolved.

Some error responses disclose exception details. The production behavior for authentication, authorization, I/O, scanner, and unexpected exceptions is not fully specified. No execution results or production scan outcomes were supplied.

Email and messaging

Email components construct HTML and plain-text messages from templates and may embed images using content identifiers. Templates are loaded from assembly resources and may be cached. Domain events such as registration approval or rejection can trigger email handlers. A configured pickup directory is evidenced in some environments; this proves file-based handoff configuration, not delivery by an SMTP relay or mail service.

Email sending can be disabled or can return false when recipients are filtered out. Missing templates or no recipients may cause exceptions. Some handlers await the sender but ignore the Boolean result, so the relationship between a false delivery result and the user-visible outcome is unknown. SMTP settings, transport security, sender configuration, retries, timeouts, duplicate delivery, logging, template safety, and failure recovery are not established.

Email rules can remove or transform recipients according to configuration. Regex matching may be substring-based unless patterns are anchored. The rule cache and template cache have reported synchronization or lookup concerns, but their runtime effect is unknown. Dynamic-template insertion is present in one component, while template resolution does not visibly read the same dynamic-template store.

Logging, audit and diagnostics

Logging and diagnostics use ELMAH, Serilog, debugger output, SQL or XML error logs, and application audit records. Error records may include exception type, message, stack trace, user, host, status code, timestamps, and serialized XML. Some ELMAH settings allow remote access or do not require authentication, although the effective deployed protection is unknown.

An ELMAH filter suppresses logging for some unauthenticated 404 requests, reportedly treating them as possible probes. This reduces visibility for that class of request unless IIS or another layer logs it; IIS logging configuration is not supplied. Debug and non-debug configurations use different logging paths, but the active registration and multiple-logger interactions are unresolved.

Business audit data records selected actions such as assessment and guarantee changes, movement creation, rejection, receipt, cancellation, deletion, and status changes. Audit records may include notification, movement, shipment, user, screen, type, original and new values, and timestamps. The evidence does not establish system-wide audit completeness, immutability, access control, retention, redaction, atomicity with business changes, or monitoring of audit-write failures.

External services and API clients

The application includes identity and token services, OAuth or OpenID Connect clients, Companies House lookup, email, virus scanning, document generation, SQL Server, and reporting procedures. API clients attach bearer tokens, may use client credentials, and may apply Polly-based retries for selected HTTP statuses and exceptions. The configured scopes, token lifetime, endpoint availability, certificate behavior, retry count, backoff, timeout, cancellation, and exhausted-retry handling remain partly unknown.

HTTP wrappers log requests and responses, including response bodies and reason phrases for unsuccessful responses. Redaction, size limits, sensitive-data handling, log retention, and access control are not established. Some request paths concatenate query parameters or references into URLs without visible encoding, but the complete caller and server handling are unavailable.

Operational failure paths

Observed or reported failure paths include:

• maintenance responses with HTTP 503;
• custom 400, 403, 404, and 500 responses;
• anti-forgery exceptions;
• authentication and authorization failures;
• virus-found and scanner errors;
• malformed or missing uploads;
• missing or duplicate database rows causing Single, First, or SingleAsync failures;
• malformed dates, numbers, identifiers, JSON, or enum values;
• missing templates, merge fields, facilities, routes, or related records;
• database migration and constraint failures;
• child-process startup, quoting, timeout, output, or exit-code failures;
• email template, recipient, SMTP, or sender failures;
• partial persistence between files, database records, events, and audit records;
• report-generation and cache-refresh failures; and
• stale or missing TempData, session, or hidden-form state.

Failure translation is heterogeneous. Some paths return false, null, empty results, model-state errors, HttpNotFound(), or a generic error view. Others rethrow, raise domain exceptions, or suppress exceptions broadly. The system-wide distinction between missing data, authorization failure, operational failure, and programming failure is not established. Logging, retries, compensation, operator notification, and recovery for these paths are generally unknown.

Evidence limits

The supplied evidence does not establish the deployed topology, hosting and application-pool configuration, production settings, secret storage, database users and privileges, migration execution history, report refresh schedule, file-storage lifecycle, scanner deployment, email relay, background processing, monitoring, alerts, backup and restore operations, retention, release procedures, or operational ownership.

Source, test, migration, configuration, and summary evidence contain contradictions and incomplete coverage. Some tests are described without execution results, some scenarios are characterization expectations rather than verified tests, and some artifacts are missing or unreadable. The operational description should therefore be limited to the supported source elements and reported test or configuration observations. It does not establish that the described controls are active, complete, successfully deployed, or effective in production.

Content quality review

Advisory; not approval. Review status: advisory.

Overall assessment

The draft is materially relevant to operations.md and is generally careful not to present source observations as verified production controls. It covers the main operational concerns evidenced in the supplied material: maintenance mode, startup and configuration, database tooling and migrations, reporting and cache refresh, document and file handling, scanning, email, logging, external clients, and failure paths.

Its main weakness is not a single unsupported conclusion but breadth and repetition. It combines operational description with extensive application-behaviour, query, migration, security, and source-review detail. Much of that is useful context, but the document risks obscuring the operational conclusions and giving equal prominence to confirmed source facts, test expectations, secondary summaries, and hypothetical risks. The evidence itself repeatedly states that these categories must be kept separate.

Relevance and scope

The sections on maintenance, configuration, migration utilities, cache refresh, document generation, scanning, email, logging, external services, and operational failures are directly relevant.

Some material is operationally relevant but should be shortened or explicitly framed as context:

• Detailed report filter fields, workflow statuses, document block ordering, movement outcomes, and domain validation belong primarily in business-behaviour or application sections unless they affect an operational dependency, failure mode, data-quality risk, or support procedure.
• Long lists of possible null dereferences, parser failures, query inconsistencies, and migration risks are relevant as operational failure candidates, but should be grouped by consequence rather than repeated at implementation-detail level.
• The actor section currently mixes business actors with operational actors. External applicants, competent-authority users, and administrators may be application actors, not necessarily people responsible for operating the service.

A more focused structure would distinguish:

1. observed operational capabilities;
2. operational dependencies and boundaries;
3. source-level operational risks;
4. evidence of tests or configuration;
5. unverified production controls and ownership gaps.

Unsupported or overextended claims

Most statements are qualified, but several should be tightened.

Operational actors

The statement that supported operational actors “appear to include application and deployment operators, database administrators, internal or competent-authority users, administrators, external applicants, and system-operated components” is partly inferred from tool names, roles, and workflows. The evidence does not establish that deployment operators or DBAs are defined actors, nor who owns each responsibility.

Correction: describe these as “potentially relevant actors inferred from the source and tooling” and state that operational responsibility, segregation of duties, and ownership are not evidenced.

Health and readiness

The draft says that the anonymous scanner health-style endpoint is “reported to return \"ok\".” This is appropriately cautious, but the evidence contains a further qualification: some accounts treat this as a candidate scenario rather than confirmed runtime behaviour. The draft should explicitly preserve that distinction.

Correction: state that an implementation or test description identifies an anonymous GET health-style action returning \"ok\", but deployment, route exposure, authentication middleware interaction, and whether it is a liveness or readiness check are unverified.

The draft also mentions Database.Exists() but could make clearer that this is not evidence of a deployed health endpoint or dependency readiness check.

Configuration and runtime

The draft accurately preserves the conflict between .NET Framework 4.5.2, 4.8, and generated runtime metadata. However, the wording “the application is associated with .NET Framework 4.8” may still be read as an application-wide conclusion. The evidence includes multiple projects and possibly separate applications.

Correction: use “some project evidence targets .NET Framework 4.8, while other project, package, or generated-resource evidence refers to 4.5.2 or runtime metadata; the effective target of each deployed component is unresolved.”

Email delivery

The statement that a pickup-directory configuration “proves file-based handoff configuration” is reasonable, but “handoff” may imply a functioning handoff. It proves only that a pickup-directory delivery mode is configured in the observed configuration.

Correction: say it “shows configuration for file-based SMTP pickup; it does not establish that files are created, consumed by a relay, delivered, or monitored.”

ELMAH and diagnostics

The draft says some ELMAH settings allow remote access or do not require authentication. The evidence supports this as configuration evidence, but the operational risk depends on the effective deployed configuration and IIS/network exposure.

Correction: explicitly label this as “source/configuration-level exposure risk requiring deployment verification,” rather than presenting it alongside operationally observed logging behavior.

Virus scanning

The draft correctly identifies the file-existence heuristic as weak evidence of scanning. It should also avoid implying that an absent temporary file is necessarily interpreted as a malware-positive result in every scanner path. The evidence describes that behavior for a particular file-based implementation, not necessarily the remote scanner or the whole scanning subsystem.

Correction: scope the statement to the named file-based implementation and separately describe remote/client scanner behavior as unresolved.

External-service retries

The statement that clients “may apply Polly-based retries for selected HTTP statuses and exceptions” is appropriately conditional. The draft should distinguish the presence of retry-wrapper code from confirmed registration and use. Some evidence gives concrete retry counts and delays in one client, while other evidence only identifies a wrapper.

Correction: state which retry details are directly visible in a specific client, and state that application-wide retry policy, idempotency safety, and registration are unknown.

Contradictions and tensions that need clearer treatment

The draft records many uncertainties, but several material contradictions deserve explicit cross-references rather than being dispersed.

Scanner health endpoint

There are at least three evidence positions:

• an authenticated POST scan and anonymous GET returning ok are visible or reported;
• the route and middleware deployment are unknown;
• some descriptions classify the behavior as a characterization candidate rather than executed or production-verified behavior.

The draft should identify this as an evidence-status conflict, not merely a deployment gap.

Maintenance scope

The draft correctly notes uncertainty over MVC, Web API, static content, health endpoints, and administrative bypasses. It should also distinguish the filter’s source behavior from global registration. A maintenance filter class or test does not establish that it is globally registered or that it affects every process or application.

Transaction boundaries

The draft describes several explicit transactions but sometimes moves quickly from “inside an application transaction” to broader operational implications. It should identify separately:

• transaction shown in application code;
• transaction shown in SQL procedure;
• transaction supplied by an external migration runner;
• file or email work outside the database transaction;
• event dispatch after persistence.

These are not interchangeable. In particular, a database transaction does not establish atomicity with file storage, email, scanner operations, audit publication, cache refresh, or external API calls.

Migration evidence

The draft lists numerous migration hazards, including destructive changes, NOT NULL conversions, TOP 1 without ordering, NOT IN with nullable values, and unreadable files. These are relevant, but the evidence also contains later migrations, possible corrective scripts, alternative schemas, and multiple source snapshots.

Correction: each migration concern should be labelled as one of:

• directly visible in the supplied SQL;
• dependent on missing schema/data;
• dependent on migration ordering;
• potentially corrected by later or unavailable scripts;
• execution status unknown.

Without that separation, the volume of risks may imply that migration failure or data loss was observed, which it was not.

Cache freshness

The draft states that some reports may use data one day behind and that cache refresh is not shown to be atomic. This is useful, but the evidence appears to contain both resource text describing delayed data and SQL procedures that refresh caches. It does not establish the schedule, trigger, successful execution, or whether all named reports use the same cache.

Correction: distinguish “user-facing warning that delayed data may be used” from “observed cache-refresh implementation” and “unverified freshness and reconciliation.”

Error detail disclosure

The draft mentions includeErrorDetail: true and exception details in some responses. It should make clear whether this is an implementation default, a test configuration, a development configuration, or an effective production setting. The evidence does not establish a production information-disclosure incident.

Missing operational behaviours

The final evidence-limits section is broad, but several operational questions should be made more explicit because they are important to the requested purpose:

• Who owns the service, database, scanner, email relay, document templates, reporting caches, and migration tooling?
• What are the deployment approval, change-control, segregation-of-duty, and emergency-change processes?
• Are migration backups taken, and has restore from those backups been tested?
• What are the recovery objectives, including RPO and RTO, for the application, database, files, reports, and email?
• Is there a tested disaster-recovery or failover arrangement?
• Are health checks monitored, and are alerts generated for failed dependencies, stale caches, scanner errors, email failures, migration failures, or disk exhaustion?
• Are there scheduled jobs, Windows services, queues, workers, or external schedulers for cache refresh, email processing, file deletion, archive processing, or event dispatch?
• What are file retention, quarantine, deletion, legal hold, and orphan-cleanup rules?
• How are document templates versioned, validated, released, and rolled back?
• How are secrets, certificates, machine keys, OAuth credentials, database credentials, and scanner credentials provisioned and rotated?
• Are database users least-privileged, and are migration accounts separate from application accounts?
• Are clock synchronization and timezone conventions defined for UTC/local date comparisons, audit order, report boundaries, consent periods, and working-day calculations?
• Are rate limits, concurrency limits, request-body limits, and storage quotas imposed outside the application?
• Are operational logs correlated to notification, movement, file, migration, and request identifiers?
• Are failed email, scanner, document, event, and external-service operations retried, quarantined, compensated, or surfaced to operators?

These are evidence gaps, not findings that the controls are absent.

Missing behaviours in the failure analysis

The failure section is comprehensive at code-path level but less explicit about operator-facing outcomes. It should ask what happens operationally when:

• a migration fails halfway through;
• a cache refresh fails after deleting old rows;
• a scanner is unavailable or returns malformed data;
• a file is stored but database persistence fails;
• an email send returns false without throwing;
• a document is generated but later audit or movement persistence fails;
• an external API succeeds but the local save fails;
• an event dispatch fails after the database commit;
• a child process exits non-zero without useful output;
• a temporary database or file is not cleaned up;
• a database connection or SQL Server procedure times out;
• two users submit conflicting movement, guarantee, ownership, or status updates.

For each, the document should distinguish the visible source behavior from the missing operational response: logging, alerting, retry, compensation, manual recovery, and user notification.

Evidence traceability

The draft contains no claim-level traceability to the supplied evidence. Phrases such as “reported,” “observed,” “described,” and “the supplied material” occur frequently, but a reader cannot readily determine whether a statement comes from:

• executable source;
• a unit or integration test assertion;
• configuration;
• migration text;
• a secondary review;
• a proposed characterization scenario; or
• an unresolved summary.

This is a significant evidence-quality weakness for an operational document. The corrections should not invent citations, but the document should use a consistent provenance convention or an accompanying evidence map controlled by Atelier. At minimum, each major operational claim should identify its evidence class and whether execution or deployment was observed.

Repetition and presentation

The document repeatedly states that topology, deployment, monitoring, backups, recovery, ownership, and production effectiveness are unknown. Repetition reinforces caution but makes the draft long and less usable. Consolidate the recurring caveats into an opening “confidence and evidence boundary” paragraph and a short final limitations section. Then attach local qualifications only where they materially change interpretation.

The same applies to repeated statements that source risks are not confirmed production defects. A single status vocabulary would be clearer:

• Observed source behavior
• Test expectation, execution not supplied
• Configuration evidence
• Conditional source risk
• Not evidenced
• Contradictory or unresolved evidence

Specific corrections recommended

1. Replace the broad operational-actor list with a distinction between application actors and inferred operational roles.
2. Mark the scanner health endpoint explicitly as source/test-described and not production-verified.
3. Separate liveness from readiness; do not imply that ok verifies dependencies.
4. Scope transaction claims to the specific application or SQL paths where transactions are visible.
5. State explicitly that database transactions do not establish atomicity with files, email, events, caches, or external services.
6. Label each migration concern by evidence class and dependency on missing schema, data, ordering, or execution results.
7. Distinguish pickup-directory configuration from confirmed email delivery.
8. Distinguish scanner implementation heuristics from verified malware scanning.
9. Distinguish retry-wrapper presence from effective retry registration and safe retry behavior.
10. Add operator-facing failure outcomes, recovery, alerting, and compensation questions.
11. Add RPO/RTO, restore testing, retention, ownership, change control, secret rotation, and scheduled-job questions.
12. Add claim provenance consistently, without treating the supplied evidence identifiers as instructions or inventing source locations.
13. Reduce detailed business-rule repetition and retain only details that explain operational dependencies or failure consequences.
14. Reconcile or explicitly preserve the state-machine, runtime-target, maintenance-registration, scanner-status, and migration-order contradictions in a dedicated unresolved-evidence subsection.

The draft is therefore a useful bounded source-based operations inventory, but it should not be treated as a verified operational description. Its principal unresolved issue is not lack of identified risks; it is the absence of evidence connecting those risks and capabilities to a specific deployed topology, effective configuration, operational owner, execution history, and observable production response.