eCTD Software Proof of Concept: Fixtures and Demo Checklist

This resource combines an eCTD software demo checklist with a small synthetic input set for a buyer-led proof of concept. It targets FDA eCTD v3.2.2 publishing and lifecycle behavior. It does not assess scientific correctness, replace system qualification, or establish authority acceptance.

Download the POC-34 reference input set

The ZIP contains the four source texts, history and case manifests, expected results, a blank acceptance record and checksums. Download revision 1.1 packages the original inline exercise unchanged. These are synthetic inputs for a v3.2.2 evaluation, not a valid submission or an import-ready vendor project. Build and qualify the regional baseline before running package defects; Assyro’s unsupported v3.2.2 scope remains explicit.

Download the POC-34 synthetic reference inputs (ZIP)

All source content, identifiers, and cases are fictional. No vendor execution was performed for this article. Before running the package checks, you need an appropriately licensed vendor environment, a competent publishing operator, and an otherwise suitable regional baseline generated by the publisher. If those are unavailable, retain the reference work and mark package execution unverified.

Reproduce the reference inputs

The input content is provided here for copying; no download or account is required. Create a folder named poc-34 with a sources subfolder. Use UTF-8 text and preserve sequence numbers as strings, including their leading zeroes. The resource revision is 1, September 14, 2026.

Create four text files under sources. Each begins with these exact two lines:

Synthetic POC-34 training content. Not scientific evidence.
Document: Training overview

Append the three lines defined for each file in this table, one field per line:

The marker makes wrong source selection observable. Version 3 is selected; version 4 must not enter the output merely because it is newer. If the evaluated product needs Word or PDF inputs, the operator must create suitable renditions and retain the mapping to these source texts. These text files are not claimed to be acceptable documents in a real submission.

Save this as history.csv:

sequence,leaf_id,operation,target_sequence,target_leaf_id,source
0000,lfA0,new,,,sources/approved-v1.txt
0001,lfA1,replace,0000,lfA0,sources/approved-v2.txt

This is a reference manifest, not an eCTD XML backbone or a vendor import format. It says that the second historical leaf replaces the first. Have the publisher map those reference IDs to the actual leaf IDs, paths, and document locations used in the practice dossier.

Save this as cases.csv:

case_id,sequence,leaf_id,operation,target_sequence,target_leaf_id,source,loaded_history,us_regional_present
P01,0002,lfA2,replace,0001,lfA1,sources/approved-v3.txt,0000+0001,true
N01,0002,lfA2,replace,0000,lfA0,sources/approved-v3.txt,0000+0001,true
N02,0002,lfA2,replace,0001,lfA1,sources/approved-v3.txt,0000+0001,false
U01,0002,lfA2,replace,0001,lfA1,sources/approved-v3.txt,0000,true

The us_regional_present field specifies the intended condition for the later package exercise. It does not mean a regional XML file has been supplied in this input set. Changing the CSV flag alone is not a test of missing-file detection.

Establish the expected checks before the demonstration

Keep the following table as the expected-result record. Actual vendor results start as not run and remain separate from these expectations.

For v3.2.2, once a leaf is replaced or deleted it is no longer current and cannot be targeted by a subsequent modified-file relationship. That makes N01 different from P01. ICH eCTD v3.2.2, July 16, 2008, Appendix 6.

For the scoped FDA missing-file case, validation criterion 2 addresses a missing us-regional.xml and is classified High. The current criteria PDF is revision 4.6, dated August 17, 2026; FDA's catalog lists support from August 28, 2026. The version of the criteria is not the eCTD format version. FDA validation criteria, FDA v3.2.2 standards catalog.

A vendor may use different local finding identifiers. Assess whether the report identifies the intended condition and supports a useful corrective action; do not require its numbering to impersonate FDA's report.

eCTD software demo checklist: source to retained package

Use this script as the first session, then repeat the cases in the agreed proof-of-concept environment. Give both the operator and buyer witness the expected-result table before starting.

1. Record the scope and environment. Identify the product, edition, release, licensed functions, agency, application context, eCTD version, validator, and active rule revision. Assign each required function to the product or other named tool performing it. If the demonstration requires a separate publisher, record that dependency rather than attributing its output to the authoring product.

2. Select and review the source. Open all four source versions, select approved version 3, and show how the selection is recorded. Introduce the newer unapproved version 4 as a distractor. The retained review and selected output must identify marker 120. Record any manual intervention needed; a successful operator correction is different from automatic prevention.

