eCTD Validation Guide: Criteria, Checks and Release Evidence

This guide is for regulatory operations teams preparing a submission or accepting one from a publishing partner. It follows the work from choosing the rules to releasing an identifiable package. FDA examples are scoped to CDER/CBER; the regional comparison shows why one authority's report cannot cover every destination. Primary sources were checked September 14, 2026. The worked scenario is synthetic, with a complete answer key; it is not a vendor test or a submitted application.

What the validation result actually establishes

Before discussing whether a submission is “validated,” identify the question being answered. The same word is often used for a technical package check, a review of scientific content, or qualification of a computerized system. Each produces different evidence.

Treat this table as a responsibility map. A clinical reviewer may resolve a numerical inconsistency without changing the publishing configuration. A publisher may repair a package reference without determining whether the scientific conclusion is justified. The release owner needs both results when both tasks apply.

The practical meaning of a clean technical report is narrow: no findings were reported by that check, on that input, under that configuration. To rely on it, the team still needs to know whether the expected files were included, the applicable rules ran, and anything was skipped or unsupported.

Choose the authority, version and effective rules first

Record the receiving center or authority, application identifier, submission purpose, eCTD format, relevant history, and planned submission date. Then select the associated specifications and validation profile. “FDA,” “latest rules,” or “eCTD 4” alone is not a complete configuration record.

The format version and criteria version are separate identifiers. FDA criteria 4.6 does not mean eCTD format 4.6. Equally, a vendor's software release number is neither of those values. Keep all three in the run record so another operator can reconstruct the setup.

Check individual effective dates as well as the document cover. FDA's 3.2.2 criteria explain that a rule with an effective date marked TBD is not yet used for validation. The 4.0 criteria include newly listed rules with TBD dates. A posted rule is therefore not, by itself, proof of an active agency rejection condition. 3.2.2 effective-date definition, page 3, 4.0 criteria, including eCTD4-085

There is a similar distinction for supporting specifications. FDA's current 4.0 standards page lists regional implementation guide 1.9 and regional controlled vocabulary 1.2 with support dates still TBD. It also describes forward compatibility for existing 3.2.2 applications as a future phase. Do not infer that an existing application can transition because new documents or sample files are posted. FDA 4.0 implementation context

For another authority, build the equivalent record from its own current sources. A US check can remain useful evidence, but it does not replace the destination's regional rules or application-specific requirements.

Prepare the documents and the complete candidate package

Begin document checks during preparation, while the source owner can still make corrections. Inspect readability, navigation, cross-references, document identity and the applicable technical settings. Separate a source-content correction from a conversion or assembly correction so it reaches the right owner.

For FDA, the linked PDF specifications are version 4.1. They accept PDF 1.4–1.7, PDF/A-1 and PDF/A-2, and address searchability, navigation and security settings. A generic “PDF/A” label is insufficient to identify the exact format. These FDA specifications also do not establish another region's requirements. FDA PDF specifications, Version and Security sections

Create a candidate that can be identified independently of its folder nickname. Record its application/submission identifiers and the complete file inventory, with content digests appropriate to the controlled workflow. Retain the approved source versions used to produce it. This internal evidence record supplements the format's prescribed package metadata; it does not replace it.

The complete input matters. A checker given one PDF cannot establish conformance of an entire submission. An isolated new sequence may not supply the history needed to assess a lifecycle operation. If the tool lacks that context, record the limitation rather than treating an absence of findings as a successful check.

Manual navigation review adds a different observation. Open an important cross-reference from the assembled output and inspect the destination's identity and location, not simply whether a file opens. A link can resolve successfully to the wrong study or to a superseded document. Compare the destination with the approved source reference and record any correction. For summary-to-body checks, the Module 2 guide provides the surrounding document context.

Do not require every new sequence to repeat all five modules or every document in the application. Establish what the intended operation needs, including any referenced history. The submission checklist supports that broader preparation task; the XML backbone guide provides more detailed structural context.

Run the check, interpret the finding, and correct its cause

Capture the validator's product/release, rule profile, criteria revision, relevant settings and input identity before interpreting its report. Note skipped checks, unresolved dependencies and any custom rules. A vendor-specific warning and an active agency criterion should remain distinguishable even when one interface displays both.

