If the drug-substance section is a dossier about a molecule, the drug-product section is a dossier about a process and a package, and that shift changes the shape of the AI workflow that builds it. Module 3.2.P, sections 3.2.P.1 through 3.2.P.8, describes the finished dosage form: its composition, the pharmaceutical development that justifies the formulation, the manufacturer and the manufacturing process, the control of excipients, the control of the drug product, the reference standards, the container closure system, and stability. Where 3.2.S is dominated by a single anchor artifact, the specification, 3.2.P is dominated by relationships: a process description that must reconcile to a batch record, in-process controls that must trace to critical process parameters, a container closure system whose integrity must be demonstrated and whose compatibility governs stability, and a development narrative that must justify why the formulation and process are what they are. This lesson designs the end-to-end AI workflow for 3.2.P, and it argues that the central discipline here is not just transcription fidelity but relational coherence, because the most common drug-product defect is not a wrong number but a section that contradicts another section a reviewer reads alongside it.

What the 3.2.P Section Actually Is, Section by Section

Module 3.2.P has eight subsections, and like 3.2.S each answers a distinct regulatory question from a distinct source. Section 3.2.P.1 is the description and composition of the drug product, the dosage form and the qualitative and quantitative composition with the function of each component. Section 3.2.P.2 is pharmaceutical development, the section that explains and justifies the formulation, the manufacturing process, the container closure, and the microbiological and compatibility attributes, and it is where the ICH Q8 quality-by-design rationale lives, including any design space, critical quality attributes, and critical process parameters identified during development. Section 3.2.P.3 is manufacture, the manufacturer, the batch formula, the description of the manufacturing process and process controls, the controls of critical steps and intermediates, and process validation, and it is the home of the batch record and the in-process controls.

The remaining subsections govern control and the package. Section 3.2.P.4 is the control of excipients, their specifications and analytical procedures and the justification of those specifications, including any human or animal origin considerations. Section 3.2.P.5 is the control of drug product, the specification, the analytical procedures and their validation, batch analyses, characterization of impurities, and justification of specification, paralleling 3.2.S.4 but for the finished product. Section 3.2.P.6 is reference standards or materials. Section 3.2.P.7 is the container closure system, its description, materials of construction, and the suitability evidence covering protection, compatibility, safety, and performance. Section 3.2.P.8 is stability, paralleling 3.2.S.7 but governed additionally by the in-use stability and the interaction with the container closure. The workflow has to recognize that 3.2.P.2 development, 3.2.P.3 manufacture, 3.2.P.5 control, 3.2.P.7 packaging, and 3.2.P.8 stability are not independent narratives but a single argument that the formulation, process, and package together deliver a product that meets its specification throughout its shelf life, and that the relationships among them are where defects hide.

The Intake Layer and the Relational Source Map

The intake layer for 3.2.P resembles 3.2.S in principle, controlled and versioned sources rather than pasted text, but the source set is more relational. The master batch record and the batch formula enter as the source for the 3.2.P.3 process description and the in-process controls. The pharmaceutical development report enters as the source for 3.2.P.2 and carries the critical-quality-attribute and critical-process-parameter definitions that the in-process controls and the validation must trace back to. The drug-product specification and the analytical method validation reports enter as the source for 3.2.P.5, exactly as in 3.2.S.4. The container closure specifications, the extractables and leachables studies, and the container closure integrity data enter as the source for 3.2.P.7. The stability program, including the in-use stability data, enters as the structured numeric source for 3.2.P.8.

What makes the intake layer different is that the workflow does not just load these sources; it builds a relational source map that records which sources govern which claims and which claims must agree across subsections. A critical process parameter defined in the 3.2.P.2 development report must appear as a controlled parameter in the 3.2.P.3 process description and must be within the range that process validation demonstrated. An in-process control in 3.2.P.3 must trace to a critical quality attribute it is there to control. The container closure described in 3.2.P.1 and 3.2.P.7 must be the container in which the 3.2.P.8 stability was conducted. The relational source map is the workflow's model of these dependencies, and it is what lets the coherence check, later, ask not merely "is this claim true" but "does this claim agree with the claim it depends on in another subsection." This is the structural answer to the relational nature of the drug-product dossier, and it is built at intake, before the model drafts a word.

Process Description and In-Process Controls, the Traceability Chain

