A validation report is the agency’s first look at your sequence, run by you before they run it. Read well, it tells you in minutes whether the submission will be accepted. Read badly, it sends a team chasing two hundred findings that come from four causes.
Key takeaways
- Agencies validate every sequence automatically before a reviewer opens it.
- Read the report by severity first and by count last.
- Most findings share a handful of causes; fix the cause, not each line.
- Compare each run with the last one so you can prove what changed.
What eCTD validation is
When a sequence reaches an agency, a validator checks it against that agency’s published criteria before any reviewer sees it. The checks are mechanical: is the backbone XML well formed and valid against its DTD or schema, does every file it references exist with the checksum it claims, are the envelope values drawn from the agency’s controlled vocabularies, are lifecycle operations pointing at documents that were actually filed, and do the PDFs meet the agency’s technical rules. A sequence that fails the wrong check is rejected on technical grounds and the review clock does not start.
Running the same criteria yourself, before you send, is what eCTD validation means in practice. The output is a report: a list of criteria, each with a result and a severity.
Read it by severity, not by length
The first instinct is to look at how many findings there are. The number is almost meaningless. One high-severity finding can stop a submission; a hundred low-severity findings will not. Each agency grades its criteria in its own way — FDA uses high, medium and low for eCTD 3.2.2, the EU uses pass/fail and best practice, Health Canada uses error, warning and information — so the first question is always the same: is there anything here that the agency treats as a reason to reject?
If the answer is yes, nothing else matters until it is fixed. If the answer is no, the medium findings are next, because an agency may ask you to correct them, and low or best-practice findings are worth fixing so they do not become habits.
Group findings by cause
Validation reports are long because one problem shows up many times. A wrong application number appears on every check that reads the envelope. A file renamed after the backbone was built fails a checksum check and a reference check. A PDF exported with the wrong settings fails for fonts, for version and for Fast Web View. Teams that work the report line by line fix the same problem repeatedly and still miss its source.
Before fixing anything, sort the findings into the few causes behind them. The usual groups are the envelope (application details, submission type, sequence number, contacts), files and checksums, lifecycle (a replace or delete that targets the wrong leaf), PDF properties, and navigation (bookmarks and hyperlinks). Our page on eCTD validation rules walks through each group.
A long report usually has a short list of causes. Fix the causes and the report shortens itself.
Fix at the source, then rebuild
It is tempting to patch the published sequence: edit a PDF in place, adjust a value in the XML. That fixes this sequence only, and it creates a new problem — the files on disk no longer match the checksums the backbone recorded. The durable fix is upstream. Correct the document and re-render it, correct the application record that the envelope is built from, choose the right lifecycle target, and then rebuild the sequence so every checksum and reference is generated fresh.
Re-run and compare with the last run
A clean second report is good; knowing exactly what changed between the two is better. When each run is compared with the previous one, the report answers the questions a lead actually asks: which findings are new since yesterday, which are resolved, and which have not moved. It also gives you evidence. Keep the final report with the sequence you transmit, so that if the agency raises a technical question you can show what you checked and when.
Validate what you receive, too. Sequences built by a partner or a previous vendor deserve the same check before you build on them. Problems inherited from an earlier sequence are much cheaper to find now than in the next submission.
Use the agency’s own criteria
A validator is only as good as the rules it runs. Use the current published criteria for the region and version you are filing in, at the agency’s own severity, so that a clean report means what you think it means. We publish the criteria for several agencies in searchable form — start with the eCTD validation criteria hub.
How DnXT approaches it
DnXT Publisher runs each region’s own criteria — more than 2,500 across 16 eCTD regions — while a sequence is being built, not only at the end. Findings are graded at the agency’s severity, every run is kept, and each run can be compared with the last so you can see exactly what changed.
See a validation report you can act on
Bring a sequence and we will run it against its region’s criteria with you.
