Design spaceDesign Space (ICH Q8(R2) §2.4)

The design space is a multivariate region of CMAs and CPPs inside which the process has been shown — by experimental data and/or mechanistic understanding — to deliver product that meets all CQAs with acceptable assurance. It is not a single set-point with tolerance bands around it (that's a univariate Proven Acceptable Range, or PAR). It is the joint space, and its shape can be highly non-rectangular: parameters trade off against each other, edges curve, and an interior point may meet spec while a corner of the bounding box does not.

ICH Q8(R2) §2.4 is explicit: 'Working within the design space is not considered as a change. Movement out of the design space is considered to be a change and would normally initiate a regulatory post-approval change process.' That regulatory dividend is the reason design spaces are worth the development investment.

1. Risk-rank the CMAs and CPPs that drive each CQA (output of the initial QbD risk assessment).
2. Choose a DoE that spans the candidate ranges with adequate statistical power — typically a face-centred central composite, response-surface, D-optimal or mixture design depending on the unit operation.
3. Execute at-scale (or scale-down model that is itself qualified) and measure the CQAs at each run.
4. Fit a multivariate response model — linear + interaction terms, often with quadratic terms for response-surface designs; assess fit (R², Q², lack-of-fit, residuals).
5. Compute the predicted CQA at every point in the input space; overlay the acceptance criteria; the intersection is the design space.
6. Account for prediction uncertainty — the boundary should be drawn with a probability-of-success criterion (Bayesian credible region, or response-surface contour shrunk inward by the prediction interval), not at the model-mean boundary.
7. Verify at the edges (edge-of-failure runs) — particularly the corners and the predicted boundary — to confirm the model's extrapolation behaviour and the failure mode at the edge.
8. File the design space in CTD Module 3.2.P.2 (drug product) or 3.2.S.2 (drug substance) with the supporting DoE data, the model, the assumptions and the verification runs.

A design space can be defined at a unit-operation level (e.g. compression: hardness as a function of compression force × dwell time × lubricant level) or end-to-end across the process. Unit-operation design spaces are easier to file and to update; end-to-end design spaces are more flexible but require more model-development effort and stronger justification of the linkages between operations.

Scale-up: a design space defined at lab scale is not automatically valid at commercial scale. The Q8(R2) Annex and Q11 expect either (a) at-scale verification runs inside the design space, or (b) a scientifically justified scale-independent model (e.g. dimensionless number-based equations for mixing, drying or coating). PPQ batches are typically placed at representative interior points of the design space, not at the centre-of-edges.

Evolution: the design space is not static. As CPV data accumulate, as new suppliers introduce new CMA variation, or as the process is intensified, the design space may need to be expanded (regulatory submission, comparability protocol), contracted (CAPA-driven), or refined (improved model). ICH Q12 lifecycle management tools — Post-Approval Change Management Protocols (PACMPs), Established Conditions — are designed for exactly this.

1. Submitting a list of PARs and calling it a design space. PARs are univariate; a design space is multivariate. Regulators see this on Module 3 and downgrade the flexibility.
2. Defining the design space at the model-mean prediction boundary — no allowance for uncertainty. The first variation that lands near the edge fails CQA.
3. No edge-of-failure runs — the regulator has no way to assess what happens just outside the claimed space, which undermines confidence in the boundary.
4. Design space based on a single API lot or single excipient lot — the CMA variation that real supply chains exhibit isn't captured; the model overfits its calibration set.
5. Claiming a broad multivariate space in the filing but writing the batch record to a tight univariate setpoint, so the operational flexibility is never actually used.
6. Crossing 'within the design space' with 'no change control needed for anything' — site changes, equipment changes, material-vendor changes are still change-control events regardless of where in the design space the process runs.

• Recipe holds CPP set-points, PARs and a reference to the filed design space — the kiosk shows the operator both 'recommended setpoint' and 'design-space envelope' for each parameter, so deliberate movement within the space is supported, not punished.
• Multivariate gate at release: the batch's CMA/CPP values are checked against the design-space model, not just the univariate PARs. A combination of in-spec parameters that lands outside the joint space is flagged for QA review.
• Edge-proximity dashboard: per CQA, the platform plots the current batch population against the design-space boundary, so QA can see drift toward an edge before a CQA fails.
• Change control: a proposed move outside the design space, or an expansion of the design space, kicks off a change-control workflow with regulatory-affairs routing — the platform won't let an operator silently run a batch outside the filed envelope.
• Lifecycle: when CPV trends justify expanding/contracting the design space, the new model version is held alongside the previous version; the variation submission, the approval date and the effective batch are all on the design-space record.