When documents are uploaded or authored within DNXT, the platform ingests them into a structured dossier object — not as flat files in a folder, but as typed nodes in a graph-like dossier model. Each document is identified by its eCTD section reference (e.g., m2.7.4, m5.3.5.1), its document type, lifecycle state, and content hash. This canonical index is the single authoritative record from which all regional variants are derived. Nothing downstream touches source files directly — every operation is a read from this indexed model.

The user declares which regions are in scope for a submission event — for example, US FDA + Health Canada + GCC. This declaration triggers the compliance engine to load the pre-built regional specification profiles for each selected region. Critically, these specification profiles — TOC template, Module 1 document requirements, required metadata fields, validation rule sets, and sequence numbering conventions — are maintained by DNXT and versioned against each agency's published technical standards. There is no manual configuration by the customer. Selecting "Health Canada" means the CA22 eCTD specification is applied automatically, including its unique Module 1.2 regional administrative information requirements.

The engine resolves the canonical dossier index against each regional TOC template and generates region-specific table of contents structures. For regions like ICH, this follows the standard eCTD module hierarchy. For Health Canada, the engine applies the CA22-specific TOC including the regional Module 1 envelope. For SAHPRA and GCC, which have their own Module 1 structures and section ordering conventions, the engine applies those templates without the user needing to understand the underlying difference. Each generated TOC is expressed in the region's required XML format — leaf.xml, backbone files, or eCTD envelope files — and is validated against the region's published schema before it is ever presented to the user.

Module 1 is the most variable part of any multi-regional submission — what FDA requires in section 1.2 is different from what Health Canada expects in its administrative information package, which differs again from SAHPRA's cover letter and CTD-specific cover page requirements. DNXT maintains a Module 1 document schema for each region that specifies exactly which documents are required, which are optional, what the accepted file formats are, and what the metadata must contain. The engine identifies which Module 1 documents the user has provided, maps them to region-specific slots, and flags any gaps before the submission is packaged. Document authoring templates for region-specific Module 1 forms (e.g., FDA Form 356h, Health Canada HC/SC 3011) are included in the platform.

Each region requires metadata to be encoded differently in the submission XML — field names, controlled vocabulary values, date formats, and required attributes vary across agencies. The compliance engine applies each region's metadata schema to the canonical document index and generates the correct metadata output for each regional package. For FDA submissions, this means conformance with the FDA eCTD specification and CDER/CBER metadata requirements. For Health Canada, the CA22 metadata schema with its specific product and company identifier conventions. For GCC, the Gulf Central Committee's eCTD metadata requirements are applied. Metadata is never manually transcribed — it flows from the canonical dossier object through the regional schema filter and into the submission package automatically.

Lifecycle operations — new, replace, append, delete — have different rules per region. FDA eCTD has specific rules about when a replace operation is valid versus when a delete-and-new sequence is required. Health Canada has its own lifecycle guidance that diverges in edge cases. The compliance engine enforces these rules at the operation layer: if a user attempts an operation that is invalid under a region's lifecycle rules, the system blocks the operation and explains why. This means lifecycle errors are caught before packaging, not discovered during agency technical screening — which is typically the most costly point to discover them, often triggering a reject and resubmit cycle that delays review by weeks or months.

The final output is five independently validated, agency-ready submission packages — each with its own correct folder structure, file naming conventions, backbone XML, leaf XML, Module 1 documents, and metadata. Each package passes an automated pre-submission validation run against the region's published validation criteria (e.g., FDA ECTD Validation Criteria version 6.1, Health Canada CA22 technical specifications) before being made available for download or direct gateway submission. A submission readiness report is generated for each region showing validation pass/fail status, rule coverage, and any advisory warnings. All five packages are generated from the same canonical source and are guaranteed internally consistent — if a document is version 3.1 in the FDA package, it is version 3.1 in every other regional package.