eCTD Lifecycle Management: Sequences, Amendments, and Version Control

An eCTD is not a single submission. It is a living dossier that evolves over the lifetime of a drug application. Amendments, supplements, annual reports, and responses to questions can change what a reviewer sees without erasing what was previously submitted.

This guide is for regulatory operations teams preparing a follow-up submission or taking over an existing dossier. Its worked history uses ICH eCTD v3.2.2. The later v4.0 section explains why the same leaf instructions cannot simply be carried across. Agency implementation information was checked on September 14, 2026.

Three kinds of change to keep separate

Before asking which operation to use, identify which record is changing.

A document can be internally approved but never submitted. A submitted replacement can be technically current while its proposed change is still under regulatory review. A later refusal or withdrawal may require another submission to restore an appropriate current view.

For each proposed change, write down the intended outcome in ordinary language: “This report replaces the current report,” “This is a separate report,” or “This document should cease appearing as current.” Then ask the publisher to show how the applicable technical model achieves it. This avoids choosing an operation merely because a file has a newer date.

The four eCTD v3.2.2 lifecycle operations

In v3.2.2, a leaf is an XML entry describing a document and its lifecycle relationship. A CTD section can contain several leaves. The operation applies to a leaf relationship, rather than to every document in that section.

For append, replace, and delete, the modified-file reference identifies a target leaf through its XML location and ID. A leaf already replaced or deleted is no longer a valid current target. These are v3.2.2 rules; see ICH eCTD Specification v3.2.2, Appendix 6, Table 6-3.

Why “another document” does not necessarily mean append

Suppose a section already holds Report A and you submit an independent Report B. Being in the same section does not establish a relationship between them. In the worked example below, B therefore enters as new.

Append needs a more specific reason. If an addendum supplements Report A while A remains relevant, an append relationship may express that intention, subject to regional guidance. It is not a shortcut for avoiding the decision about whether the reader needs one consolidated document or two connected documents.

FDA advises caution with append and suggests considering consolidated replacements; updated datasets should replace the old datasets rather than append to them. These recommendations appear in FDA's September 2024 Technical Conformance Guide, section 2.5. The EU also recommends avoiding append because it increases lifecycle complexity, and prohibits targeting a leaf in a different CTD section. See EU Harmonised Technical Guidance v6.0.1, section 2.9.6.

Worked history: two replacements, an independent addition, and a deletion

The following is an illustrative v3.2.2 lifecycle history, not a complete submission or an executed validator result. It uses sequences 0000–0003 to make the relationships easy to follow; this does not prescribe the starting sequence for every agency. Assume all relevant history is available and each sequence is technically accepted.

The fictional application begins with Report A and Report B in the same appropriate CTD section. Later, A is revised twice, a separate Report C is introduced, and B is retired. The short leaf IDs are explanatory identifiers.

The target column identifies the historical XML entry. An actual relative reference from sequence 0002's index.xml to the A2 leaf would include the parent-directory step:

modified-file="../0001/index.xml#lfA1"

This is an attribute illustration, not complete XML that can be submitted.

Three decisions matter in this history. First, A3 targets A2, because A2 is current immediately before sequence 0002. Targeting A1 again would skip the valid current predecessor. Second, A2 is a valid replacement target even though it originally entered through a replace operation. Third, C1 is new even though the section already contains other reports.

What the historical view must still show

After 0003, ask the reviewer to open both views. The latest current view should present A3 and C1. A view reconstructed through 0001 should present A2, B1, and C1. The retained history should still let the reviewer open A1, A2, A3, B1, and C1 in their original submitted contexts.

Do not satisfy this exercise by saving screenshots of the final current view alone. They cannot establish that A1 remains readable, that A2 was the predecessor actually referenced, or that B1 existed before its deletion. Keep the submitted packages and inspect the relationship chain.

