eCTD File Naming Conventions: Rules and Checked Examples

This reference is for publishers and regulatory-operations reviewers checking names in a candidate submission. Its numerical lookup covers the identified 3.2.2 sources, checked October 6, 2026. It does not transfer their conventions to eCTD 4.0, a gateway transport archive, or an internal document-management system.

The distinction matters in practice. A source Word file can have a descriptive working name while the published PDF uses a controlled submission name. A short PDF name can still sit inside an overlong path. A filename can satisfy the allowed-character convention while pointing to the wrong study. Check those questions separately.

Find the rule for the value you are checking

Start by separating a name, a path, a document title and a delivery archive. The name is one component, such as study-101.pdf. The path identifies its location through folders. The leaf title is reviewer-facing text in a 3.2.2 backbone. The delivery archive or other transport wrapper follows its own instructions.

These entries describe different scopes. Do not take the largest number as a global allowance, or label the shortest number a universal ICH requirement. Record the receiving authority and intended format beside the result.

For eCTD 4.0, open the applicable regional implementation and technical documents separately. FDA's v4.0 standards index identifies those documents; the format-readiness guide explains why new-application eligibility and existing-application history also matter. A v4.0 document title does not prove that every older filename constraint carries over unchanged.

Apply the character convention without inventing extra rules

For the ICH 3.2.2 convention above, assess the literal published name. A name copied from an email can contain a space, an uppercase extension, or a visually similar dash that is not the ordinary hyphen character. A reviewer may not notice those differences by looking at a rendered document title.

These are convention checks, not a claim that every example triggers the same rule, severity or gateway response. An underscore's absence from one authority's list of detected invalid characters does not establish that it satisfies the entire governing convention. Equally, an XML identifier may have different rules from a filename. Do not apply the filename table to every string in a backbone.

Keep extension syntax separate from accepted file type. Renaming a Word document from .docx to .pdf changes its name, not its format. A syntactically tidy extension also does not prove that the file type is accepted in the intended section. FDA's file-format specifications, reached through its 3.2.2 standards index and the corresponding regional sources govern that next question.

Use the eCTD overview for orientation if names, document placement and submission format are being treated as the same task. They are related controls with different evidence.

Count names and paths from a stated boundary

Count the value that the rule evaluates. Do not include a local workstation prefix such as a user's desktop directory unless the governing rule actually includes it. Do not remove the sequence folder from an EU path calculation: the cited guidance explicitly starts there. For an unfamiliar validator, retain the displayed input and ask how its count is produced.

The examples below are invented ASCII strings. Their counts are reproducible; none is a sample agency submission.

The filename:

clinical-study-report-pk-phase-1-healthy-volunteers-study-001.pdf

contains 65 characters, including the period and pdf. It exceeds the 64-character ICH limit. Removing the hyphen between study and 001 produces the following 64-character boundary example:

clinical-study-report-pk-phase-1-healthy-volunteers-study001.pdf

A boundary example is not a recommendation to use the longest possible name. Prefer a concise, controlled identifier that your team can distinguish from similar records. Keep the fuller readable description in the appropriate document metadata or leaf title.

For a path, count every included separator as well as every name:

0000/m3/32-body-data/32s-drug-sub/32s41-spec/drug-substance-specification-release.pdf

This path is a counting fixture only. It does not demonstrate the correct section folder hierarchy or document granularity. Its 85-character count is below the numerical limits in the table, but the Canadian result still needs the proper regional counting boundary and all other applicable checks. A short string is not proof of a valid package.

Reproduce the counts with a small local check

Python 3 can count these supplied strings without opening or modifying any files:

examples = {
    "over_limit_name": "clinical-study-report-pk-phase-1-healthy-volunteers-study-001.pdf",
    "boundary_name": "clinical-study-report-pk-phase-1-healthy-volunteers-study001.pdf",
    "path_example": "0000/m3/32-body-data/32s-drug-sub/32s41-spec/drug-substance-specification-release.pdf",
}
for label, value in examples.items():
    print(label, len(value))

Expected output:

over_limit_name 65
boundary_name 64
path_example 85

