Wrong Document Version in a Submission: What to Check

First establish which document was authorized, which artifact entered the package and whether that package was transmitted. Preserve the evidence and hold the affected release while those facts are reconciled. Replacing a local file does not change a package already received by an agency.

This troubleshooting guide is for regulatory operations and document owners investigating an apparent wrong-version document in a submission candidate or transmitted package. FDA eCTD examples refer to CDER/CBER; the technical correction route depends on the actual application, format, submission state and agency instructions. The diagnostic method is proposed operating practice, not a universal agency resubmission procedure.

Sources were checked October 6, 2026. The worked incident below is fictional. It illustrates how to distinguish causes and verify a correction without claiming a real supplier defect or successful agency outcome.

Decide which branch you are in

Do not begin by selecting the newest file. “Wrong version” can mean a draft was selected, an old rendition was reused, a different record with the same title was chosen, or a correct historical source was mistaken for an error. The required version is the one authorized for the task, not necessarily the latest one in the repository.

If other work can continue safely, define its unaffected scope. Do not erase the original evidence, silently overwrite the transmitted archive or mark the issue closed because a corrected PDF now exists on someone's desktop.

Build a five-point evidence chain

Create one incident record with application/program, submission identity, format, publisher release/configuration, discovery time, reporter, expected result, observed result and current release/transmission state. Capture any exact error code and validation report version, but recognize that a semantically wrong source can be technically well formed and produce no format error.

Trace these five points:

1. Authorized source: record identifier, selected revision, permitted use and approval/release evidence.
2. Retrieved input: actual file or repository snapshot, retrieval identity/time and metadata used for selection.
3. Prepared rendition: converted artifact, conversion job/configuration and source relationship.
4. Released package: exact package identity, included artifact, location/lifecycle metadata and release decision.
5. Transmitted package: transfer identity, package evidence and applicable acknowledgements or agency correspondence.

For each point record what is known, its evidence location and what remains unresolved. The package directory a publisher opens today may have changed since transmission. Retrieve the controlled transmitted archive or other authoritative evidence rather than assuming the current working folder is identical.

Checksums can establish whether two byte sequences match a recorded comparison. They cannot establish which version was authorized. A DOCX and its PDF rendition should not be expected to have the same digest; assess their documented conversion relationship and relevant content instead.

Record the source organization's namespace as well as the local identifier when multiple partners use similar numbering. “R-12, final.pdf” is not a globally unique record identity. Keep confidential evidence in the approved incident repository and provide only the necessary material to each investigator.

Locate the first point where the evidence diverges

Work forward from the authorized source. This table uses discriminating observations, not a list of interchangeable fixes.

Treat a path as a hypothesis until the relevant log, configuration or reproducible behavior supports it. “Someone used the wrong file” is an observation about the outcome, not a sufficient explanation of why the process allowed it.

For example, a conversion-cache hypothesis requires evidence that the job reused an output belonging to another input. If the conversion log is absent, record that gap. Do not label the cache the root cause because it seems plausible or because restarting the service removes the symptom.

Apply the correction at the confirmed boundary

A source-selection error needs an eligibility rule tied to the authorized task and record revision. Renaming a file to FINAL does not establish that rule. Verify how the source is selected and how a later draft, older approved version and missing approval are handled.

A rendition-mapping error needs a reliable relationship between the accepted input and generated output. Correct the mapping or reuse condition, regenerate the affected candidate and inspect the relevant content. Include adjacent documents processed by the same job or configuration in the impact assessment.

A package-assembly error needs the right controlled artifact at the intended location, with the correct metadata and lifecycle action. Regenerate affected evidence and repeat the release checks required by your process. A prior approval for a different package does not automatically authorize the revised one.

A transmission-handoff error needs reconciliation of the authoritative transfer source, release identity and delivered package. Avoid an automatic second transmission while the first one's state is unresolved. The intended action might be a retry, a new submission or an agency-directed correction; those decisions are not interchangeable.

Where approval itself is ambiguous, the document owner and regulatory lead must establish the intended content. Engineering cannot resolve a scientific or regulatory decision merely by choosing the largest version number.

If the package has been sent, interpret the receipts

