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

Data Model

Data Model

The system models international waste-shipment notifications and related assessment, movement, financial, organisational and reporting data. The evidence is source-level and partial: declarations, mappings, migrations, views and selected tests are present, but the complete schema, deployed database, ORM configuration and runtime relationships are not established.

Core entities and relationships

A notification or notification application may contain:

• notification identifiers and numbers;
• notification type and trade direction;
• competent authority;
• exporters, importers, producers and owners;
• facilities and treatment sites;
• carriers and transport routes;
• states of export, import and transit;
• customs entry and exit points;
• waste types, waste codes, operation codes, packaging and physical characteristics;
• chemical composition, recovery and disposal information;
• shipments and movements;
• assessments, consent, objections, withdrawals and key dates;
• financial guarantees, payments, refunds and additional charges;
• comments, shared users, audit records, files and annexes.

The evidence describes both export-notification and import-notification structures. Some records use NotificationApplicationId, others use ImportNotificationId, NotificationId or a generic Id; the relationship between these identifiers is not consistently demonstrated.

Facilities may be associated with a notification and one facility may be marked as the actual treatment site. Producers may similarly be marked as the site of export. Some collection logic selects exactly one matching facility or producer with Single, while other evidence permits empty collections or does not show cardinality enforcement. It is therefore unresolved whether the production invariant is “zero or one”, “at least one”, or “exactly one” in every workflow.

Carriers and transit states are ordered collections. Transit states contain country, competent authority, entry point, exit point and ordinal-position data. The domain code is reported to reject duplicate or non-consecutive ordinals and to renumber states after removal, although one validator checks only that the set of positions contains every value from one through the collection size; an unordered sequence such as 2, 1 may therefore pass. The persistence and enforcement of these rules are not fully shown.

Identifiers, values and nullability

Identifiers are predominantly GUIDs, with notification and movement numbers represented separately. Some notification numbers are generated from competent-authority-specific SQL sequences or by selecting the smallest unused positive movement number. The evidence does not establish database uniqueness, concurrency protection or whether all generation paths use the same mechanism.

Many models expose nullable dates, flags, identifiers, collections and monetary values. Null may represent “not supplied”, “not applicable”, “not yet completed” or an absent related record, but these meanings are not consistently documented. Some mappings return null, an empty collection or a default object for missing data; others dereference the value or use Single, SingleAsync or First, which can fail when the expected record is absent or duplicated.

Collection initialization is inconsistent. Some constructors initialize collections to empty lists, while others initialize them only in parameterized constructors or leave them unset. ORM materialisation, model binding or callers may supply the required values, but this is not established.

Status and lifecycle data

The model represents notification, assessment, movement and financial-guarantee statuses. Assessment values include, among others, NotSubmitted, Submitted, NotificationReceived, InAssessment, ReadyToTransmit, Transmitted, DecisionRequiredBy, Consented, ConsentWithdrawn, Objected, Withdrawn, Reassessment, UnderProhibition and FileClosed. Movement values include New, Captured, Submitted, Received, Completed, Rejected, Cancelled and PartiallyRejected. Financial-guarantee values include ApplicationReceived, ApplicationComplete, Approved, Refused, Released and Superseded.

These values establish representable data, not a complete lifecycle. Selected tests and state-machine descriptions support submission, receipt, assessment commencement, transmission, consent, withdrawal, resubmission, prohibition, closure, movement completion and guarantee decisions. However, the evidence contains a material status ambiguity: one state-machine description shows NotificationReceived transitioning to the concrete AwaitingPayment state, while other descriptions refer to the broader Submitted state. The relationship between parent and substate values is unresolved.

Status-history records can contain previous and new status, acting user and timestamp. The evidence does not establish whether every status change creates an immutable history record, whether events and history writes are atomic, or whether status values have stable numeric meanings across migrations and application code.

Dates and temporal values

Date fields include notification receipt, assessment start, commencement, completion, acknowledgement, transmission, decision-required-by, consent validity, withdrawal, objection, file closure, archive, shipment, receipt, recovery, disposal, payment and financial-guarantee decision dates.

