Once a sequence is filed, its contents are fixed. Every file has been fingerprinted, those fingerprints are recorded in the submission’s own manifest, and an agency holds a copy. That is not a vendor policy choice — it is what makes an eCTD submission a record rather than a folder.
Which creates an awkward moment when a link check finds a stale hyperlink in a sequence you filed eighteen months ago.
The fix itself is trivial: point the link at the document that replaced the original destination. The system knows the right target, because it knows what replaced what. The hard question is not what to write. It is where.
The dangerous default
Software that corrects a PDF link writes to whatever file it is given, in place, with no idea which folder that file sits in. It cannot know — it is a document utility, and correctly so.
So everything standing between a link fix and a corrupted filing is the decision about which file to write to. Get that wrong and the software rewrites a document whose fingerprint is recorded in a manifest an agency already holds. The submission does not break in an obvious way. It becomes quietly inconsistent with its own manifest, and you find out during an inspection.
That is why, in DnXT, deciding where to write is not an afterthought buried in the file-saving code. It is a dedicated part of the software with its own tests, checked as rigorously as the regulatory rules — because it is the only thing standing between a routine correction and an unrecoverable one.
Refusing is the feature
The instinct when something cannot be resolved is to fall back to whatever seems reasonable. Here, every reasonable-looking fallback is the disaster.
DnXT refuses, rather than falling back, in four situations:
- The working area and the filed submission turn out to be the same folder. The most dangerous configuration there is, because the “fix” would rewrite the filed document while appearing to work perfectly.
- The dossier has no working area recorded. Writing the corrected copy next to the filed file is the obvious fallback and precisely the outcome to prevent.
- The corrected file would end up outside the working area. A file-writing system that can be pointed somewhere unexpected is a security problem as well as a compliance one.
- The filed document is not where the record says it is. If what you started with is not what it claims to be, nothing that follows should assume otherwise.
Refusal with a clear reason is a good outcome. A regulatory operations person told “this dossier has no working area configured, so nothing was written” can fix that in a minute. A person whose file was silently written somewhere convenient cannot undo it.
The destination is decided by the system, not by whoever asked
The working area is worked out by the system from the dossier’s own recorded location, using the same logic the publishers use.
It is emphatically not something the caller can specify. This is worth dwelling on, because letting the caller name the folder is the natural design and it is wrong here. This is the code that decides where files land. If the caller could name the folder, the write could be aimed anywhere the system can reach — and that is the one thing the safety check cannot defend against, because it can only judge a destination against the folder it was told about. Give it the wrong folder and it approves happily.
The general rule: when part of a system exists to constrain where something is written, it must not take that constraint from the very thing it is constraining.
Nothing is written without confirmation
Run it without confirming and you get the plan and no changes at all. You see every link it intends to change, in which document, from where to where. Then one approval covers the batch.
Two reasons, and only one of them is process.
The compliance reason: rewriting an already-filed document without human approval is not defensible under GxP, whatever the change is and however correct it looks.
The practical reason: repositioning a link can get it wrong. Pointing a link at a replacement document means finding the right place in that document, and the replacement has different pagination. The system reports any target it could not locate rather than quietly failing — because software that ignored those would claim success for links it never actually changed. Listing them individually, rather than summarising, is what makes the confirmation step meaningful.
The corrected file is a starting point, not a filing
What comes out is a corrected copy in your working area. That is all.
Filing it is ordinary work afterwards: review it, approve it, include it in the next sequence as a replacement, publish. The mechanism eCTD already provides for “this document supersedes that one” is exactly the right mechanism, and there is no need to invent a second one.
The tempting shortcut — quietly correct the filed sequence, since the change is small and obviously right — is what turns a QC finding into a data integrity finding. The correction is not the problem. Its invisibility is.
What to ask a vendor
Software that touches filed regulatory records needs one commitment before anything else: the boundary between what has been filed and what is still being worked on is enforced by the software, not by training.
Every organisation has a procedure saying nobody edits a filed sequence. Procedures stop deliberate acts. They do not stop a well-intentioned feature with a sensible-looking fallback.
So ask what the software does when it cannot work out where to write — and be pleased if the answer is “it refuses”.
DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see remediation that never touches a filed sequence against your own submissions.