FDA describes ESG NextGen ACK1 as upload information, ACK2 where applicable as transmission information to the Center, and ACK3/ACK4 where applicable as the Center's response. Read the actual status and content rather than treating the presence of an acknowledgement as universal acceptance. FDA submission acknowledgements.

Keep three questions separate: Was this package transmitted? What did the receiving system report? What corrective regulatory action is appropriate for the content issue? A successful delivery result cannot establish scientific correctness, and a local validator cannot tell you which source the organization intended to submit.

FDA supports both eCTD 3.2.2 and 4.0 in their applicable routes; do not infer a correction method from the document's own revision number. Consult the current FDA eCTD overview and the specifications for the application's actual format.

The September 2024 eCTD 3.2.2 Technical Conformance Guide, version 1.9, addresses submission tracking and lifecycle in section 2.5. The June 2026 eCTD 4.0 guide, version 1.5, uses Context of Use and context-group lifecycle; replacement within a group and moving content between groups are distinct. These are reasons to assess the correct lifecycle, not instructions to apply an arbitrary Replace operation to every incident. FDA 3.2.2 guide, FDA 4.0 guide, section 1.5.

Provide the regulatory lead with application/submission identities, exact affected content, expected and actual versions, receipt state, potential impact and proposed correction. Record any necessary agency clarification. This guide cannot supply a universal sequence number, submission type, notification deadline or withdrawal decision for an unspecified incident.

Match each receipt to the affected transfer

Use this separate fictional reconciliation exercise before choosing a resend branch. The incident concerns package P-18 and transfer TX-18; TX-19 belongs to another package. These labels are internal exercise aliases, not prescribed FDA identifier formats. The example assumes a production route where a Center response is applicable.

After the first two rows, the affected package's Center outcome is still unknown. Do not borrow another transfer's receipt because the filenames or submission dates look similar, and do not infer failure solely from missing evidence. The third row resolves that uncertainty; it does not prove the selected document was authorized or scientifically correct. Preserve the correlated receipts and the original package while deciding the appropriate content correction.

Worked incident: the newest file was an unauthorized draft

In the fictional Cedar example, authorization A-90 names study report SR-6 revision 2 for task T-18. Revision 3 is a later draft. Both files have the same display filename. The retrieved input, generated PDF and prepared candidate all contain revision 3; the task has not been transmitted.

The investigator retains A-90, source revision history, retrieval log J-7, conversion record C-7 and candidate P-7. J-7's selection configuration explicitly requests the latest revision without consulting T-18's authorization. A repeat in a synthetic environment selects revision 3 again.

The supported causal chain is:

• Symptom: candidate P-7 contains unauthorized revision 3.
• Immediate trigger: J-7 retrieves the newest revision.
• Contributing condition: a later draft exists with the same display filename, so filename inspection does not expose eligibility.
• Confirmed control defect: the selector has no task-specific authorized-revision condition.
• Blast radius to assess: other tasks using that selector, including cases where the latest revision happens to be approved.

The evidence supports this chain. It does not establish why the original developer chose the rule or whether any other submission was affected. Those remain separate questions, not invented additional “whys.”

The proposed correction is to bind the source selection to the approved task/record/revision and reject unresolved authority. Cedar regenerates the candidate from revision 2 and repeats its applicable preparation and release checks. The example does not claim that a real implementation has passed; the following table defines the retest evidence required.

The original failure is closed only when observed results support the corrected selection and the rebuilt output. A disappearing warning, renamed file or disabled validation rule is not sufficient.

Close with impact, evidence and prevention

Record the final affected population, confirmed cause, correction, retest results, release decision and any agency action. Investigate neighboring paths that use the same selector, converter or handoff. Do not expand the conclusion to unrelated systems without evidence, or assume no impact because the first document reviewed was acceptable.

If diagnosis remains unresolved, prepare an escalation packet containing the five-point chain, exact identities, configuration, relevant logs, preserved artifacts, discrepancy comparison and explicit unknowns. The supplier should receive a reproducible boundary question rather than an unsupported allegation.

For upstream prevention, use the SharePoint-to-publishing handoff checklist where relevant and the broader eCTD submission checklist. If you are evaluating Assyro, bring a synthetic version-selection scenario and require evidence for the proposed workflow before relying on an automated handoff.