For each consequential finding, record the affected artifact, applicable criterion, observed condition, responsible owner and planned disposition. Check that the rule applies to this authority, format and submission date. Then inspect the evidence behind the finding. A short error label is a starting point for investigation, not a complete correction instruction.

For a concrete technical example, FDA's 4.0 criterion eCTD4-059 identifies a missing, misplaced or incorrectly cased submissionunit.xml file as a High Error, effective September 16, 2024. The following cases apply only that filename check; they are not complete XML samples or executed validator results. Criteria 1.6, eCTD4-059, page 55

The operator should first confirm the actual directory listing and format record, then change the source configuration responsible for output naming. Produce a new candidate and repeat the affected check along with the other checks required by the release procedure. If the correctly named file still triggers the finding, investigate its location, the selected input and the tool configuration before repeatedly renaming it. This makes the correction traceable to an observed condition.

Checksum mismatch illustrates why severity cannot be guessed from the label. FDA's 3.2.2 criteria 4.6 list code 1374 as Low for US DTD 3.3. FDA's 4.0 criteria 1.6 list document-checksum rule eCTD4-064 as High Error, effective September 16, 2024. These are version-specific entries, not interchangeable severity labels. 3.2.2 code 1374, page 18, 4.0 eCTD4-064, page 56

Before submission, investigate whether the bytes changed, the wrong file was selected, or the recorded digest was generated incorrectly. Correct the controlled source or publishing process, rebuild as appropriate and check the resulting candidate. Do not edit a final file and keep the earlier report as its evidence. For an already submitted package, follow the applicable agency finding and corrective instructions rather than assuming every mismatch requires the same resubmission action.

FDA's 3.2.2 severity descriptions distinguish High findings that prevent processing from Medium and Low findings with different receipt/review implications. “Low” is not permission to ignore a known defect, and “any finding means rejected” is also inaccurate. Apply your release procedure while retaining the actual agency classification. FDA severity definitions, page 3

If two validators disagree, compare their complete inputs, rules and settings before counting findings. An extra custom check or a duplicated message does not demonstrate greater accuracy. Resolve the consequential difference at the artifact and criterion level. The common validation errors guide is the focused destination for further diagnosis.

Worked example: a clean technical report with a wrong summary

Assume a team is preparing an eligible FDA eCTD 4.0 submission. The approved source is a fictional study table, T-14 version 2, with a June 30, 2026 cutoff. It reports participants experiencing a particular event, counted once per participant. The submission plan calls for both a treated-population summary and a separately labeled randomized-population description.

The same eight participants belong to both populations in this invented example. The denominators differ because ten randomized participants were not treated. These facts define the exercise; they are not clinical data or a recommended analysis method.

Now inspect two sentences in the draft:

• Sentence A: “In the treated safety population, 8 of 40 participants (16%) experienced the event.”
• Sentence B: “Among all 50 randomized participants, 8 (16%) experienced the event.”

Sentence A is internally inconsistent: its numerator and denominator give 20%, not 16%. Sentence B agrees with the separate randomized-population row. Changing every occurrence of 16% to 20% would introduce a new error. A useful content check must preserve population, cutoff and source context, not enforce identical percentages everywhere.

Suppose the publisher produces candidate C1 with readable PDFs, functioning references and matching package integrity values. For the thought exercise, assume the configured technical run reports no findings. That assumed result is compatible with Sentence A still being wrong: the package can accurately carry scientifically incorrect prose.

After the content owner approves the correction, produce C2. Preserve C1 and its report, then check C2 under the applicable process and tie the new evidence to C2. The corrected PDF has different bytes; a C1 report cannot simply be renamed as the C2 report. Confirm that Sentence B was preserved and that the correction did not disrupt navigation or the intended package operation.

This is also a useful test of a proposed review tool. Ask it to locate Sentence A, link the finding to the correct source and allow Sentence B's difference to be accepted with a reason. An extraction failure or missing source should remain visible. No finding under those conditions is not proof of content correctness.

