Filing one product into many markets is the defining logistics problem of global regulatory operations. The science is the same molecule everywhere, but the dossier is not: the EU wants sections the US does not, Japan requires local content nobody else asks for, and a Gulf submission inherits most of the ICH backbone while diverging in Module 1 entirely. Most teams manage this divergence in the least reliable place possible — copied spreadsheets and tribal memory of “what we did for the last one.”
DnXT Planner models the problem directly with composable submission templates: a global core that captures what is common, market variants that inherit it and diverge deliberately, and a variance ledger that makes every difference visible and intentional.
A Template Is a Section List, Not a Document
First, a definitional point. In DnXT, a submission template is an editable list of eCTD sections — the planned shape of a dossier — not a stack of document boilerplate. The template says “this submission type, for this market, includes 3.2.P.8.1, 3.2.P.8.2 and 3.2.P.8.3”; it does not pretend to write your stability summary for you. That distinction keeps templates honest: they encode structural knowledge (what a complete dossier of this type looks like), which is durable, rather than content, which is program-specific.
Because the section catalog is derived from the same eCTD structure DnXT Publisher actually publishes against — the real ICH backbone merged with regional Module 1 structures — a template is never out of sync with what the publishing engine can build. Planning and publishing speak the same structural language.
The Core-and-Variant Model
The composition rules are deliberately simple:
- The global core holds sections common to all markets — the shared ICH spine of your submission type
- Each market variant inherits the core automatically and completely
- Variants add local sections — regional Module 1 content, market-specific requirements
- Variants exclude core sections that do not apply — an explicit, recorded exclusion, not a silent omission
The effective table of contents for any market resolves live as: (core ∪ local additions) − exclusions. It is set arithmetic, and that is the point — the rule is simple enough that anyone on the team can predict what a variant contains without opening it.
Live Propagation: Edit the Core Once
The payoff of real inheritance — as opposed to copy-paste templating — shows up the first time the core changes. Suppose your CMC team decides all markets now need a dedicated elemental impurities section. In a copied-spreadsheet world, that change must be re-applied to every market file, and it will be missed in at least one.
In DnXT, you add the section to the global core once, and every variant inherits the change immediately — except any variant that has explicitly excluded it, which keeps its recorded exclusion. Propagation is live, and exclusions survive core edits because they are first-class decisions, not divergent copies. The inheritance model means there is exactly one place where “what all our dossiers share” is defined.
The Variance Ledger: Divergence Made Visible
The question global regulatory leads actually ask is not “what is in the Japan dossier?” — it is “how does Japan differ from everyone else, and why?” The variance ledger answers it directly: a matrix of sections × markets showing, for every section, which markets include it from core, which added it locally, and which excluded it.
This view earns its keep in three situations:
- Planning a new market — start from the variant closest to the new market’s requirements and see precisely what needs to change
- Defending consistency — when an agency or an internal auditor asks why a section present in one market is absent in another, the exclusion is on record as a decision, with the variant that made it
- Template governance — when the ledger shows the same “local” section added independently by four variants, that section probably belongs in the core; the ledger surfaces the refactor
From Template to Living Submission
A template becomes real work when you apply it to a submission: the resolved section list seeds the submission’s planned table of contents, and from there the operational machinery takes over — a completeness banner tracks how much of the planned structure has content (“32/115 sections · 28%”), sections get owners and dates, and the plan connects to the document-level tracking grid where authoring, review, QC and publishing status live per document.
Recommended-section intelligence assists at this stage too: given the submission type, the platform suggests sections typically included, with an AI ranking layer that degrades gracefully to deterministic rules — the system stays fully functional with AI turned off, which is a design principle across the platform, not an accident.
Why Not Just Use the Publishing Tool’s Structure?
A fair question — every eCTD publishing tool has a folder tree. The answer is timing and audience. Publishing structure exists once documents exist; template planning happens months earlier, when the conversation is “what will this filing require in each market and who has to produce it?” Doing that planning in the publishing tool means doing it document-by-document, too late to drive resourcing. Doing it in spreadsheets means divorcing it from the structure that will eventually be published. The template layer sits deliberately between: structural enough to be correct, early enough to be useful. For the broader picture of how planning, tracking and publishing connect in DnXT, see the platform overview — and for the underlying dossier mechanics, our eCTD guide.
Frequently Asked Questions
Can a variant override a core section rather than exclude it?
A variant’s relationship to a core section is include (default) or exclude. Market-specific structural needs are modeled as local additions, which keeps the arithmetic — and the audit story — unambiguous.
What happens to in-flight submissions when a template changes?
Templates seed submissions at apply time. An in-flight submission keeps its planned structure; you can re-apply or reconcile deliberately rather than having live plans mutate underneath the team.
Does this support non-eCTD markets?
The section catalog is eCTD-derived, which covers the major markets and formats DnXT publishes. Markets with divergent formats are typically modeled as variants with heavier local additions.
See Your Portfolio’s Shape in One Matrix
If your multi-market planning currently lives in copied spreadsheets, the variance ledger alone is worth a look. Book a demo and we will build a core-and-variant template for one of your real submission types, live.
