Everything in this chapter has been preparation for this moment: building one complete, end-to-end AI-integrated workflow that takes a finalized TLF package on one end and produces a publishing-ready Module 2.5 Clinical Overview on the other, with every step classified, every handoff gated, and every action written to the Veeva Vault QualityDocs audit trail. This is not a drafting exercise; it is the assembly of the map from Chapter 1 Lesson 1, the verification gates from Lesson 2, and the validated-workflow discipline from Lesson 3 into a single operating pipeline that an FDA Office of New Drugs reviewer could trace from the first AI touch to the signed conclusion. The pipeline has six stages: TLF intake, Module 2.7.3 and 2.7.4 sub-summary drafting, the integrated Module 2.5 draft, the cross-Module consistency check across 2.5, 2.7, and the CSR, reference QC, and the publishing-ready handoff. At each stage the question is the same one you have been trained to ask: what class is this step, what is the gate, who signs, and what does the audit trail record. By the end you will have a workflow you could install, qualify, and defend, not a clever prompt you could not.

Stage One: TLF Intake and Source-of-Truth Binding

The pipeline begins not with a prompt but with the binding of the source of truth, because every downstream claim will be reconciled against what you load here, and the Level 1 lesson on the context window established the unforgiving rule: a missing source is a silence, not a flag. TLF intake takes the finalized, statistically QC-approved Tables, Listings, and Figures package, the one that exists after the dry-run review in weeks 3 to 5 of the CSR cycle, and binds it as the authoritative source against which the workflow will reconcile every efficacy and safety number. This binding is consequential because the whole defensibility of the pipeline rests on the AI reasoning over the real, final TLF and not an interim cut, and a workflow that drafts the 2.7.3 from a preliminary TLF and then reconciles against the final one will surface a flood of discrepancies that look like AI errors but are actually a source-control failure at intake.

Intake is therefore a gated step in its own right, even though no narrative is generated yet, because what gets bound here determines whether everything downstream is trustworthy. The intake gate confirms that the loaded TLF is the finalized version under the correct version label, that the analysis populations and the SAP-defined endpoints in the loaded package match the protocol and SAP of record, and that the binding is recorded in the audit trail with the TLF version identity and timestamp. In a retrieval-augmented configuration, intake also confirms that the TLF tables are correctly chunked and indexed so that retrieval pulls the right cell when a downstream claim needs to reconcile against it, because a retrieval layer that returns the wrong table is a silent source of fabricated-looking reconciliation. The signatory at intake attests that the bound source is the version of record, which is the foundation every later attestation stands on.

This stage embodies the Lesson 3 IQ discipline in operation: the source-of-truth connection is one of the installed configuration items, and intake is where its correctness is confirmed for this specific run. A mature pipeline does not treat intake as administrative; it treats it as the moment the workflow's entire chain of reconciliation is anchored, because an error here does not produce a wrong sentence, it produces a wrong foundation, and a wrong foundation propagates undetected through every stage that trusts it. The discipline of binding and recording the exact TLF version at intake is what lets the Day 74 reviewer confirm, definitively, that the numbers in the Clinical Overview trace to the same TLF the rest of the dossier was built on.

Stage Two: Module 2.7.3 and 2.7.4 Sub-Summary Drafting

With the TLF bound, the pipeline drafts the Module 2.7.3 Summary of Clinical Efficacy and the Module 2.7.4 Summary of Clinical Safety, and these are the workhorse AI-ready steps of the whole workflow, because the cognitive task is transformation of finalized table contents into structured summary narrative against fixed ground truth. The AI takes a finalized efficacy table and produces the corresponding 2.7.3 results paragraph, takes the adverse-event summary tables and produces the 2.7.4 safety narrative, and at each the verification gate is a reconciliation: every numeric claim, every population statement, every directional comparison, and every cross-reference in the draft is checked against the source cell it came from. This is the table-to-narrative gate from Lesson 2, now instantiated at production scale across the dozens of paragraphs that make up the two summaries.