The exercise supports a limited release decision: the specified inconsistency has been resolved and the required technical evidence belongs to the revised candidate. It does not establish that the study design is adequate, the benefit-risk conclusion is sound, all required content is present, or the agency will accept or approve the application. Those questions need their own review and evidence.

The regulatory document QC exercise extends this example into a source-linked content-review evaluation.

eCTD validator vs publisher: when do you need both?

A publisher creates and maintains the electronic submission output. A validator checks an input against configured criteria and produces findings. You need both responsibilities covered when your team creates submissions, but that does not necessarily mean buying two products. Some publishing products include validation: Certara's current GlobalSubmit PUBLISH page, for example, describes live validation and PDF/navigation QC. GlobalSubmit PUBLISH

If publishing is internal, start with a publisher that supports the required authority, format and next operation. Determine what its built-in validation covers before buying a separate checker. Add an independent validator when it addresses a defined need, such as an independent release check or intake of partner-produced packages. A second engine can supply additional evidence, but it does not guarantee detection of every defect or resolve scientific meaning.

If a partner supplies finished packages, the immediate need may be an acceptance/review workflow. Request the package, report, checking configuration and correction responsibility. Demonstrate that the proposed validator can inspect that external input. If you must rebuild the package, maintain its history or perform the next operation yourself, validation alone is insufficient; publishing capability or a continuing service is still needed.

Apply that distinction to C1 and C2 above. A validator may identify a technical issue, but the organization still needs someone authorized to change the source and create C2. The content reviewer must correct Sentence A. A successful rerun cannot establish scientific completeness or take over the publisher's lifecycle work.

Compare procurement scope using the same submission and retained responsibilities. Include rule/profile updates, user access, historical retrieval, partner handoffs and any publisher or service you will keep. Missing public documentation is an unresolved requirement; a confirmed unsupported format excludes the product for that operation. Avoid assigning identical capabilities to all products labeled “AI,” “standalone” or “publishing suite.”

Assyro publishes this guide. For eligible FDA eCTD 4.0 preparation, review and validation, Assyro is our first evaluation recommendation. Demonstrate the exact external input, output and retained evidence required by your workflow. Assyro does not currently support eCTD 3.2.2, so retain a supported tool or service for required 3.2.2 work. The validation software comparison and publishing software guide provide more detailed selection context.

Use the LORENZ eValidator alternatives guide when the buying decision concerns a standalone validation workflow.

Qualify the software for the work you will rely on

Checking C2 and qualifying the system used to check C2 are different activities. The first concerns one candidate and one run. The second asks whether the configured system, procedures and responsible people can support a defined use with appropriate evidence.

FDA's Part 11 scope guidance recommends a documented risk assessment and consideration of record integrity when determining the approach to computerized-system validation. It also distinguishes applicable predicate-rule obligations from its enforcement-discretion policy. Applicability depends on the actual records and use; a software label alone does not settle it. FDA Part 11 guidance, section III.C.1

For this workflow, define what you rely on the system to do: select the correct profile, identify input files, retain findings, preserve dispositions and retrieve the evidence after a change. Evaluate those functions with the configuration you intend to use. Assign ownership for updates, access, exceptions and records retained outside the tool.

Include a case the tool should flag, an acceptable case it should preserve, and an input it cannot evaluate. The worked example supplies content-review cases, but it is not a complete qualification protocol. If the intended use includes retained review decisions and the system cannot retrieve Sentence B's accepted disposition, a clean package report does not close that separate requirement.

Evaluate Assyro eCTD validation only for its supported v4.0 scope, using the exact input, profile and retained report required by your process.

Release a specific package and track the agency response

Before handoff, have someone other than the preparer reconstruct the decision from the retained record. They should be able to locate the approved source, released candidate, applicable checking context, material findings and final dispositions. If they cannot tell whether a report belongs to C1 or C2, resolve the association before release.

Transmission follows its own process. FDA describes ESG as the central point for electronic delivery; an upload or local validation report is not a substitute for the relevant agency processing response. Track the response for the released submission and route any findings through the responsible regulatory owner. FDA submission process

For an Assyro evaluation, bring the authority/version record, one permitted candidate and a source discrepancy such as the example above. Discuss the required validation workflow, including the functions that remain with your publisher, content reviewers and release owner.