eCTD Lifecycle Operations Explained: New, Replace, Append and Delete

An eCTD application is not a folder of documents. It is a history: every sequence says what it adds and what it changes in what was filed before. Lifecycle operations are how that history is written, and getting them wrong is one of the quietest ways to confuse a reviewer.

Why lifecycle exists

Applications live for years. An IND may run to hundreds of sequences; a marketing application keeps receiving variations, supplements and annual updates long after approval. Reviewers need to know, at any moment, which version of each document is in force. eCTD answers that by recording, for every document in every sequence, how it relates to what was submitted before.

In eCTD 3.2.2 each document entry in the backbone — a leaf — has an operation attribute. There are four.

The four operations

New. The document is being submitted for the first time in this place. It does not affect anything filed earlier. Most documents in an initial sequence are new.

Replace. The document supersedes one filed in an earlier sequence. The leaf points back to the document it replaces. In the current view the new version takes its place, and the old one becomes history.

Append. The document adds to one already filed without superseding it — an addendum to a report, for example. Both remain in force together. Several agencies discourage or restrict append, so check the regional guidance before you rely on it; a replace with the complete updated document is usually clearer for the reviewer.

Delete. The document filed earlier no longer applies. The leaf points to it but carries no file. In the current view the document disappears; in the history it remains, with the sequence that retired it.

Current view and cumulative view

Agencies and good review tools show an application two ways. The cumulative view lists everything ever submitted, sequence by sequence. The current view applies all the operations and shows only what is in force today. A reviewer opening section 3.2.P.8.3 wants the current stability data, not every version since sequence 0000 — which is exactly what the operations make possible.

This is also why lifecycle errors matter even when they pass validation. A replace that points at the wrong document is technically valid. It retires something that should still be in force and leaves the document it should have replaced sitting beside the new one. The reviewer now sees two versions and no clear answer.

A replace pointing at the wrong document usually passes validation and still confuses the reviewer.

The mistakes that cause trouble

• Filing as new what should be a replace. Two versions of the same document end up in force at once.
• Replacing the wrong target. Common when documents share titles, or when a section holds several similar files.
• Losing the target altogether. When an application moves between tools or vendors, the references back to earlier sequences can break, and later operations have nothing valid to point at.
• Changing location instead of operating on it. Moving a document to a different section is not a replace; the old placement stays in force unless it is deleted.

What changes in eCTD 4.0

eCTD 4.0 keeps the idea of lifecycle but models it differently. Documents are identified independently of where they are placed, so the same document can be referenced again — in a later sequence or another application — without resubmitting the file. Lifecycle is managed on where and how a document is used, and the append operation is not carried forward. If you are planning a move to 4.0, our eCTD 4.0 readiness guide covers what to prepare.

How DnXT approaches it

In DnXT Publisher the operation for each document is chosen against the application’s current view, so a replace is picked from what is actually in force rather than typed as a path. Cumulative and current views sit side by side, and region-specific lifecycle checks run with the rest of validation while the sequence is built.