The reason 2.7.3 and 2.7.4 come before the 2.5 is architectural and not merely sequential, and it reflects the actual structure of the CTD: the Module 2.7 summaries are the detailed clinical summaries from which the Module 2.5 Clinical Overview is integrated, so the workflow builds the foundation summaries first and reconciles them to the TLF, then integrates upward. Drafting the 2.5 before the 2.7 would invert the dependency and force the integrated overview to reconcile against summaries that do not yet exist, whereas building 2.7 first means the 2.5 integration in the next stage reconciles against already-verified summaries plus the TLF, a far stronger position. Each 2.7.3 and 2.7.4 paragraph that passes its reconciliation gate becomes a verified building block, carrying its own audit-trail record of model version, sources, dispositions, and signatory, and the integrated 2.5 will be assembled from blocks that are individually defensible.

There is a discipline here that the consistency-check stage will later depend on: every claim in the 2.7.3 and 2.7.4 must carry its source linkage, the specific TLF table and cell it reconciles to, recorded at the gate. This source linkage is what makes the cross-Module consistency check in Stage Four tractable, because consistency is checked not by comparing prose to prose but by comparing each module's claims to the common source. A 2.7.3 drafted without recorded source linkage produces verified-looking paragraphs that cannot later be cross-checked efficiently, so the gate's record must capture not just that the claim reconciled but what it reconciled to, turning each summary into a set of source-anchored claims rather than a block of text.

Stage Three: The Integrated Module 2.5 Draft and Its Prohibited Core

The third stage integrates the verified 2.7 summaries into the Module 2.5 Clinical Overview, and this is the stage where the three-class discipline from Chapter 1 Lesson 1 does its most important work, because the 2.5 is not uniform in class. Much of the Clinical Overview is AI-assistive integration: the model synthesizes the verified efficacy and safety summaries into the concise integrated narrative the 2.5 requires, condensing and connecting content that has already been reconciled, and the human adjudicates whether the integration faithfully represents the underlying summaries without introducing claims that exceed them. This is genuinely useful AI work, because integrating a 2.7.3 and a 2.7.4 into a coherent 2.5.4 and 2.5.5 is a synthesis task the model accelerates, and the gate here checks that no integrated claim overstates or distorts the verified summary it derives from.

But the Module 2.5 contains the single most important AI-prohibited step in the entire submission, the integrated benefit-risk assessment in Module 2.5.6, and the pipeline must enforce its exclusion boundary exactly as Chapter 1 and the Level 1 limits-of-reasoning lesson established. The model may assemble the balanced inputs to the benefit-risk discussion, laying out the magnitude and durability of the efficacy alongside the frequency and severity of the key safety findings drawn from the verified summaries, but the conclusion that the benefit outweighs the risk in the indicated population is authored by the named signatory, not generated. The gate at 2.5.6 is the exclusion-boundary gate: its record affirmatively shows that AI involvement stopped at the structured scaffold and that the human authored the verdict, so that the audit trail proves, rather than merely asserts, that the most consequential judgment in the dossier originated with an accountable person.

This stage is where a less disciplined team destroys an otherwise excellent pipeline, by letting the model carry its fluent integration straight through into a benefit-risk conclusion because the prose flows naturally from the inputs to the verdict. The flow is exactly the danger: a model that has just integrated the efficacy and safety summaries will, if unprohibited, produce a confident benefit-risk sentence that reads like the natural conclusion, and that sentence is precisely the AI-authored conclusion the accountability principle forbids. The pipeline's design must make the 2.5.6 boundary a hard stop in the tooling, not a reminder in a procedure, so that the integrated draft arrives at the benefit-risk section with the scaffold built and the verdict line empty, awaiting the named author whose signature will own it.

Stage Four: The Cross-Module Consistency Check Across 2.5, 2.7, and CSR

