You define the submission type (NDA, BLA, ANDA, IND, MAA, or CTA) and select the eCTD standard — 3.2.2, 3.3, or 4.0 — along with target regions. The platform loads the corresponding DTD schema (for 3.x) or HL7 RPS schema (for 4.0) and pre-validates your configuration against the selected agency's published guidance, including FDA's US33 specification and Health Canada's CA22 schema. This upfront binding prevents format drift downstream and ensures every document you ingest is evaluated against the correct structural rules from the start.

Source documents are uploaded via the DNXT web interface or pushed through the REST API from your document management system. The platform extracts metadata — document title, language, author organization, effective date — and maps each file to its correct CTD module and section based on filename conventions, user-defined rules, or an AI-assisted classification layer. PDF technical conformance is checked against FDA's Electronic Submissions Gateway (ESG) requirements: PDF/A compliance, font embedding, bookmarking structure, and file size limits are all flagged before any index is generated.

Every document in the dossier is assigned a lifecycle operation: new for first-time inclusions, replace for revised documents referencing a prior leaf, append for addenda to existing content, or delete to formally withdraw a prior submission leaf. The platform tracks operation history across all prior sequences in the dossier and flags conflicting operation assignments before they reach the index. For eCTD 4.0, each operation generates the appropriate COU (Context of Use) element with the correct status code — a requirement that manual workflows routinely misconfigure.

For eCTD 4.0 submissions, the platform auto-generates RFC 4122-compliant UUIDs for every document, every Context of Use element, and the submission itself — eliminating the most common source of 4.0 validation failures, which is duplicate or malformed UUID values. Simultaneously, SHA-256 checksums are computed for each document file at the time of finalization and embedded in the HL7 RPS manifest. Any post-finalization file modification will invalidate the checksum, creating a tamper-evident record that satisfies agency integrity requirements and your own audit obligations.

Module 1 content is not shared across regions — it is compiled separately for each target jurisdiction. The platform maintains region-specific Module 1 templates: FDA Form 1571/1572 for US IND submissions, FDA 356h for NDA/BLA, Health Canada SC/HC 3011 for CTA applications, and equivalent administrative forms for ICH, SAHPRA, and GCC regions. Regional cover letters, application forms, and administrative documents are populated with dossier metadata and appended to the correct regional sequence without any copy-paste between regional packages. For Health Canada CA22, bilingual (English/French) Module 1 requirements are enforced at the template level.

The platform generates the complete eCTD index — index.xml for 3.x submissions validated against the published DTD, or the HL7 RPS backbone document for 4.0 — with all cross-references, sequence numbers, and leaf attributes resolved. The resulting XML is then run through DNXT's internal validation engine, which applies the same rule sets used by FDA's eSubmitter and EXTEDO's validator: sequence consistency, valid operation chains, required attribute presence, and XML well-formedness. Errors are returned with precise XPath locations and plain-language remediation guidance, not raw schema error dumps.

Once validation passes, the platform assembles the final submission package: a correctly structured directory tree with the index at root, all documents in their CTD module folders, and a delivery manifest. For FDA submissions, packages are formatted for direct upload to ESG or CDER Direct. For Health Canada, the package conforms to the eSubmission gateway format. Each completed package receives a tamper-evident package hash and a signed audit log showing who finalized it, when, and from which IP — satisfying 21 CFR Part 11 electronic signature requirements without any additional tooling.