Observed rules include:

• some dates cannot be in the future;
• related dates may need to be chronological;
• shipment periods vary according to pre-consent status;
• movement dates must fall within a consent period;
• receipt and completion dates may be checked against shipment or receipt dates;
• decision deadlines may be calculated using working days or calendar days.

The evidence uses DateTime, DateTimeOffset, UTC values, local values and date-only comparisons. It does not establish a consistent timezone or precision policy. Migration scripts also convert some timestamp values to DATE or reduced-precision DATETIMEOFFSET, potentially removing time or offset information; the business effect is unknown.

A recurring contradiction concerns the prenotification-to-shipment limit. Executable-code descriptions commonly report a limit of 60 days, while some messages and user-facing text state 30 days. Another warning refers to three working days, while a separate consent-expiry description refers to three or four working days. The effective rules are unresolved.

Quantities, units and financial values

Shipments and movements contain quantities and units including kilograms, tonnes, litres and cubic metres. The evidence supports conversions between compatible weight units and between compatible volume units, with some precision and rounding rules. Other paths use factors such as 1,000 or threshold-based corrections, but the complete conversion and dimensional rules are not available.

Some tests and validators describe quantity tolerances using 50% and 150% bounds. Other code rejects partial-rejection quantities equal to or greater than the actual quantity, while accompanying wording says only that the rejected quantity must not exceed the actual quantity. Zero, negative values, boundary precision and mixed-unit behaviour are not uniformly established.

Financial data includes charges, payments, refunds, additional charges, cover amounts, permitted active loads and potential refunds. Payment completion is calculated from transactions and billable amounts in selected paths. A credit is generally treated as a payment and a debit as a refund, but another mapper requires credit to be populated and debit absent. The treatment of conflicting, zero or negative credit and debit values is unresolved.

Waste and operation data

Waste data represents EWC, Basel/OECD, Y, H, HP, UN class, UN number, national, customs and other code categories. It also represents not-applicable, not-listed and custom-code states. Some handlers give persisted codes precedence over custom or not-applicable representations; other paths use different precedence. Code-type checks, duplicate detection and collection validation are not uniform across the supplied material.

Operation codes are associated with recovery, disposal, interim and other processing categories. The evidence supports rules against mixing recovery and disposal codes and requires at least one code in some workflows. The complete code catalogue, metadata, notification-type compatibility rules and persistence constraints are not supplied.

Chemical-composition, waste-component, wood, energy, process-of-generation and additional-information fields are represented through several related models. Descriptions and further-information fields have reported length limits, and annex flags can alter whether details are permitted or required. The complete conditional-validation matrix and relationship between string-based input models and decimal-based domain models are unknown.

Files and annexes

Files contain identifiers, names, types and binary content. Annex collections may contain process-of-generation, technology-employed and waste-composition files. An absent annex may be represented by an object with a null file identifier rather than by a null object. Replacement and deletion operations may create or remove file associations, but file storage, cleanup, retention, access control, scanning and transaction coordination are not established.

Document generation uses notification, movement, facility, carrier, customs-office, waste and annex data to populate OpenXML templates. Main-document and annex output depends on block order, ordinal values, collection cardinality and template fields. Missing or duplicated fields, absent treatment sites, empty collections or unexpected enum values may cause exceptions. Successful rendering, storage, transmission and later retrieval are not evidenced.

Persistence and integrity

Entity Framework-style mappings configure required properties, maximum lengths, decimal precision, foreign keys, row-version columns, junction tables and database-generated identifiers. Raw SQL and stored procedures are also used for progress, reporting, archiving, deletion, pricing and migration operations.

These mappings and scripts demonstrate intended persistence structure, but not the deployed schema or enforcement. The evidence does not establish all uniqueness constraints, cascade rules, cardinalities, row-level access controls, concurrency handling, transaction scope or migration state. Several migrations are potentially destructive or order-dependent, including dropped and recreated shipment fields, relationship changes, lookup replacement, duplicate cleanup, data backfills, truncation and nullable-to-non-nullable conversions. Some migration files were unavailable or unreadable, and execution results were not supplied.