These ASCII counts were checked for this article. The code is not an eCTD validator: it does not establish character eligibility, file format, path resolution, regional applicability or content identity. For non-ASCII input, first establish the applicable character/encoding rule instead of assuming Python's character count reproduces an authority's implementation.

For a length-only boundary exercise, compare "a" * 59 + ".pdf", "a" * 60 + ".pdf" and "a" * 61 + ".pdf". Their lengths are 63, 64 and 65. The first two satisfy the stated maximum; the third does not. Changing one a to _ leaves the length unchanged while changing the character assessment. That is why one green result cannot stand in for the whole review.

Distinguish document placement from physical naming

A CTD section number tells the reviewer what a document means in the dossier. A folder name tells the software where bytes are stored. They need to agree with the applicable publishing model, but they are not interchangeable identifiers.

ICH 3.2.2 Appendix 3 describes recommended folder/file names and allows appropriate adaptations; it does not make every illustrated directory mandatory. Its text also distinguishes the physical display order from CTD navigation order. Use the structure guide to plan the content hierarchy, then verify the resulting references and regional packaging. Do not manufacture empty folders merely to make an illustration look complete. ICH Appendix 3.

A practical naming plan should retain an approved source identifier, a published-file identifier and the intended document role. If two reports would both become study-report.pdf in the same location, resolve the collision before export. Adding “final-final” does not establish which approved source the output represents.

Interpret a finding before changing the package

An error message is evidence to investigate, not permission for an arbitrary rename. Record the tool/version, selected regional profile, criteria revision, exact rule, affected input and displayed severity.

FDA's checked 3.2.2 criteria distinguish, among others, path length 1085: Medium, invalid filename characters 1204: Low, and filename length 1221: Low. The document's severity definitions describe different processing and review implications. Therefore, a universal statement that every naming finding causes immediate rejection is inaccurate. Low severity is not a recommendation to leave a known defect unresolved. FDA criteria 4.6, definitions and named entries.

Do not map a vendor's message to an invented universal code such as FN-001. If the product uses its own identifier, retain both the product identifier and the documented agency mapping. An unresolved mapping stays unresolved. The common validation errors guide shows how to separate missing files, bad references and integrity findings.

Rename through the controlled publishing process

Consider a fictional pre-submission candidate. The approved source is report SR-101 revision 3. Its output is named Study 101.pdf; the publishing reference uses that same name. Your selected naming convention requires a change to study-101.pdf.

1. Preserve the original candidate and finding. Record the approved source identity and the exact old path. Confirm that this is the package you intend to correct.
2. Make the change where the output is generated. Update the publishing mapping or controlled export instruction so the next build does not recreate the old name.
3. Rebuild references with the renamed output. A new filename alone is insufficient if XML or PDF links still resolve to the old path. Keep the old-to-new mapping for review.
4. Check the intended file, not just any file at the target. Open the output and reconcile it to SR-101 revision 3. A different report with the expected name is a failed correction.
5. Repeat the applicable checks and handoff review. Retain the new candidate identity, report, configuration and reviewer disposition. Confirm that the relevant check remained enabled.

Renaming a file does not change its content bytes by itself. Republishing may nevertheless regenerate references or other outputs, which need checking. If a PDF is edited as part of the repair, its integrity metadata must correspond to the new approved bytes; do not retain an old report as evidence for changed output.

For an already submitted sequence, do not silently rewrite the historical archive. The corrective action depends on the actual finding and lifecycle context. Follow the applicable authority instructions through the responsible publishing/regulatory owner. Transport and acknowledgement questions belong in the FDA submission-delivery guide, separately from naming checks.

Keep a reusable naming decision record

Copy one row for each consequential finding. This is an editorial worksheet, not an agency form.

Use pass for a demonstrated check, fail for a contradiction, and unknown when scope or evidence is missing. “Not applicable” needs a recorded reason. If the authority or format is unknown, stop the rule decision; do not select the easiest limit to satisfy.

Complete the submission-readiness checklist after the corrected package is identifiable. When evaluating software, bring the original finding and corrected example to the validator comparison. For a supported Assyro workflow, discuss the actual input and required checks through eCTD validation. Assyro currently supports FDA eCTD 4.0, not 3.2.2; this reference does not imply that every example can be run in Assyro.