Stage Four is the canonical AI-assistive step of the whole pipeline and the one that delivers a capability no human team can match at scale: checking consistency across the Module 2.5, the Module 2.7 summaries, and the underlying CSR, so that a hazard ratio stated in the 2.5.4 matches the value in the 2.7.3 which matches the CSR Section 11 result which matches the TLF cell. The AI reads across all three levels and flags every discrepancy, a number that differs between modules, a population that is described differently, a cross-reference that points to different targets, and it surfaces these as a worklist for human adjudication. This is the second-set-of-eyes capability that never tires across the thousands of claims in a Module 2 package, and it catches the propagation errors the Level 1 lesson warned about, where a single value carried inconsistently across modules signals that at least one instance is wrong.

The critical design point, carried directly from Lesson 2, is that the AI flags but does not resolve: every discrepancy it surfaces is adjudicated by a human against the common source of truth, the TLF, and the adjudication is recorded with its rationale. When the consistency check flags that the 2.5.4 states a median PFS that differs from the 2.7.3, the human does not accept whichever the model prefers; the human goes to the TLF cell, determines the correct value, corrects the erring module, and records a disposition showing which value was authoritative and why. The gate's acceptance criterion is that every flagged discrepancy is dispositioned and grounded in the TLF, and the danger this stage must design against is over-trust, the temptation to let the AI's confident flag-and-suggest output stand as if the suggestion were the resolution, when the suggestion is only a prompt for a human to reconcile.

This stage is also where the source linkage captured in Stage Two pays off, because the consistency check is dramatically more tractable when each module's claims are already anchored to their TLF sources. Rather than comparing the prose of three documents and hoping to notice a mismatch, the check compares each module's source-anchored claims against the common TLF, turning a fuzzy editorial task into a structured reconciliation across a known claim set. The consistency check is, in effect, the workflow auditing itself before the reviewer does, and a clean disposition record from this stage, showing discrepancies found, adjudicated, and corrected against the TLF, is among the strongest pieces of evidence the pipeline can present that its cross-Module integrity is real and not assumed.

Stage Five: Reference QC and the Cross-Reference Reckoning

Stage Five is the reckoning for the failure mode this entire program has circled since Level 1: the fabricated cross-reference, the citation to a Table 14.2.1.4 that does not exist, which survives spell-check and a hasty reviewer and lands as an Office of New Drugs Information Request on Day 74. Reference QC verifies that every cross-reference in the Module 2.5 and the 2.7 summaries, every citation to a TLF table, a CSR section, or a sub-summary, points to a target that actually exists and contains what the citing sentence claims it contains. This is partly an AI-assistive step, where the AI enumerates every cross-reference and checks each against the bound TLF and the CSR structure, flagging any citation whose target cannot be located or whose target does not contain the claimed result, and partly a human reconciliation of every flag the enumeration produces.

The reason reference QC is its own stage rather than a sub-task is that cross-references are the highest-risk content class, as Chapter 1 established, and they fail in a way that is invisible to the consistency check: a citation can be internally consistent across all three modules and still point to a nonexistent table if the same fabricated reference propagated everywhere, which is exactly what happens when a 2.7.3 fabrication is integrated into the 2.5 and the consistency check finds them consistent with each other. Reference QC is the stage that checks citations against the actual target rather than against each other, and it is the only stage that catches a uniformly-propagated fabrication. The gate's acceptance criterion is absolute and follows the Level 1 rule: every cross-reference resolves to a real target containing the claimed content, and any uncheckable citation is treated as wrong until proven right, blocking the document until the citation is corrected or removed.

Reference QC is also where the timing discipline from the CSR-cycle map matters, because the Level 1 lesson noted that a reference manager run before the TLF is finalized validates citation format against a target that may not yet exist. In this pipeline, reference QC runs against the finalized, intake-bound TLF, so a cross-reference that format-validates is also checked against a real, final target, closing the gap that lets format-valid fabrications through. The disposition record from this stage, showing every cross-reference enumerated, located, and confirmed against the final TLF, is the direct answer to the Day 74 question that opened this program: the reviewer who asks the sponsor to reconcile a stated result against its cited table finds that the pipeline already did exactly that, with a logged record naming the verifier and the target, for every citation in the Clinical Overview.