3. Build and qualify the practice baseline. Have the publisher create appropriate document renditions, the two historical sequences, and the proposed current sequence. Supply the applicable regional metadata, backbones, and other required components. Retain the reference-to-actual mapping and the baseline's validation report with history loaded. If the baseline has unresolved defects, stop the controlled package comparison. An incomplete skeleton can produce many errors without demonstrating that the intended defect was detected.

4. Demonstrate P01 and preserve both views. Inspect the final output, replacement relationship, current view, and retained earlier versions. Export the package and report. The buyer should be able to reconcile the evidence after the session, rather than relying on a sequence of screens that disappears when the call ends.

5. Reset for N01, N02, and U01 separately. Each starts from an identified copy of the qualified baseline. For N01, change only the target to the superseded original. For N02, remove m1/us/us-regional.xml inside the current sequence directory of an exported copy—0002/m1/us/us-regional.xml in the reference numbering—and use the agreed external-file validation route. For U01, withhold sequence 0001 in a separate imported-history workspace. Preserve the master history and each faulty copy.

6. Explain detection, prevention, and repair separately. If a publisher refuses the stale relationship during assembly, retain that result as prevention evidence. If it recreates missing regional XML before export, that demonstrates repair, not necessarily validation of a missing file. Preserve the requested defective input and determine which agreed tool will inspect it. If no external-file validation route is available, mark that check unknown or failed against the buyer's requirement; do not silently replace it with a different task.

7. Close each case before moving on. Record the observed outcome, evidence location, owner, and disposition. A presenter who skips the failed lifecycle step has not completed the script. Keep the failure or unknown visible, assign the next action, and repeat only under a new run ID. Do not overwrite the initial result with the repaired run.

Gateway transmission is outside this reference exercise. If it is mandatory for your purchase, create a separate case for the current authorized agency test route, credentials, acknowledgments, and responsibilities. A local export is not evidence of transmission.

Use the eCTD submission software shortlist to choose candidates before running the same input set with each.

Copy the acceptance record

Use one record per case, including any retest. Brackets below are blank fields to complete, not example results.

Run/case ID and date: [required]
Operator and buyer witness: [required]
Vendor/product/edition/release: [required]
Agency/application context/eCTD version: [required]
Validator/rule revision/effective status: [required]
Input copy and qualified baseline: [required]
Reference-to-actual ID/path mapping: [required]
Loaded history and source selected: [required]
Expected check: [required]
Actual observation: [unknown until run]
Package/report/view evidence locations: [required]
Skipped steps and limitations: [required]
Result: [pass/fail/unknown/N/A with approved reason]
Repair/retest ID: [if applicable]
Buyer owner and disposition: [required]

A negative-control pass means the deliberate defect was correctly identified in the agreed workflow. It does not mean the defective package is acceptable. An approved not-applicable result needs a scope reason; it cannot excuse a mandatory function the product failed to demonstrate.

For example, a hypothetical N01 run that shows a generic dashboard but no target finding or retained report should read: “Actual observation: required lifecycle result not demonstrated; evidence: session notes only; result: unknown; disposition: repeat N01 and retain the report.” It should not inherit a pass from P01 or from the number of other checks completed. This illustrates how to record insufficient evidence; it is not an observed vendor result.

Carry the agreed acceptance outcomes into the eCTD RFP template as inspectable supplier requirements.

Keep the format and product eligibility explicit

Do not apply these leaf targets unchanged to eCTD v4.0. A v4.0 evaluation needs its own Context of Use, document identity, lifecycle, vocabulary, and regional cases. As checked September 14, 2026, FDA's standards page accepts v4.0 for new CDER and CBER applications while describing forward compatibility for existing v3.2.2 applications as a future phase. FDA v4.0 submission standards.

Assyro publishes this resource. Assyro does not currently support eCTD v3.2.2, so this publishing requirement cannot be treated as passed by an Assyro demonstration. If evaluating a different authoring or review scope, agree that narrower boundary and retain the downstream publishing dependency.

The next deliverable is an executed case record with the actual files and reports. This article supplies reproducible reference inputs, expectations, and the script; vendor execution remains unverified. Use the eCTD lifecycle guide for the relationship model and the vendor-selection framework to carry unresolved mandatory cases into the buying decision. No mandatory unknown or failure can be averaged away by a favorable demonstration elsewhere.

For a separate v4.0 evaluation, create and qualify v4.0-specific inputs and expected results before evaluating Assyro eCTD validation with the declared profile. This article’s downloadable fixture is v3.2.2-only, which Assyro does not support.