Every publishing tool checks for broken links. Open each PDF, follow every link, report the ones that lead nowhere. It is a solved problem and has been for twenty years.

It also misses the failure that actually costs you.

The link that works and is wrong

Consider a cross-reference from a Module 2 summary to a study report in Module 5. It was correct when it was written. Two sequences later the study report is replaced — a new version filed, superseding the original.

The link still works. The file it points at is still there, still valid. Every broken-link checker in the industry reports it green.

And a reviewer following it lands on a superseded document.

This is the failure that eCTD lifecycle creates and that link checkers were never designed for. Catching it means knowing not just whether a destination exists, but whether it is still the current version — which means understanding every replacement and deletion across the entire history of the dossier.

Three verdicts

DnXT’s link audit gives every link one of three results:

  • Verified — the link works, and points at the current version.
  • Broken — the link does not work.
  • Stale — the link works perfectly, and points at a version that has since been replaced.

There is a reasonable argument for treating stale links as simply broken. Both are defects; both need fixing; two categories are simpler than three.

We keep it separate for one reason: it is the only result no other tool produces. A reviewer scanning a defect list has learned what “broken” means and skims past it. Putting the finding nobody else can produce into the category everybody skims gives you a feature that technically works and changes nothing.

The three results also imply different work. A broken link needs a destination. A stale link already has one — it needs redirecting to the document that replaced its target, which the system can propose precisely because it knows what replaced what.

One check, not two questions

Two design decisions here are worth spelling out, because they are the difference between a feature that gets used and one that gets ignored.

Checking for stale links is the link check plus a lifecycle question. Running them as separate menu options means opening every PDF in the submission twice — on a real submission, minutes of a reviewer’s day, spent to learn nothing the second time. They are one job, so they run as one pass.

From a menu, “does this link work” and “does it point at the current version” are not a meaningful choice. Offering them as two options mostly guarantees people run the familiar one and never discover the other exists. One option, one pass, every link labelled.

A report a reviewer can sign

The other requirement is blunter: a link check whose output is a pop-up message cannot be the thing a QC reviewer signs their name to.

The report lists every link that was checked — the document, the page, the link type, where it points, the result, and for stale links what it should point at instead — worst first, with a full spreadsheet download for the second QC pass.

Not only the failures. A reviewer signing off “links checked” is making a statement about coverage, not just about defects. They need to see what was checked and passed. And since the check has already been through every link to produce the results, exporting only the failures would deliberately throw away evidence already gathered.

The warning markers come from that same single pass, and a document can carry both red and amber — because a document with two broken links and one stale link has two different problems.

Two principles worth borrowing

Both of these apply to any compliance check, and both exist because the alternative is software that misleads quietly.

A check that did not run is never shown as clean. “No problems found” and “the check never completed” look identical on screen and mean opposite things. If the check failed, the panel says so; it does not show green.

Approval covers the batch, never each link. A remediation run takes one approval for the whole set. Approving link by link sounds more careful and is the opposite — it produces a hundred clicks, and a hundred clicks is a rubber stamp with extra steps.

The general point

Most submission QC tooling was designed for a world where a submission is a folder of files. eCTD is not that. It is a series of lifecycle operations, where the meaning of any given file depends on everything filed after it.

Checks that ignore lifecycle will keep passing submissions a reviewer can visibly walk into the wrong document from. The fix is not a better crawler. It is teaching the check what “current” means.

DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see lifecycle-aware link checking against your own submissions.