Selected operations use explicit transactions and roll back on exceptions, including some archive, movement and bulk-processing paths. Other multi-step operations perform separate saves or combine database changes with file storage and events without an evidenced shared transaction. Partial persistence, orphaned files, incomplete audit records or inconsistent related entities are therefore possible but not confirmed.

Data-model failure paths

Potential failure paths supported by the evidence include:

• missing or duplicate related records causing Single, SingleAsync or First failures;
• null collections or nested values causing mapping, validation or view-rendering exceptions;
• malformed dates, numbers, GUIDs, JSON or enum values causing conversion exceptions;
• conflicting receipt, rejection, partial-rejection or completion flags producing precedence-dependent results;
• inconsistent units or precision causing conversion errors or loss of precision;
• missing migration matches leaving nulls before a later non-null constraint;
• duplicate logical records where database uniqueness is not shown;
• partial database updates when later saves, event dispatch or file operations fail.

These paths are source-level or evidence-level risks. The supplied material does not establish their reachability, frequency, user-visible response or occurrence in production.

Content quality review

Advisory; not approval. Review status: advisory.

Overall assessment

The draft is broadly relevant to data.md and reflects the evidence’s central limitation: it is a source-level, partial description rather than a verified deployed schema or complete domain model. It is appropriately cautious in many places and preserves several important uncertainties. However, it is much broader than a data-model document. It includes substantial application-architecture, security, operational, document-generation, migration, and runtime-failure material that would be more useful in separate sections or documents. The breadth also makes it difficult to distinguish actual model facts from inferred workflow behavior and repeated evidence summaries.

The draft should not be treated as complete or verified. Its main weakness is not a single obvious factual error, but the risk that readers will treat the long inventory as authoritative despite the evidence being fragmented, sometimes contradictory, and often derived from secondary analyses.

Relevance and scope

The core data-model content is relevant:

• entities such as notifications, assessments, movements, facilities, producers, carriers, routes, waste classifications, guarantees, payments, files, comments and audit records;
• identifiers, collections, nullable values and date types;
• status and lifecycle representations;
• quantities, units, financial values and waste-code structures;
• mappings, migrations, foreign keys and persistence concerns.

The sections on document generation, reporting, authorization, middleware, email, virus scanning, deployment, maintenance mode, migration tooling and operational recovery are only indirectly relevant. They may be useful as data-model consequences or integrity risks, but they currently occupy a large proportion of the document. Consider separating them into architecture, security, operations, document processing and migration assessments, leaving data.md focused on:

1. logical entities and identifiers;
2. relationships and cardinality;
3. value semantics and nullability;
4. lifecycle/status representation;
5. temporal, quantity and monetary rules;
6. persistence constraints;
7. known contradictions and unresolved model questions.

The introduction should state explicitly that the document is a logical model inferred from declarations and selected persistence evidence, not a schema catalogue or database design specification.

Claims needing correction or tighter qualification

Notification and movement numbering

This sentence risks conflating two different numbering mechanisms:

> “Some notification numbers are generated from competent-authority-specific SQL sequences or by selecting the smallest unused positive movement number.”

The evidence supports authority-specific sequence generation for notification numbers and smallest-unused-positive-number logic for movement numbers. It should say that explicitly, for example:

> “Notification numbers are reported to use competent-authority-specific SQL sequences in some paths. Movement numbers are separately reported to use the smallest unused positive number within a notification. The evidence does not establish that these mechanisms are universal, concurrency-safe, or used consistently across all paths.”

This distinction is important to the model and to any later discussion of uniqueness.

Identifier relationships

The draft correctly notes inconsistent names such as NotificationApplicationId, ImportNotificationId, NotificationId and Id. It should go further by distinguishing:

• same-name or similarly named fields;
• demonstrated foreign keys;
• application-level lookup relationships;
• inferred relationships from mappings or handlers.

At present, the wording could leave the impression that the identifiers are merely inconsistently named, when some evidence indicates separate Notification and ImportNotification schemas and tables. A correction should state that identifiers may refer to different aggregates or schema domains, and that a relationship must not be inferred from naming alone.

