US source intent handy via the U.S. Food & Drug Administration resources and, when helpful for phrasing or readability norms, consult the European Medicines Agency. Your job is to translate that CTD-true core into ACTD packages in which navigation and naming replace XML as the quality controls. Teams that treat eSubmission as a reviewer UX problem—rather than a file transfer problem—ship faster, receive fewer “where does this number come from?” questions, and globalize changes more consistently.

Two consequences follow. First, you need a content-to-container map (which CTD leaf populates which ACTD node) that the whole program can reference. Second, you need build rules that everyone obeys: how to name files, how to title leaves, what bookmark depth to enforce, and how to run a post-pack link crawl to prove links land on captions. With those rules, ACTD portals become predictable—regardless of whether the authority is rigid about filenames or lenient about bundling.

Granularity Decisions: How Many Leaves, What to Bundle, and Where Lifecycle Will Break if You Guess

Granularity is the level at which you split content into discrete, navigable leaves. In eCTD, the backbone and regional guidelines prescribe it; in ACTD, you choose—then live with the consequences. Too coarse, and reviewers scroll endlessly; too fine, and your packaging becomes brittle with many files to track, rename, and re-upload. A practical rule is to match reader intent: make each major table set, figure set, or narrative unit that a reviewer might independently cite its own leaf, and keep appendices that are not read standalone bundled into annex leaves. For clinical, single-study CSRs remain separate leaves; for nonclinical, each pivotal tox report should be a leaf; for CMC, keep specifications, validation summaries, and stability figures as distinct leaves so Module 2 links can land precisely.

Consider future lifecycle. A portability-friendly dossier groups content so that the most frequently updated items (labeling leaflets, country forms, responses-to-queries, stability timepoints, minor spec clarifications) are replaceable without touching unrelated leaves. If you bundle multiple studies or stability protocols into one monolithic PDF, a small change forces a large re-upload and increases the risk of misalignment between old links and new page numbers. Conversely, splitting excessively (e.g., making each CSR appendix a separate file) creates a high-maintenance package and increases portal rejection risk for excessive file counts or sizes.

Document your decision in a one-page Granularity Charter: for each module, list the default leaf types and any country-specific exceptions. Add “update frequency” and “citation frequency” columns to justify splits. When a novel content type appears (e.g., a device IFU for a combination product), update the charter rather than improvising. The charter keeps publishing predictable, allows vendors to deliver to spec, and—most importantly—prevents accidental changes to the reviewer experience between sequences. Treat granularity not as a file-count target but as a risk control for verification speed and lifecycle stability.

File Naming & Leaf-Title Catalogs: Small Strings That Decide Whether Replace Works

Most ACTD portals do not enforce a multi-XML lifecycle like eCTD, but they do care about filenames and title strings. A stray space here (“IR 10 mg” vs “IR 10mg”), a hyphen there, or a title that changes casing across sequences can cause replace operations to fail silently, leaving reviewers with duplicated or orphaned documents. The fix is a leaf-title catalog: a controlled list of canonical titles and corresponding internal filenames used across the entire lifecycle. Each entry should include (1) the human-facing leaf title, (2) the exact ASCII-safe filename (no spaces if the portal dislikes them), (3) the document ID/version, and (4) the module/node placement. When country portals impose mandatory filenames, map from your catalog to portal aliases at ship time via a simple renaming script or sheet—but do not change the internal IDs or title strings in the source PDFs.

Adopt conventions that are readable and sortable. Example: M3-P-5-1_Specifications-IR-10mg_Table-Set.pdf will cluster all specification leaves together and make it obvious what strength is in scope. Reserve short, unambiguous prefixes (M1, M2, M3, etc.), avoid special characters, and prefer single hyphens over mixed punctuation. For multi-part artifacts (e.g., CSR main body and appendices), append a stable suffix (_Main, _AppendixA, _AppendixB) rather than reusing a generic “Part1/Part2” that changes as content grows.

Wrap naming in governance. New leaves cannot be introduced without catalog entries; changed titles require an impact check on hyperlinks, bookmarks, and cover letters. Keep the catalog under version control and store it alongside the evidence map (the list of Module 2 claims and their anchor IDs). Before you package, run a quick diff between the current source directory and the catalog to catch unauthorized titles or filenames. This small ritual prevents an outsized share of “technical rejection” pain and keeps your portal bundles neat, deterministic, and easy to audit.

