The engine traverses the source dossier's directory tree and parses every XML manifest, index file, and leaf document to construct an internal document graph — a complete map of every file, its module location, its document type, and every reference it makes to other documents. This step identifies all hyperlink targets, STF node references, and TOC entries before any transformation begins, ensuring the clone operation has a complete picture of the dossier's internal dependency structure. Typical indexing of a 4,000-node eCTD dossier completes in under 90 seconds.

Using the document graph, the engine replicates the complete folder hierarchy and document set into a new submission context — applying the target application number, submission type, and sequence number to the structural scaffold. File references in the index manifest are remapped to the new root path, and any submission-context metadata (applicant, drug product, application identifier) is updated from the clone configuration supplied by the user. Documents that differ by submission type — for instance, Module 1 regional cover materials — are flagged for replacement rather than direct copy, so the publisher can immediately see what content requires human attention versus what is structurally equivalent.

Every hyperlink within PDF documents, XML files, and HTML bookmarks is resolved against the document graph and rewritten to point to the correct target in the new dossier. The engine distinguishes between three types of references: internal links (document A citing document B within the same dossier), external links (citations to published literature, which are preserved as-is), and anchor links (in-document bookmarks, which are recalculated based on the destination document's content). This is not a find-and-replace operation on file paths — the engine resolves link targets semantically, using document identifiers, so a link to "the primary clinical study report" finds the correct document in the new dossier even if its path has changed. Broken link detection runs simultaneously, flagging any reference that cannot be resolved so a publisher can act on it before the dossier reaches the gateway.

For dossiers migrating from eCTD 3.x to eCTD 4.0, the engine converts the legacy node-based addressing scheme — where documents are identified by their position in the CTD folder hierarchy — to the UUID-based leaf-document addressing required by eCTD 4.0 and the FHIR-aligned ICH M8 specification. A globally unique identifier is generated for each leaf document, and a SHA-256 cryptographic checksum is computed from the document's binary content and embedded in the manifest. This checksum serves as the agency's integrity verification mechanism: if a document is altered after the manifest is generated, the checksum will fail, and the submission will be rejected. Because the checksum is computed from actual content rather than metadata, it also catches encoding errors or file corruption that might otherwise go undetected.

Study Tagging Files (STFs) in eCTD 3.x use a flat referencing model tied to the node hierarchy. In eCTD 4.0, the equivalent mechanism is the node extension, which references leaf documents by UUID and supports richer study metadata attributes required by FDA's CDER and CBER review divisions. The clone engine parses each STF, maps its study references to the corresponding UUID-addressed leaf documents in the new dossier, and generates a compliant node extension XML file. Study metadata attributes — study ID, study type, therapeutic area codes — are preserved from the source and validated against the target submission's drug product and indication context. Where a study reference cannot be automatically resolved (for example, a study document that was removed from scope in the new submission), the engine generates a resolver log entry for publisher review.

The TOC is not simply copied — it is regenerated from the new dossier's document set, applying the regional TOC template appropriate to the target agency (FDA, EMA, PMDA, Health Canada, or other ICH regions). Regional rules govern which modules are required, which headings are mandatory, what document naming conventions apply at each TOC level, and how placeholder sections are represented when content is not included in the current submission. The engine applies these rules against the document graph to produce a TOC that is structurally correct for the target submission context before any human opens the dossier. For eCTD 4.0 targets, the TOC is expressed as an XML composition resource aligned to the ICH M8 implementation guide rather than the legacy HTML/XML format.

Before the cloned dossier is released to the publishing team, the engine runs a full validation sweep using the same rule set applied at submission gateway check — covering FDA's eCTD technical conformance guide, EMA's eCTD specification, PMDA regional requirements, and ICH M8 for eCTD 4.0 targets. The validation checks structural integrity (all referenced files exist at their declared paths), hyperlink resolution (every internal link resolves to a real document and anchor), checksum correctness (SHA-256 values match current file content), STF/node-extension validity, and TOC completeness against the regional rule set. The result is a machine-generated validation report that functions as a pre-submission audit trail — the team knows the dossier is structurally sound before a single content edit begins.