The process description in 3.2.P.3.3 and the controls of critical steps in 3.2.P.3.4 are the relational heart of the drug-product section, because they connect the development rationale to the manufactured reality. A process description is a sequence of unit operations, each with its parameters, and the in-process controls are the tests and limits applied at defined points to keep the process within the bounds that development established. The risk is not primarily that the model invents a step, though it can; the risk is that the model produces a process description that is plausible and internally smooth but disconnected from the batch record, omitting a control the batch record requires, or stating a parameter range that does not match the validated range, or describing an in-process control without tracing it to the critical quality attribute it exists to protect.

The workflow therefore drafts the process description from the master batch record under the same transcription discipline as a specification, reconciling each unit operation and each parameter to the batch record, and then runs the relational trace: each critical process parameter in the description is matched to its definition in the 3.2.P.2 development report and to its demonstrated range in the process validation, and each in-process control is matched to the critical quality attribute it controls. A critical process parameter that appears in the process description but was never identified in development, or an in-process control with no attribute to justify it, or a parameter range in the description that the validation did not cover, is a relational defect that a transcription check alone would pass, because the description can be a faithful transcription of a batch record that itself is inconsistent with the development and validation story. This is the failure mode the relational source map exists to catch, and it is the one an OPQ reviewer is trained to find, because an unjustified or unvalidated process control is a control strategy the sponsor cannot defend.

The Container Closure System, the Package as Evidence

Section 3.2.P.7 introduces a class of claim that has no analogue in the drug-substance section: the suitability of the container closure system, which is demonstrated through protection, compatibility, safety, and performance, and which is the gateway to the stability conclusion. The container closure is not merely described; it must be shown to protect the product from light, moisture, and oxygen as needed, to be compatible with the product such that extractables and leachables do not compromise it, to be safe for its intended use, and to perform as a delivery system where applicable. The supporting evidence, the extractables and leachables studies, the container closure integrity testing, the moisture and light protection data, is technical and quantitative, and the model is prone to summarizing it with reassuring conclusions, "the container closure system was demonstrated to be suitable for its intended use," that may overstate what the studies showed.

The workflow treats container closure suitability as an interpretive claim subject to the challenge discipline, not a transcription. A suitability conclusion is surfaced with the specific extractables, leachables, integrity, and protection results that support it, and the question routed to the named author and the packaging or quality expert is whether those results compel the conclusion or merely accompany it. The relational dimension is critical here too: the container closure that 3.2.P.7 demonstrates suitable must be the exact container in which 3.2.P.8 stability was conducted, because stability data generated in a different package does not support the shelf life of the marketed package. A workflow that builds 3.2.P.7 and 3.2.P.8 independently can produce two internally clean subsections that describe two different packages, a coherence defect that escapes both and that directly undermines the shelf-life claim. The relational source map links them, and the coherence check enforces that the package of suitability is the package of stability.

Drug-Product Stability and the In-Use Dimension

Section 3.2.P.8 parallels the drug-substance stability section and inherits its discipline, trends computed from structured data rather than paraphrased, extrapolation beyond real-time coverage flagged as an ICH Q1E justification, the narrative and protocol and data tables built from one source so they cannot disagree. But drug-product stability carries dimensions the drug substance does not. It is conducted in the marketed container closure, so it depends on the 3.2.P.7 package. It often includes an in-use stability study, the data supporting the period over which the product remains acceptable after first opening or after reconstitution, which is a distinct claim with its own conditions and its own acceptance criteria. And it must account for the photostability and the temperature excursions the dosage form may experience, which for a biologic drug product can be the controlling stability risk.

The workflow extends the structured-stability discipline to these dimensions. The in-use stability data is extracted as its own structured dataset, the in-use period is computed from it rather than asserted, and any in-use claim in the narrative is reconciled to the computed result, because an in-use shelf life is exactly the kind of operationally consequential number a model will state plausibly and a pharmacist will rely on. The shelf-life conclusion is built from the long-term data in the marketed package, with extrapolation handled under Q1E, and the in-use period is built from the in-use study, and the two are kept distinct so the model does not conflate them into a single reassuring statement. The relational check then confirms that the storage statement the 3.2.P.8 stability supports is the storage statement the product labeling will carry, closing the loop between the dossier's stability evidence and the instruction a patient will actually receive.

The Coherence Check as the Primary Control