PDF Hygiene & Navigation: Bookmarks, Named Destinations, and the Hyperlink Manifest That Proves Traceability

In ACTD, your PDF is the interface. Invest in PDF hygiene the way you invest in data integrity: embedded fonts, selectable text (no image-only scans), and consistent page geometry. Then add navigation. At a minimum, provide bookmarks to H2/H3 depth (e.g., major sections and subsections). For any table or figure cited by Module 2, create a caption-level bookmark and a named destination—the stable anchor that hyperlinks can target without changing if page numbers shift. The hyperlinked “click-through” from an overview sentence to the exact proof caption is the single most valuable reviewer convenience you can provide.

Manage links with a hyperlink manifest: a controlled list (spreadsheet or XML/JSON) that maps each Module 2 claim to a destination ID in the underlying Module 3–5 PDFs. Publishing uses the manifest to inject links; QC uses it to verify that every link resolves; and authors use it to avoid free-form linking that breaks when files update. After packaging, run a post-pack link crawl on the final shipment (the actual zip or portal bundle), not on working folders. The crawl should confirm that (1) no links land on cover pages or section headers when a caption exists, (2) all required bookmarks are present, and (3) all linked files are in the shipped set.

Make figures legible at 100% zoom, not just on a poster screen. Use vector exports when possible, keep axis labels readable, and standardize figure fonts and sizes across studies. For clinical curves (KM plots) include numbers at risk; for forest plots include confidence intervals and a clear reference line; for CMC stability charts include slope/interval annotations that match the text. Save figure IDs in captions (e.g., “Fig. EFF-12”) and reuse those IDs in Module 2 sentences and in the hyperlink manifest. This discipline turns your dossier into a self-checking system: if a number moves, the mismatch shows up during link or figure-ID validation long before a reviewer asks.

Portal Behaviors & Packaging Patterns: Size Caps, Folder Rules, Indices, and What to Do When the Gate Is Picky

ASEAN portals vary. Some accept a simple set of folders with relaxed naming; others impose strict patterns, file-size caps, or index sheets. The safe approach is to build portal profiles—one-page guides that capture limits (max file size, accepted extensions, max file count per folder), required folder names, and any index artifacts. Use these profiles to drive your packaging scripts and QC. When files exceed a cap (e.g., a large CSR), split at logical breaks: main body vs appendices, or appendices grouped by type. Avoid splits that break table/figure numbering or named destinations; keep anchors and bookmarks intact across parts by cloning the caption IDs in each split file.

Include a compact manifest index in the submission (even if not required): a single PDF that lists document titles, IDs, and their placement, with a brief “how to verify” note for pivotal claims. In hybrid pathways (paper + electronic), the manifest doubles as a map for assessors and a training aid for new team members. Store gateway evidence with each shipment: upload receipts, checksums or hashes (e.g., SHA-256) of the zipped package, and acknowledgment IDs. If the portal returns machine-readable acknowledgments, archive them with the sequence label; that record will close many “what exactly did you send?” questions during queries.

Be wary of invisible pitfalls. Some gateways silently sanitize filenames (e.g., converting spaces to underscores or truncating long names). Test once on a noncritical package to see how the portal mutates names, and then adjust your catalog or shipping aliases accordingly. If the portal auto-sorts by filename rather than by metadata, pad numeric parts of names (e.g., “01, 02, 03”) to preserve order. Finally, confirm how “replacements” work: does a new upload with the same name overwrite the prior file, or does it sit alongside? Encode that behavior into your lifecycle SOP so you never rely on an assumption about replace semantics.

Localization Logistics: Bilingual PDFs, Transliteration, and Hash Lineage From CTD to ACTD

ACTD markets often require bilingual leaflets and localized Module 1 documents, and some authorities expect transliterated names for companies or sites. Treat localization as a controlled build, not a sidecar. Keep a bilingual glossary for product terms, clinical endpoints, unit conventions, and address formatting (commas, hyphens, digits). Apply consistent decimal separators and date formats. Require that translations remain searchable text with embedded fonts; image-only scans frustrate reviewers and fail accessibility checks. When transliterating names, lock spelling conventions early and propagate them to forms, certificates, and artwork to avoid “identity drift.”