Transit-state ordering

The statement that domain code rejects duplicate or non-consecutive ordinals is supported in several paths, but it should not be generalized to every transit-state workflow. The evidence also reports:

• collection-level checks for uniqueness and consecutiveness;
• validation that checks set membership rather than ascending order;
• domain methods that normalize or retain invalid positions;
• update paths that do not repeat constructor-level country and identifier checks.

The draft should distinguish “consecutive as a set” from “ascending in list order.” It currently does mention that 2, 1 may pass, but the surrounding wording could still imply a stronger universal invariant than the evidence supports.

Suggested wording:

> “Several domain and validator paths require unique positions forming the set 1 through n. At least one validator does not require the collection to be ordered, so [2,1] may satisfy the rule. Update and persistence enforcement are not consistently demonstrated.”

Facility and producer cardinality

The draft appropriately identifies unresolved cardinality, but the alternatives could be presented more systematically. The evidence supports different local rules, including:

• exactly one actual treatment site in selected validators and document paths;
• Single/SingleOrDefault assumptions in mappings and rendering;
• cases where removal of the sole marked site is permitted;
• collections that may be empty during draft construction;
• producer and facility flags that are not always initialized or recomputed.

This is more than an unresolved choice between zero-or-one and exactly-one. The document should identify the invariant as workflow-dependent and not unified across construction, validation, persistence, and rendering.

Status values

The status section is useful, but it combines values from different concepts: assessment state, movement state, guarantee state, decision state, and possibly parent/substate hierarchies. The draft says this generally, but the status lists would be clearer if explicitly grouped by model or aggregate.

For example, NotificationReceived, AwaitingPayment, Submitted, InAssessment and FileClosed should not appear as if they are all members of one flat status enum. The draft should label them as “reported assessment/status vocabulary” and distinguish concrete substates from parent states.

The sentence:

> “These values establish representable data, not a complete lifecycle.”

is sound and should be retained, but it would be stronger if followed by a warning that numeric values and names are not necessarily stable across migrations, reporting procedures and application enums.

Date and time policy

The temporal section is well supported and appropriately cautious. One refinement is needed: it should distinguish date-only business fields from timestamps rather than listing all temporal values together. The evidence includes DATE, DATETIME, DATETIMEOFFSET, UTC values, local values and date components. These may represent different semantics, not merely inconsistent implementation.

A more precise correction would identify three unresolved policies:

• whether a field represents a calendar date or an instant;
• which timezone is authoritative;
• whether precision and offset are intentionally discarded during migration or mapping.

The draft’s phrase “potentially removing time or offset information; the business effect is unknown” is supported, but should not imply that every conversion is destructive or harmful.

Thirty- versus sixty-day rules

The contradiction is correctly identified and is one of the strongest parts of the draft. It should distinguish at least three potentially different rules:

• prenotification-to-shipment maximum;
• movement-date range from the current date;
• user-facing warning period.

The supplied evidence contains both 30- and 60-day rules in different contexts. The draft currently presents the contradiction mainly as one rule conflict. It should state that some apparent disagreement may result from different operations or notification types, although the authoritative mapping is not available.

Quantity and unit handling

The quantity section accurately preserves uncertainty, but it should avoid implying that all conversions are dimensional conversions supported by the same component. The evidence includes:

• compatible weight conversions;
• compatible volume conversions;
• reporting conversions using factors such as 1,000;
• migration corrections and heuristics;
• precision and rounding rules that vary by unit;
• paths where units are treated by numeric IDs.

These should be separated into domain conversion, reporting conversion and migration transformation. A factor of 1,000 in a report or migration must not be described as evidence of a general domain conversion rule.

Financial data

The draft correctly reports conflicting credit/debit mapping conventions. It should also state more directly that the evidence does not establish currency, sign conventions, accounting treatment, or whether a debit is always a refund. The presence of MONEY, decimal precision, charges and refunds does not establish a complete monetary model.

The phrase:

> “A credit is generally treated as a payment and a debit as a refund”

is reasonable as a summary, but “generally” is still potentially too broad. Better:

