Ask a regulatory operations team a question that sounds simple: which documents are currently in force in 3.2.S.2.3 for this drug substance, across every sequence we have filed?
Watch what happens. Somebody opens a viewer. Somebody else opens a spreadsheet they maintain by hand. A third person remembers that sequence 0031 replaced two of those documents and 0044 deleted one.
The answer exists. It has been checked, validated and accepted by an agency. It is just not in a form anyone can look up.
Everything is searchable except the submission itself
In a modern regulatory platform, nearly everything can be looked up. Products, substances, manufacturers, indications, applications, market registrations — all of them can be listed, filtered and cross-referenced in seconds.
The contents of your filed submissions are the exception. For eCTD 3.x, each document’s identity, its lifecycle operation, its section context and its relationship to the document it replaced live inside the submission’s own index.xml file and the regional file beside it. That is where the standard says they belong, and that is correct — those files are what the agency received.
The consequence is that every interesting question starts by reading XML files by hand. Not one file: the index and regional files for every sequence in the dossier, in order, tracking replacements as you go. It is possible. It is also why nobody does it casually, and why the answers end up in spreadsheets that quietly go out of date.
An index built from what you filed
DnXT builds a searchable index of your filed submissions at the moment you publish — one entry for every document, in every sequence, in every backbone.
The distinction between an index built from the filing and a second version of the truth is the whole design. The submission files stay authoritative. The index is rebuilt from those files in one go, so it can always be regenerated and can never quietly become the thing you believe instead of the thing you actually filed. A reconciliation check exists for one purpose: compare the index against the files and report any disagreement.
Each entry carries what you need to answer a question without opening the submission:
- The section, with its full context — not just “3.2.S.2.3” but the substance, manufacturer, product, indication and excipient that tell you which 3.2.S.2.3 this is.
- The lifecycle operation — new, replace, append or delete.
- What it replaced, resolved to the specific earlier document, which is what actually connects a replacement to its predecessor.
- Checksum, document order, and a tamper-evident seal per sequence, so the index itself can be shown to be unaltered.
Context is matched, never guessed
Section context in eCTD is a set of names. “Drug substance: angiotensin II acetate.” Those names have to be matched to your actual substance and manufacturer records before you can cross-reference anything.
DnXT matches on the exact name. When a name does not match anything, it stays visible as written and is never guessed at. A near-match on a manufacturer name produces a plausible-looking wrong answer — and in a regulatory system, a plausible-looking wrong answer is worse than no answer at all, because nothing downstream can tell it apart from a real one.
That is a rule we apply across the platform rather than a detail of this feature: the software may report what it suspects, and may not quietly turn a suspicion into a fact.
“In force” is not the same as “most recent”
The most common way to get this wrong is to assume the latest sequence wins. It does not, because eCTD lifecycle is a web of relationships, not a simple list.
A document is in force when it has not been deleted and has not been replaced by something filed later. That relationship is carried by the submission’s own statement about what supersedes what. Deciding it by sequence number, or by whatever order things happen to come back in, produces an answer that is right most of the time — which is the worst possible property for a compliance question.
So the index resolves each replacement to the specific earlier document and records it. “What is in force” then becomes something you can work out directly, using exactly the evidence the agency holds.
Indexing never holds up a filing
The indexing runs after the publishers have written the final backbone and everything has been reconciled. If it cannot finish, it retries, and then raises an alert.
It does not fail the publish. An index is a convenience built on top of a filing; a filing that succeeded, succeeded. Coupling them the other way would mean a temporary problem in a reporting feature could hold up a submission on a deadline — which is not a trade any regulatory team should be asked to make.
What it makes possible
Once your filed submissions are searchable, questions that used to be projects become answers:
- Change impact. “What have we filed that names this manufacturing site?” becomes a lookup rather than an investigation.
- Section-level history. Every version of 3.2.P.3.3 across the life of the dossier, with the operation that put it there and the sequence it came from.
- Facts read back out of filings. Finding every Form 356h ever filed in a dossier — and reading the establishment details off it — starts with knowing which documents are forms, and where.
- Honest gaps. A dossier that has never been indexed is reported as a gap, by name. Silence and completeness look identical to a reader, and they mean opposite things.
The underlying idea
Your filed submissions are the most reliable information your organisation owns, and in most systems they are completely opaque — a folder of files that only a viewer can open.
Making them searchable does not change what was filed. It changes what you can ask, and how quickly you get an answer you can defend.
DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see lifecycle-aware answers from your own filed sequences against your own submissions.
