A Common Technical Document is not one document workflow. It is a stack of modules whose tolerance for generated content varies enormously, and the automation decision has to be made per section rather than per submission. The useful question is not “can AI write our CTD” but “which CTD sections have source data structured enough to support traceable generation, and which sections carry interpretive claims a regulatory reviewer will challenge”.
Those two properties — content lineage and claim-bearing status — are what separate the automatable parts of a CTD from the parts that stay human-authored regardless of model quality. Get the split wrong and you do not merely slow the submission down. You put unverifiable content into a claim-bearing surface, which is a very different class of problem.
Why does the naive approach fail?
The naive approach points a generation model at the template set and treats every module as the same target. It usually starts well, because the first sections attempted are often the most structured ones, and the output looks convincing. The failure arrives later, when the same pipeline is aimed at a Clinical Overview.
Module 5 clinical study listings and Module 3 tabulated data assembly behave nothing like a Clinical Overview. In the first two cases, every sentence or table cell in the output has a determinate origin in a controlled source — a study report, a specification, a batch record, a validated database extract. In the third case, the value the document adds is the interpretation: benefit-risk reasoning, weighing of inconsistent findings, judgement about the adequacy of the evidence base. There is no source row that “produces” that paragraph. A model can imitate its shape without inheriting its authority.
The divergence point is content lineage: sections where every generated sentence traces back to a controlled source are automatable under GxP; sections where the added value is human interpretation are not. That statement is doing more work than it appears to. It means feasibility is a property of the source data, not of the model — and it means two teams with identical tooling can get opposite results because one has structured, versioned, queryable source data and the other has PDFs in a shared drive.
The section-by-section feasibility read
Below is the shape of the read we run with regulatory affairs and quality leads before any automation budget is committed. Feasibility here means “traceable generation is achievable with controlled lineage”, not “a model can produce plausible text” — almost anything passes the second test.
| CTD area | Source data structure | Claim-bearing? | Automation feasibility |
|---|---|---|---|
| Module 1 administrative forms and regional content | High — registry and master-data driven | No | High: assembly and field population, with lineage to master data |
| Module 2 quality overall summary | Medium — draws on Module 3 records | Partly | Medium: tabulated portions assemble; narrative rationale stays authored |
| Module 2.5 / 2.7 Clinical Overview and Clinical Summary | Low — synthesis across studies | Yes, heavily | Low: human authoring stays mandatory; assistive drafting only, under review |
| Module 3 tabulated quality data | High — specifications, analytical results, batch data | No for the tables themselves | High: assembly, reformatting, consistency checking |
| Module 3 narrative justifications (e.g. specification setting) | Medium | Yes | Low to medium: retrieval support, not generation of the argument |
| Module 4 nonclinical study summaries | Medium — report-derived | Partly | Medium: extraction and summarisation with per-sentence provenance |
| Module 5 study listings, tabular summaries, cross-references | High — CDISC-style structured data | No | High: generation with full traceability |
Read the table as a scoping instrument rather than a verdict. The two columns that move a row are the source-structure column and the claim-bearing column; the feasibility column is derived, not independent. When a client improves the structure of their source data — for example by moving specification history out of documents and into a controlled system — rows move up. That is often the cheaper intervention.
What makes a section claim-bearing
A section is claim-bearing when a regulatory reviewer can disagree with it. Listings and tabulations can be wrong, which is a data-integrity problem with a data-integrity remedy. An overview can be contested, which is an argument, and arguments need an accountable human author who can defend them in a question-and-answer cycle and in an inspection.
This distinction matters more than the automation-versus-manual framing because it survives improvements in model quality. A better model narrows the error rate on listings. It does not transfer accountability for a benefit-risk conclusion. In our experience with regulated document workflows, teams that internalise this early spend their automation effort where cycle time is actually available; teams that do not spend it arguing about whether the Clinical Overview draft was “good enough”, which is the wrong question about the wrong section.
The deeper structural pattern here — that regulated AI feasibility is decided by evidence lineage rather than model capability — is developed across the wider regulated-workflow argument on our life sciences AI practice page, where the same split governs analytical and monitoring workflows as well as documents.
Keeping lineage intact
Lineage is not a document property; it is a pipeline property. If a generated Module 5 tabulation cannot be re-derived from a named source version, it is not lineaged, however accurate it is. In practice this means the pipeline records, per generated unit: the source system and record identifier, the extraction or transformation applied, the model and prompt version, the reviewer, and the timestamp — and it means the generation step is deterministic enough to be re-run and compared.
The engineering behind this is ordinary document-understanding and extraction work — layout-aware parsing, table extraction, retrieval over a versioned corpus — combined with the same discipline used for any validated system: pinned versions, reproducible environments (Docker images with fixed dependency sets), and captured artefacts. What makes it regulated is not exotic technology but the audit trail around it. Our validation and audit-trail engagements treat that trail as the deliverable, with the section feasibility split deciding which workflows enter the harness at all.
Two operational signals are worth tracking from the first pilot: the proportion of generated content accepted at first internal review, and the document-quality regression rate after automation is introduced. The first tells you whether the section was correctly scoped. The second tells you whether the pipeline is drifting — a section that passed review in March and fails in September usually indicates a source-schema change nobody flagged, not a model problem.
Sequencing a rollout
Prove the high-feasibility rows first, and prove them with the audit trail switched on rather than as a demonstration. Module 1 assembly and Module 5 listings are the natural starting points because failure there is detectable by comparison against source, so the review burden during validation is bounded. Module 4 and the tabulated parts of Modules 2 and 3 come next, once extraction provenance has been exercised on real data. The Clinical Overview and Clinical Summary do not join the sequence; they gain assistive retrieval — finding the relevant study result, surfacing inconsistencies across reports — while the argument stays authored.
The sequencing rule we apply: never attempt a lower-feasibility section until the audit trail from the previous one has survived a real internal review cycle, not a pilot review. Remediation cost avoided on an unlineaged section is invisible in a business case and very visible in an audit finding.
Frequently Asked Questions
What does ‘what AI document automation can and cannot do for a CTD submission’ mean in practice, section by section?
AI document automation excels at structuring and formatting CTD submissions but struggles with scientific judgment and regulatory strategy. AI Document Automation Cannot has one honest answer. Asked about AI Document Automation Cannot, most engineers point here. AI Document Automation Cannot has one honest answer. It means testing each CTD section against two properties rather than judging the submission as a whole: whether the source data is structured enough for every generated sentence to be traced back to a controlled record, and whether the section’s content carries interpretive claims a reviewer can contest. Sections passing the first test and failing the second are automation candidates. Sections carrying contestable claims stay human-authored.
Which CTD modules and sections are realistic automation targets today, and which are not?
Module 1 administrative content, Module 3 tabulated quality data, and Module 5 study listings and tabular summaries are the strongest candidates, because their sources are structured and the output is not claim-bearing. Module 4 summaries and the tabulated portions of Module 2 are intermediate. The Clinical Overview and Clinical Summary are not realistic generation targets; they take assistive retrieval only.
What makes a CTD section claim-bearing, and why does that change the automation decision?
A section is claim-bearing when a regulatory reviewer can disagree with its content rather than simply find it incorrect. Listings can be wrong and corrected against source; an overview can be contested and needs an accountable author to defend it. Because accountability for an argument cannot be transferred to a model, claim-bearing status caps feasibility independently of model quality.
How do we keep content lineage from source data through to a generated CTD section?
Treat lineage as a pipeline property: record, per generated unit, the source system and record version, the transformation applied, the model and prompt version, the reviewer, and the timestamp — and keep generation reproducible enough to re-run and diff. If a generated section cannot be re-derived from a named source version, it is not lineaged regardless of its accuracy.
Where does human authoring stay mandatory even when the automation performs well — for example the Clinical Overview and Clinical Summary?
Wherever the document’s value is synthesis and judgement across studies rather than faithful restatement of records. The Clinical Overview and Clinical Summary are the clearest cases: benefit-risk reasoning and the weighing of inconsistent findings are the deliverable, and a named author has to stand behind them through question-and-answer cycles and inspection.
How do we test whether a generated CTD section is good enough to enter internal review, and what regression signals do we track?
Gate on lineage completeness first — every unit re-derivable from a named source version — then on comparison against source for factual sections. The signals worth tracking are the proportion of generated content accepted at first internal review, document-quality regression rate after automation, and rework hours on sections later found to be wrongly scoped.
How do we sequence a CTD automation rollout so the highest-feasibility sections are proven before harder ones are attempted?
Start with Module 1 assembly and Module 5 listings, with the audit trail active rather than as a demo, because failure there is detectable against source. Move to Module 4 and the tabulated parts of Modules 2 and 3 once extraction provenance has been exercised on real data. Do not attempt a lower-feasibility section until the previous one’s audit trail has survived a genuine internal review cycle.
The open question, and the one we would rather argue about with a regulatory team than answer in the abstract, is how far up the module stack structured source data can push feasibility before it hits the interpretation wall — and whether that wall sits at the Clinical Overview for everyone, or lower than teams expect.
CTD boundaries every automation vendor needs to respect
Regulatory submissions demand human accountability at specific control points that no ML system should cross. AI Document Automation Cannot rewards teams that measure first and argue later — start with the smallest instrumented slice and let the numbers settle the design.