A separate optional branch can test append: starting from the state after 0002, append an addendum to A3 in a later sequence. The expected outcome is A3 plus its addendum, with the relationship visible. It is not the same outcome as replacing A3 with a consolidated A4. This branch demonstrates the distinction; regional suitability still needs review.

Change one input and check the failure

Use these cases during a publishing handoff or history-import evaluation. They are acceptance scenarios with expected outcomes, not claims that any named software passed them.

The last case is why technical checks and human review serve different purposes. A well-formed independent addition can still express the wrong business decision. Conversely, a missing-history warning should trigger retrieval of the missing dependency before anyone concludes that the source submission itself was wrong.

FDA's published criteria explicitly distinguish a missing modified-file target from a target not previously submitted to an application within a grouped submission. Those are separate issues under codes 1153 and 1154 in the v3.2.2 validation criteria, revision 4.6.

Leaf IDs, file checksums, and document versions are different

A document-control system might call the approved source “version 7,” while its submitted leaf has ID lfA2 and its PDF has an MD5 checksum. These values answer different questions.

The leaf ID identifies the XML entry and must be unique within that XML instance. The checksum checks file integrity; it is not the leaf identity. The leaf's optional version attribute can express the submitter's internal version. The file reference identifies the actual content, which is not necessarily newly stored in the current sequence. ICH v3.2.2, Appendix 6, Table 6-8 and file-reuse discussion.

For the worked example, the handoff inventory should connect A3 to its approved source, its final submitted PDF, its leaf ID, and A2's target reference. Keep those fields separate. A publisher should not need to infer the predecessor from a filename such as report-final-v3.pdf.

Also distinguish a scientific content update from a rendering change. If the source text is unchanged but a publishing correction changes the PDF bytes, the integrity value may change. The team still needs to decide what correction is being submitted and how the relevant agency expects it to be handled. Recalculating a checksum does not make that decision.

Sequence numbering and corrections depend on the region

Manage sequence identity within the correct application. Do not let an internal study number, an IND serial number, or the number of agency letters determine the next submission package number.

For example, FDA's v3.2.2 guidance says presubmissions start with 0001, with the original application following the next available sequence number. It also distinguishes an IND serial number from the eCTD sequence number. A universal “every original application starts at 0000” rule would therefore be misleading. See FDA Technical Conformance Guide, sections 2.3 and 2.6.

EU guidance normally starts an initial eCTD lifecycle at 0000. It distinguishes a technically invalid sequence, generally corrected using the same number unless the agency advises differently, from technically valid content needing a new sequence. See EU Harmonised Technical Guidance v6.0.1, section 2.9.4.

The same distinction matters when reading FDA error reports. For example, corrective actions for unsupported DTD versions under codes 1459 and 1463 expressly allow resubmission using the original sequence number. That permission should not be generalized to every kind of correction. Consult the actual error and acknowledgment in FDA's validation criteria.

In practice, retain each transmitted attempt, its identity, receipt information, and technical disposition. Mark which attempt established the accepted history. If a corrected retransmission uses the same sequence number, avoid silently overwriting the team's evidence of the earlier attempt. Your internal archive can preserve both attempts while the regulatory lifecycle follows the authority's accepted record.

Regulatory rejection is a different event

An authority rejecting a proposed change does not mean the associated sequence can simply be removed from the dossier.

For EU post-authorisation activities, section 4.11 describes a consolidating sequence to restore the appropriate current view after withdrawal or rejection, retaining the application form and cover letter. The guidance explicitly says a sequence cannot be deleted from the lifecycle to accommodate that outcome. EU Harmonised Technical Guidance v6.0.1.

Operationally, reconcile the scientific decision first: which proposed changes remain relevant, which need reversal, and which documents require adjusted content? Then define the technical changes. A “delete everything from the rejected activity” shortcut could remove records needed to understand the decision or leave other affected documents in an inconsistent state.

Study metadata is part of the handoff