For the drug-product section, the cross-subsection coherence check is promoted from a final verification step to a primary control, because the dominant defect class in 3.2.P is relational rather than transcriptional. The coherence check walks the relational source map and tests every cross-subsection dependency: that every critical quality attribute in the 3.2.P.5 specification was identified in 3.2.P.2 development; that every critical process parameter in 3.2.P.3 traces to development and is within the validated range; that every in-process control protects a named attribute; that the container closure in 3.2.P.1, 3.2.P.7, and 3.2.P.8 is the same package; that the analytical methods in 3.2.P.8 stability are the validated methods in 3.2.P.5; that the storage statement in stability matches the proposed labeling. Each of these is a relationship that can be broken without breaking any single subsection.

This is why a 3.2.P workflow that only reconciles each subsection to its own source will pass content that an OPQ reviewer rejects. A specification listing an attribute the development never identified, a stability study run in a package the suitability section never demonstrated, an in-process control with no quality attribute behind it, are each internally clean and relationally broken. The coherence check is the control that sees what subsection-internal verification cannot, and it produces a defect that, like the interpretive failures, routes to the named author rather than resolving automatically, because deciding how to close a coherence gap, whether to correct the description, add the missing development justification, or re-scope the claim, is a judgment about the control strategy. The traceability spine and the audit trail carry the same Part 11 and Annex 11 weight as in the drug-substance workflow, but in 3.2.P the spine records relationships as well as sources, because the relationships are the evidence that the formulation, process, and package form one coherent control strategy.

Operating the Workflow: The Control Strategy as the Deliverable

In operation, the 3.2.P workflow produces not a stack of eight independent subsections but a single coherent control-strategy argument, assembled in a sequence that respects the dependencies. The intake gate confirms the sources and builds the relational source map. The development section 3.2.P.2 is established first, because it defines the critical quality attributes and critical process parameters that everything downstream must trace to. The process description and in-process controls in 3.2.P.3 are drafted from the batch record and traced to development and validation. The drug-product specification in 3.2.P.5 is transcribed and reconciled cell by cell, exactly as in 3.2.S.4, with each attribute traced to its development origin. The container closure suitability in 3.2.P.7 is built and challenged. The stability in 3.2.P.8 is computed, with the in-use dimension kept distinct, in the demonstrated package.

The coherence check then runs across the assembled section, and every relational defect routes to the named author for a control-strategy decision, not an automatic fix. The traceability spine, now carrying relationships as well as source links, and the captured audit trail make the section defensible at the Pre-Approval Inspection and answerable to an OPQ information request that asks how a particular control is justified and validated. The completed 3.2.P, with its 3.2.S counterpart, then becomes the verified source for the Module 2.3 Quality Overall Summary, which must reconcile to both. The model drafted the subsections and surfaced the relationships; the named CMC author owns the control strategy, owns the shelf-life and in-use claims, and signs the section, because the signature attests that the formulation, the process, the package, and the stability evidence form one argument the manufacturing site can execute and the product can meet for the life of every lot.

Key Takeaways

• Module 3.2.P is a dossier about a process and a package, so its central discipline is relational coherence, not just transcription fidelity. The eight subsections from 3.2.P.1 composition through 3.2.P.8 stability are a single argument that the formulation, process, and package deliver a product that meets its specification throughout shelf life, and the relationships among them are where defects hide.
• The intake layer builds a relational source map that records which claims must agree across subsections, so the coherence check can ask whether a claim agrees with the claim it depends on, not merely whether it is true. A critical process parameter in 3.2.P.3 must trace to its definition in 3.2.P.2 development and its demonstrated range in process validation, and an in-process control must protect a named critical quality attribute.
• The process description and in-process controls are the relational heart: a faithful transcription of a batch record can still be relationally broken. A critical process parameter never identified in development, a control range the validation did not cover, or an in-process control with no attribute to justify it is an unvalidated control strategy an OPQ reviewer is trained to find and a transcription check alone would pass.
• The container closure of suitability must be the container closure of stability, or the shelf-life claim is undermined. Container closure suitability is an interpretive claim subject to the challenge discipline, and a workflow that builds 3.2.P.7 and 3.2.P.8 independently can produce two clean subsections describing two different packages, a coherence defect that escapes both.
• In 3.2.P the cross-subsection coherence check is promoted to a primary control, because the dominant defect class is relational rather than transcriptional. Drug-product stability adds an in-use dimension computed as its own structured dataset and kept distinct from the shelf-life claim, and every relational defect routes to the named author for a control-strategy decision, because the model drafts the subsections but the author owns the control strategy.