> “Several mapping paths classify a populated credit as a payment and otherwise treat the record as a refund or debit. Another mapper requires credit to be populated and debit absent. Mixed, zero, null and negative values are not consistently defined.”

Unsupported or under-supported claims

Most claims are hedged, but some should be softened:

• “The model represents…” should be changed to “The supplied declarations represent…” where no persistence or runtime use is shown.
• “The evidence supports rules against mixing recovery and disposal codes” should specify whether this is domain validation, handler validation, or test expectation.
• “Document generation uses…” should distinguish observed block-generation code from successful document generation.
• “Selected operations use explicit transactions and roll back…” should identify the specific operations and avoid implying that all changes within the described operation are covered by the same transaction.
• “Partial persistence, orphaned files… are therefore possible” is acceptable, but should be marked as a consequence of missing transaction evidence rather than a demonstrated reachable path.
• “A material status ambiguity” is justified, but it should state whether the ambiguity is between parent and child status representations, not merely different names.

The document should also avoid statements that sound like confirmed production risks, such as “may cause exceptions” or “can fail,” unless the relevant call path is shown. Where the evidence only shows that an operation uses Single, the precise claim is that failure is possible if the cardinality precondition is violated.

Missing or insufficiently developed model behaviours

Despite its length, the draft still does not provide a clear logical relationship model. Important missing behaviours include:

Relationship direction and ownership

The draft lists parties, facilities, users and shared users, but does not consistently explain:

• whether a notification has one owner or multiple owners;
• whether shared users are notification-level or application-level;
• whether producer, exporter, importer and owner are distinct roles or can refer to the same organization;
• whether facilities and producers are notification-owned snapshots or reusable organizations;
• whether carriers are notification-specific or drawn from an address book;
• whether a movement belongs directly to a notification, shipment, or both.

These are central data-model questions and should be stated explicitly as unresolved.

Deletion, archival and retention state

Deletion and archiving are discussed mainly as operational risks. The data model should identify whether the evidence distinguishes:

• physical deletion;
• soft deletion;
• cancellation;
• archival;
• file closure;
• withdrawal;
• prohibition;
• retention or anonymization.

The draft mentions these concepts but does not clearly explain that their relationship is unresolved.

Audit and history semantics

The status-history discussion is useful, but the model section should also cover:

• movement audit versus notification status history versus assessment history;
• whether audit records are append-only;
• whether history records are snapshots or events;
• whether timestamps are event time, database time or application time;
• whether user identity is stored as string, GUID or foreign key;
• whether history is retained through deletion or archival.

The evidence repeatedly raises these distinctions, and they are important to a data model.

Enum and lookup persistence

The draft notes numeric-status uncertainty but does not systematically cover lookup governance:

• whether enum numeric values are persisted;
• whether lookup IDs are stable across migrations;
• whether names or codes are used as external keys;
• whether lookup rows can be deactivated;
• whether unknown values map to zero, null or exceptions;
• whether reporting procedures use different status/code mappings from the application.

This is a significant evidence gap.

Concurrency and uniqueness

The draft says uniqueness and concurrency are not established, but the model section would benefit from identifying the specific logical uniqueness candidates:

• notification number;
• movement number within notification;
• one actual treatment site;
• one site of export;
• one route per notification;
• one annex collection per notification;
• one receipt or completed receipt per movement;
• one shared-user association per notification and user;
• one code per notification/code type;
• one approved financial guarantee.

These should be described as candidate invariants, not asserted constraints.

Contradictions the draft should surface more explicitly

The draft captures several contradictions, but some important ones from the evidence are not prominent enough:

1. Receipt clearing after rejection. The draft correctly records conflicting evidence about whether rejection clears receipt data. This should be elevated because it affects movement-state integrity and subsequent completion.

2. External versus internal receipt/completion parity. The draft identifies differing file requirements and date checks, but should explicitly state that the policy may intentionally differ or may be an implementation divergence. It should not imply that internal completion is the authoritative rule.

3. Payment handler return values. Evidence reports payment and refund handlers returning different Boolean values, and some operations return success without inspecting service results. This is relevant to the model’s operation-result semantics and should be included more clearly.