Stage Six: Publishing-Ready Handoff, the Audit Trail, and Module 1.14

The final stage hands the verified Module 2.5 to the publishing team, and the handoff is itself a gate with a signatory who attests that every prior gate is complete: that the TLF was bound and version-recorded at intake, that the 2.7.3 and 2.7.4 claims were reconciled with recorded source linkage, that the 2.5 integration was adjudicated and the 2.5.6 benefit-risk conclusion was human-authored under its exclusion boundary, that the cross-Module consistency discrepancies were dispositioned against the TLF, and that every cross-reference resolved to a real final target. This terminal attestation is not a new verification; it is the confirmation that the chain of verifications is complete and unbroken, and it is the point at which the named author of the Clinical Overview takes ownership of the integrated document under a Part 11 Subpart C signature.

The audit trail that this pipeline writes to Veeva Vault QualityDocs is, by construction, the complete and ordered record of every gate firing, and this is the deliverable that makes the workflow defensible rather than merely fast. For each AI-touched action it carries the model and version, the system prompt identity, the sources loaded, the verification object, the per-claim dispositions, the named verifier, the signatory, and the timestamps, organized so the sequence reconstructs the six-stage pipeline. The QualityDocs lifecycle binds each stage to a controlled document state, so advancement from one stage to the next is technically conditioned on the prior gate's completed record, which is the Lesson 2 enforcement principle and the Lesson 3 OQ property operating in production: the non-compliant path of advancing without a record is blocked by the system, not left to discipline.

When the AI involvement in producing the Clinical Overview rises to the level that disclosure is warranted under the transparency principle, the pipeline writes an AI use-log summary to the Module 1.14 administrative section, and because that summary is generated from the classified, gated, audit-trailed pipeline rather than reconstructed after the fact, it is both accurate and defensible. The Module 1.14 entry states which stages AI touched, the class of each, the controls applied, and the fact that the benefit-risk conclusion was human-authored, and it is substantiated line by line by the QualityDocs audit trail beneath it. This is the destination the entire program has been building toward: not a faster draft, but an integrated, validated, fully traceable workflow whose answer to "how was AI used to produce this Clinical Overview, and how do we know it is trustworthy" is a coherent, evidenced, inspectable account rather than a hopeful assertion, and whose author can sign the Module 2.5 cover knowing exactly what they are attesting to and exactly what record stands behind it.

Key Takeaways

• The Module 2.5 pipeline is six gated stages assembled from the chapter's discipline. TLF intake, 2.7.3/2.7.4 sub-summary drafting, integrated 2.5 draft, cross-Module consistency check, reference QC, and publishing-ready handoff, each with a defined class, gate, signatory, and Veeva Vault QualityDocs audit-trail record, so the whole pipeline is traceable from first AI touch to signed conclusion.
• Intake binds the source of truth, and 2.7 is built before 2.5 because the CTD integrates upward. Binding the finalized, version-recorded TLF anchors every downstream reconciliation, and drafting the verified 2.7.3/2.7.4 summaries first means the 2.5 integration reconciles against already-verified blocks plus the TLF rather than against summaries that do not yet exist.
• The Module 2.5.6 benefit-risk conclusion is a hard exclusion boundary, not a reminder. The model assembles the balanced efficacy-and-safety inputs, but the verdict that benefit outweighs risk is human-authored, and the tooling must arrive at 2.5.6 with the scaffold built and the verdict line empty so a fluent integration cannot flow into an AI-authored conclusion.
• The consistency check flags and reference QC catches the propagated fabrication. Consistency checks each module's source-anchored claims against the common TLF and a human adjudicates every flag, while reference QC alone catches a uniformly-propagated fabricated cross-reference by checking each citation against the real final target rather than against the other modules.
• The audit trail is the deliverable, and Module 1.14 is generated from it. QualityDocs records every gate firing in order with full metadata, advancement is technically conditioned on the prior gate's completed record, and the Module 1.14 AI disclosure is substantiated line by line, turning "how was AI used and how do we know it is trustworthy" into an evidenced, inspectable account on Day 74.