Validation is rarely run once. A publisher validates a sequence, works through the findings, makes corrections and validates again. Then a late document arrives, and the cycle repeats. By the third or fourth run, the report that matters is not the latest one on its own. It is the difference between the latest one and the run before it.

Did the corrections fix what they were meant to fix? Did they introduce anything new? Is the finding that is still failing the same one on the same file, or the same criterion on a different document?

Most tools leave that to a person with two reports open side by side. The totals might match — five medium findings before, five medium findings after — and still hide the fact that one finding was fixed and a new one appeared.

Compare the runs, not the totals

DnXT’s validation history now offers Compare with previous on every completed run. It lists:

  • New — findings in this run that were not in the previous one
  • Fixed — findings in the previous run that are gone
  • Still failing — findings present in both

Findings are grouped by criterion and ordered high, medium, low. Crucially, the files are compared too. If a criterion is still failing but now on a different document, that is called out rather than hidden inside “still failing” — because it usually means a correction moved a problem rather than solving it.

When nothing has changed, it says so plainly: the same findings, on the same items.

Why this matters more than it sounds

Re-validation is where time disappears at the end of a submission. A publisher who cannot see the difference quickly ends up re-reading every finding on every run, just in case. Or, worse, skims the totals and assumes nothing changed because the numbers match.

A direct comparison turns each run into an answer: these corrections worked, these are still open, and this one is new and needs a look before the sequence goes anywhere.

Part of a wider principle

This is one of several checks DnXT has built from the questions publishers were answering by hand at the end of real submissions. Others include refusing to publish while a document is still a draft, checking every file against FDA’s accepted formats for its location, and verifying that every hyperlink lands where its text says it does. Each is deterministic — the same input always produces the same answer — and none depends on a model’s judgement.

The common thread is simple. A regulatory team should spend its attention on the findings that need a decision, and the software should do the bookkeeping that tells them which findings those are. See preflight and automated validation and document QC for the rest of the picture.

DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see validation run comparison on a sequence you are working on.