4. Import versus export stored procedures. The evidence reports different handling of conflicting movement outcome flags and transaction/error behavior. This is a significant cross-model inconsistency not fully surfaced in the draft.

5. Schema-specific notification dates. The evidence explicitly warns that [Notification].[NotificationDates] and [ImportNotification].[NotificationDates] are distinct tables. The draft should make this a prominent correction to any implied unified date model.

6. Assessment and guarantee identifier relationships. Some evidence uses assessment identifiers, notification application identifiers and notification identifiers in different places. The draft notes this generally but should identify the exact unresolved relationship between assessment, notification, guarantee and date records.

7. Migration state. The draft says deployed schema and migration state are unknown, but it could more clearly warn that historical migration scripts cannot be combined into a final schema merely by listing all observed operations. Later migrations, unavailable files, corrective migrations and deployment order may change the apparent model.

Evidence gaps and provenance

The supplied evidence is unusually repetitive and contains many second-opinion summaries. The draft appears to synthesize them, but it does not identify which statements are:

• directly observed source;
• test assertion;
• test setup or fixture;
• migration text;
• secondary analysis;
• characterization scenario;
• unresolved reviewer interpretation.

That distinction is essential. For example, a test fixture containing a relationship does not establish a database foreign key; a resource string does not establish validation; a request contract does not establish a handler; and a migration script does not establish deployment.

The draft should add a short evidence-strength convention near the beginning, such as:

> “Declarations show representable structure. Tests show asserted expectations under their fixtures. Mappings and migrations show intended or attempted persistence structure. No category alone proves deployed runtime behavior.”

The absence of exact citations is also a practical weakness. The evidence payload contains source-section identifiers, but the review should not invent or reproduce identifiers unless the processing system requires them. At minimum, the draft should identify the relevant artifact class and symbol or migration name where available. Without this, readers cannot efficiently verify claims or resolve contradictions.

Specific corrections recommended

1. Reframe the introduction as a logical, evidence-bounded model rather than a complete data model.
2. Separate notification numbering from movement-number allocation.
3. Group status values by aggregate or state machine, and distinguish parent states from concrete substates.
4. Mark every relationship as one of: declared, mapped, foreign-keyed, observed through handler logic, or inferred.
5. Replace broad claims about “the model” with “the supplied models,” “selected mappings,” or “reported tests.”
6. Split date rules into calendar-date semantics, timestamp semantics, timezone policy and business-rule contradictions.
7. Separate domain unit conversion from reporting and migration transformations.
8. Add candidate uniqueness/cardinality invariants as unresolved questions.
9. Add a clear section on deletion, cancellation, archival, withdrawal and file-closure semantics.
10. Add a clearer distinction between assessment history, movement audit, status history and financial-guarantee history.
11. Identify the separate Notification and ImportNotification schemas and date tables explicitly.
12. State that no final deployed schema can be reconstructed from the supplied migration excerpts.
13. Reduce or relocate detailed architecture, security, document-generation and operational material.
14. Add an evidence-strength note distinguishing declarations, tests, mappings, migrations and summaries.
15. Where a possible exception is mentioned, state the required precondition for failure rather than describing the exception as an unconditional behavior.

Unresolved questions that should remain in the document

• Are NotificationId, NotificationApplicationId and ImportNotificationId identifiers for the same aggregate, different aggregates, or different schema generations?
• Which notification and movement numbering mechanisms are authoritative, and what database constraints protect them under concurrency?
• Is there exactly one route, annex collection, actual treatment site, site of export, receipt and approved guarantee per relevant parent?
• Are notification, assessment, movement, guarantee and decision statuses flat enums, hierarchical states, or separate correlated values?
• Which status and date values are persisted by application

, database migrations, reporting procedures, or external integrations, and are their numeric values stable across versions?