Preserve hash lineage. For every ACTD leaf that originates from a CTD source, compute and archive a hash of the source file. When you localize (add headings, translations, or repaginate), record the relationship: source hash → localized file hash → shipped package hash. This lineage lets you prove that the science is unchanged even though the wrapper is. It also means that when a query arrives about a localized sentence, you can cite the exact CTD anchor ID and hash, demonstrating one-to-one mapping between local text and global evidence.

Signatures and legalizations introduce additional logistics. If a country requires wet signatures on Module 1 items, plan courier time and seal integrity checks; if digital signatures are acceptable, record the certificate ID and trust service provider in a small annex. Ensure that bilingual files use identical structure and page order so reviewers can track sections across languages. Before export, run a terminology sweep to ensure that analysis set names (ITT/FAS/PP/Safety), safety terms, and dosage statements are identical to those used in the CTD core. Consistency across languages is part of your eSubmission quality story.

QC Automation & Metrics: Validators, Link Crawls, Checksums, and the “Do Not Ship” Gates

You don’t need a full XML validator to be rigorous in ACTD. A lightweight QC stack can catch the vast majority of defects before the portal ever sees your files. At minimum, implement: (1) a link crawler that opens the final shipped bundle and verifies that all hyperlinks resolve to caption-level destinations; (2) a bookmark checker that enforces minimum depth (H2/H3 + decisive captions) and flags missing bookmarks; (3) a file linter that checks for embedded fonts, non-searchable pages, and passwords; and (4) a naming diff that compares shipped filenames/titles to the leaf-title catalog. Add a checksum step (SHA-256 for each file and for the final zip) and archive those hashes; this assures chain of custody and simplifies post-submission forensics.

Translate QC into ship/no-ship gates. Examples: (a) Link coverage = 100% for all Module 2 claims; (b) Validator critical errors = 0; (c) Bookmark coverage = 100% for required levels; (d) Embedded fonts = 100%; (e) Catalog compliance = 100% (no rogue titles); (f) Package checksums archived; and (g) Portal profile checks passed (file sizes, counts, allowed extensions). Every failed gate creates an actionable defect (owner, deadline, acceptance criterion). Keep the gate results visible to leadership so “just upload it” pressure meets data instead of opinion.

Measure what matters. Track first-pass acceptance rate (sequences accepted without technical rejections), time-to-acknowledgment, and query rate per 100 pages in ACTD markets. When a sequence is accepted faster or draws fewer queries than average, examine the build: was there better granularity? Cleaner captions? A clearer manifest index? Make those traits your new baseline. Over time, your QC stack and metrics will converge on a predictable, low-friction eSubmission engine that new team members can run with minimal training.

Lifecycle in ACTD: Replace Semantics, “What Changed” Notes, and Recordkeeping for Variations

Post-approval and during assessment, you will push variations, responses-to-queries, and housekeeping fixes. Without a formal XML lifecycle, you must simulate one. First, write a replace policy: a doctrine for when to replace a leaf versus when to add a new leaf. Replacements must keep identical filenames and titles (hence the catalog), and the cover letter or Module 1 “Change History” page should declare the hash of the prior file and the hash of the new file, along with a one-line reason code (e.g., “added zone IVb 6-month pull; no other changes”). New leaves should use the same naming grammar and have cross-references from Module 2 or from the response letter to maintain discoverability.

Second, maintain a What Changed note as a standard artifact. It need only be a page or two, but it should list: (1) leaves affected; (2) exact paragraphs/tables/figures touched; (3) corresponding hyperlinked anchors; and (4) any knock-on updates to Module 1 (e.g., updated leaflet storage statement with copy-deck reference). This note saves reviewers time and reduces back-and-forth over minor edits, especially in portals that do not render diffs. Third, preserve thread continuity by keeping response packs together: your cover letter cites the question verbatim, answers concisely, and points to the anchor; supporting evidence is attached as discrete, named leaves that follow your catalog grammar. Avoid pasting long evidence blocks into letters; keep letters readable and let the links do the evidence work.

Finally, version your operational assets—the leaf-title catalog, hyperlink manifest, granularity charter, and portal profiles—just like you version the dossier. Each shipment should archive the versions used, so when a future team member reconstructs a sequence, they can rebuild it byte-for-byte. This is not bureaucracy; it’s speed insurance. When a regulator asks for the same dossier plus an update in six months, you won’t be guessing how you built it—you’ll be replaying a known-good build with the smallest necessary edits.