Open an approved document in a regulatory library and ask a question that should be easy: where has this been filed?
Which applications, which sequences, which eCTD sections, under what lifecycle operation. It is the first thing a reviewer wants to know, the first thing an inspector asks about a document, and in most systems it can only be answered by leaving the document system and looking in the publishing tool.
The result is predictable: three teams keep their own spreadsheets, and none of them agree.
Why the answer is not simply a field on the document
The obvious design is to put the application and sequence onto the document itself. Two reasons that is wrong, and the second is the one that matters in a regulated setting.
A document can be filed in many places. Quality content legitimately supports several products; a study report supports an original filing and later supplements. One document, many applications, many sequences — that does not fit in a single field.
Writing to the document changes approved content. Documents that reach a sequence are usually approved. Adding an application or product to the document is a change to an approved record — which needs version control, a reason for change and an electronic signature, and produces a new version of a document whose content did not change at all.
Recording the connection about the document is a completely different claim. The document is untouched. Its version is unchanged. Its approval still means what it meant. That is the version that survives a quality review, so that is how DnXT records it.
How the connection was made is shown alongside it
Each entry records how it came to exist, and the document panel labels it:
- Publisher — recorded automatically when the document was placed into the submission structure.
- Manual — a person asserted it.
- Import — worked out from an existing sequence during a migration.
That distinction is the point of the whole record, and it is why it appears on the entry rather than only in the audit trail. A reviewer looking at approved content has to be able to tell something the system worked out from something a person asserted without leaving the page. Sending them to an audit trail to find out whether what they are reading can be trusted is not a workable review process.
The explanation of how each connection was made is written by the system itself, not by whatever asked for it — so nobody can supply their own account of what happened. The screen shows that explanation word for word rather than writing its own version. One description of how a fact got there, written by the thing that put it there.
Removal supersedes; it does not erase
When a document is removed from a sequence, the connection is marked as superseded rather than deleted, and the panel keeps a “previously filed in” section.
The document was in that sequence. That happened. A record that disappears the moment it stops being current is not evidence of anything — and “was this document ever filed in this application?” is a question with real consequences.
A small presentation decision follows: superseded entries are greyed, not struck through. A strikethrough reads as “this never happened”, and it did happen. How something looks has to match what it claims.
A failed load is not an empty list
The panel tells them apart explicitly. When it cannot load, it says so — and says, in words, that this is not the same as the document being unused.
An empty list and a failure to load look identical by default and mean opposite things. “This document has never been filed” is a meaningful, reassuring, and occasionally very wrong conclusion to draw from something that quietly gave up.
This principle runs throughout DnXT — a check that did not run is never shown as passed, a search that failed is never shown as no results, a register that cannot be reached is never shown as an empty log. It is probably the single most valuable convention in regulated software: never let the absence of an answer look like an answer.
What it gives you
Once these connections exist and are visible on the document, several things stop being projects:
- Impact analysis when a document is superseded — which sequences and applications are affected, answered from the document itself.
- Inspection readiness — “show me everywhere this SOP was filed”, answered in one place, with the origin of each answer attached.
- Reuse decisions backed by evidence, rather than by somebody’s memory of what was filed where.
- A real connection between authoring and publishing, so the two halves of the process stop keeping separate pictures of the same reality.
The connection itself is a small record. Its absence is the reason those spreadsheets exist.
DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see document-to-submission traceability with its origin attached against your own submissions.