• Are notification dates in the Notification and ImportNotification schemas intentionally separate, and which date source is authoritative for export and import workflows?
• What are the exact meanings of null, empty collections, default objects, zero-valued identifiers and default dates for each major entity?
• Which fields are user-entered values, calculated values, imported values, authoritative references or presentation-only projections?
• Are facilities, producers, carriers and organisations stored as notification-specific snapshots, shared address-book records, reusable master data, or combinations of these?
• Does a movement belong directly to a notification, to a shipment, or to both, and which relationship is authoritative when identifiers disagree?
• Are movement numbers unique within a notification, globally unique, or only expected to be unique by application convention?
• Are shipment, receipt, rejection, partial-rejection and completion records mutually exclusive, sequential, or allowed to coexist?
• Does rejection or partial rejection clear receipt data, preserve it, or create a separate outcome that takes precedence only for display?
• Can a partially rejected movement be completed without a receipt, and if not, where is that invariant enforced?
• Are external and internal receipt and completion paths intentionally different in their file, quantity, date and authorization requirements?
• Does every status transition create an immutable history record, and are the transition and history writes part of one transaction?
• Are audit records, status histories and domain events separate persistence concepts, and how are they related?
• Are audit and history records retained through cancellation, archival, physical deletion or anonymisation?
• Does archive processing remove, redact, relocate or merely mark records, and how does it interact with deletion, file closure, withdrawal and cancellation?
• Are files first-class persisted entities with foreign keys, or are file identifiers merely associations to an external store?
• What happens to files when an association is replaced, deleted, archived or rolled back?
• Are uploaded files scanned before storage, after storage, or through a separate asynchronous process, and what is the authoritative scan result?
• Which unit conversions are domain rules, which are reporting transformations and which are migration repairs?
• Are quantities dimensionally validated so that weight and volume cannot be mixed?
• What are the authoritative precision, rounding, sign and zero-value rules for quantities, payments, refunds, charges and guarantees?
• Do credit and debit fields represent mutually exclusive transaction types, and can either field be zero, negative or null?
• Is a debit always a refund, or can it represent another accounting event?
• What is the currency and monetary scale for each financial field, and are values stored as MONEY, decimal values or display-formatted strings?
• Are waste codes and operation codes governed by stable lookup identifiers, text codes, enum values or combinations of these?
• Can lookup values be deactivated, renamed or replaced while preserving historical meaning?
• What is the intended treatment of unknown, obsolete, not-listed, not-applicable, custom and conflicting code representations?
• Are code collections unique by notification, waste type, code family, code type or another composite key?
• Which constraints are actually present in the deployed database, rather than only in mappings or migration scripts?
• Which migrations have executed successfully, and what is the resulting schema and data state in each environment?
• Were destructive migrations preceded by backups, row-count checks, reconciliation, rollback preparation or post-deployment validation?
• Do later migrations correct or supersede the apparent problems in earlier scripts, and are unavailable or unreadable scripts material to the final model?
• Are database row-version values used for optimistic concurrency, and what response is produced when a conflict occurs?
• Which application, database, report-cache and file-store operations share a transaction, if any?
• Are events published transactionally, through an outbox, synchronously after save, or not at all in production?
• Which handlers, repositories, controllers, filters and dependency registrations connect the separately described export, import, movement, API, document, scanning and reporting components?
• Which reported model relationships are supported by direct foreign keys, and which are only inferred from names, joins or handler lookups?
• Which reported tests have actually executed successfully, and do they run against the same schema, configuration and code version as the described application?
• Which apparent defects are reachable with ordinary model binding and valid persisted data, rather than only through reflection, malformed fixtures, direct construction or tampered input?
• Which messages, resource strings and displayed states are authoritative business requirements, and which are stale, unused or presentation-only artifacts?

Closing assessment

The draft has a strong evidence-bounded posture and identifies many of the material model uncertainties. Its main corrective need is structural: the reader should be able to tell, for each statement, whether it describes a declared field, a mapped relationship, a database object, an observed handler path, a test expectation, or an inference. Without that distinction, the document risks converting a large volume of partial observations into an apparent canonical schema.

The recommended corrections do not establish that the draft contains production defects, nor do they resolve the competing rules. They should be treated as review actions and questions for further source, schema, migration-execution and runtime examination.