In FDA v3.2.2 work, STF means Study Tagging File, not Submission Tracking File. The FDA standards catalog lists the ICH Study Tagging File specification v2.6.1 separately from the main backbone specification. Confirm the applicable study structure and metadata when clinical or nonclinical content changes. FDA v3.2.2 submission standards.

An internal spreadsheet recording dispatch dates is useful, but it does not replace study metadata in the submission. During handoff, ask the publisher to reconcile the study identity and the documents associated with it, particularly when replacing a report, adding datasets, or importing a dossier from another provider. The reviewer should be able to locate the intended study content through the submission structure, without relying on your internal tracker.

eCTD v4.0 uses a separate lifecycle model

For v4.0, start from the submission unit and Context of Use, rather than translating the four v3.2.2 leaf operations word for word. A Context of Use places a document within its regulatory context. The document's identity and its use in the dossier are separate concepts.

FDA's v4.0 Technical Conformance Guide describes replacement within a context group, including one-to-many and many-to-one relationships where applicable. It also describes reuse of a document UUID. If a heading or keyword change moves content into a different context group, the guide describes suspending the old context and creating a new Context of Use, rather than replacing across context groups. See FDA v4.0 Technical Conformance Guide v1.5, sections 1.5.2–1.5.5.

Consider a separate v4.0 exercise: the document bytes stay the same, but its placement needs a keyword change that changes the context group. Ask the publisher to show the old context, the proposed new context, and the document identity each uses. The expected assessment concerns context relationships and status. Demonstrating a v3.2.2 modified-file path would not answer this question.

Apply the authority-specific v4.0 decision tree before treating a technical conversion as an allowed production transition.

Format support does not establish transition eligibility

As checked September 14, 2026, FDA accepts v4.0 for new CDER and CBER regulatory applications, beginning September 16, 2024. Its standards page still assigns forward compatibility for existing v3.2.2 applications to a future implementation phase. Published forward-compatibility examples or a software feature do not themselves authorize converting an existing FDA application. FDA v4.0 submission standards.

EU implementation has a different scope: the July 8, 2026 update describes optional v4.0 use for new centrally authorised product marketing authorisation applications since December 22, 2025, alongside ongoing pilot work. Do not treat that as universal availability for every EU procedure or existing dossier. EMA eSubmission implementation news.

Before selecting a transition path, record the agency, procedure, application status, format currently used, and applicable implementation phase. Check whether the cited document is effective, future guidance, or pilot material. For an application that remains in v3.2.2, continued support for its existing lifecycle is a hard publishing requirement even if the team is preparing for v4.0 elsewhere.

A practical handoff before the next submission

Give the publisher a change inventory with one row per intended addition, update, or retirement. Include the reason, selected source version, final rendition, proposed location, predecessor where applicable, and the owner who confirmed the intended outcome. A document title alone is not enough to select a lifecycle target.

Then reconcile the available history. Record the application identity, imported sequences, accepted or rejected status, and any missing dependencies. If a publishing provider changes, obtain the underlying submitted files and XML as well as an inventory. A current-content export is useful for reading, but it cannot by itself establish all predecessor relationships.

Review the proposed current view against the inventory, using a known history like the example above. Open at least one replaced document and one deleted document in the historical view. Verify that the import preserves links and that the export can be handed to the next responsible party without relying solely on access to the outgoing provider's system.

Finally, retain the validation report with its product version, rule-set revision, applicable region and eCTD version, history loaded, findings, resolutions, and reviewer signoff. Distinguish a missing dependency from a confirmed invalid relationship. For the wider file, XML, and document review process, use the eCTD validation guide.

The immediate deliverable is an agreed change inventory and a demonstrable current/historical view. If either is unresolved, settle it before finalizing the next package. That gives the author, regulatory lead, and publisher a shared answer to the question that matters: what should change for the reviewer, and what must remain available to explain how the dossier reached that state?

Use the eCTD vendor-switching checklist when the handoff also moves the application to a different publishing system. For an acquired program, the application-transfer inventory separates history, permissions and ownership-process evidence.