DOE Study Designer · PharmTech.AI

1 · Study setup What to do here: name the product and protocol number, set the development stage, and pick your objective — Screening (find the vital few factors) or Optimization (map the response surface). Choose the encapsulation machine and any blocking/nuisance variable. These choices drive every design, the run counts, and the protocol.

Identify the product and the goal. Everything downstream — the designs, the run counts, the protocol — follows from this.

Product / project name Enter the drug product this study characterizes — e.g. "Compound X 25 mg capsule". It appears on the protocol title and headers.

Company / Organization The company or site issuing this study. It is printed on every page of the protocol — in the header at the top and the footer at the bottom — so any page that gets separated from the rest still shows who it belongs to. Enter it once here.

Appears on every page of the protocol header and footer. Enter once.

Protocol / study number Your controlled-document number for this study (e.g. PD-2026-014). It headers the protocol's document-control block and names the CSV / Word exports.

Development stage Where this product sits in its lifecycle — process development, scale-up, tech transfer, or PPQ readiness. Sets the framing and scope wording of the generated protocol.

Unit operations in this study

pick the operations your process actually runs Which operations are you characterizing? Each selected operation gets its own factors, its own responses, its own design and its own protocol sections. Select one to design a study for a single unit operation; select both to cover the whole train. Everything downstream — the setup fields, the parameter tables, the feasibility checks and the protocol — follows this selection.

Study objective Screening finds the vital few factors in the fewest runs (Definitive Screening Design). Optimization maps the response surface of a few factors (face-centered central composite). This choice changes the design the tool builds.

Blender type Tumble/diffusion (V, bin, double-cone) vs high-shear (impeller + chopper) vs ribbon/convective. Changes which blend parameters and ranges Step 2 offers — a high-shear blend uses impeller speed & chopper, not rotation rpm.

Changes which blend parameters are offered.

Blender total capacity — nameplate / geometric (L) What to do: enter the vessel's total nameplate (geometric) capacity — the size on the equipment tag — in litres or cubic feet (toggle the unit at right). Do not pre-derate for headspace: the Fill-level factor in Step 2 applies the working fraction, so the batch mass is total capacity × fill% × poured density. Lab ~1–10 L, pilot ~25–100 L, production ~100–2000 L (1 ft³ ≈ 28.3 L).

Total nameplate capacity — not the working volume (the Fill-level factor derates it). Common sizes are suggested; edit freely.

Blender diameter (m) — optional Optional. The blend vessel's internal diameter, in metres. Used only for the scale-independent Froude number and critical-speed check on a tumble blender. If blank, the radius is estimated from the capacity (cube approximation, ±~30 %).

Optional — sharpens the Froude / critical-speed check; estimated from capacity if left blank.

Encapsulation machine type Dosator (MG2 / Zanasi) vs tamping / dosing-disc (Bosch GKF). Changes which encapsulation parameters and default ranges are offered in Step 2.

Changes which encapsulation parameters are offered.

Blocking / nuisance variable Something that can affect your results but isn't what you're studying — like using more than one raw-material lot, running across different days, or using different operators. If your runs will span one of these, pick it here so the analysis can tell its effect apart from your real factors. If every run is made under the same conditions, leave it "None".

Recorded and analysed as a random effect (automated blocking of the run order is a planned enhancement).

Ambient temperature (°C) Manufacturing / test room temperature, recorded on the protocol for monitoring. Typical controlled suite 20 ± 5 °C — record the actual value.

Recorded on the protocol. Typical controlled suite 20 ± 5 °C.

Ambient relative humidity (%RH) Room humidity, recorded for monitoring. High RH degrades hygroscopic blends (flow loss, weight/assay drift, dissolution shift, gelatin-shell interaction). Typical OSD suite ~35–60 %RH. If RH is your blocking variable, record the actual value per run.

Typical OSD suite ~35–60 %RH.

Moisture sensitivity Blend contains hygroscopic / moisture-sensitive component(s)

Batch formula & materials

the ingredient list — fills the protocol's materials section; enter once Your batch formula. List each ingredient, its role, and its share (%w/w), plus the batch size per run and target fill weight. This same list fills the protocol's materials section. Ingredient cost is optional; where entered it feeds the estimated study cost on the Design step (materials + capsule shells only).

2 · Factors & ranges What to do here: check the process parameters each study will vary, and set realistic low/high ranges — edit anything; you know your equipment and material. Unchecked parameters are held fixed and documented in the protocol. Each active operation needs at least 2 studied factors.

These are the knobs you can turn. We pre-loaded typical parameters and ranges for oral solid dose — edit anything. Check the ones each study will vary; unchecked parameters are held fixed and documented in the protocol. Each active operation needs at least 2 studied factors.

Blending

	Parameter	Low	High	Unit

Encapsulation

	Parameter	Low	High	Unit

3 · Responses & acceptance criteria What to do here: pick the CQAs you'll measure and set each acceptance criterion. These are specifications defining the acceptable region — not per-run pass/fail gates; characterization runs are deliberately pushed off-target to map the edges of failure.

What you will measure, and what "acceptable" looks like. These become the CQAs the design is powered to move, and the acceptance criteria in the protocol.

Blend responses

measured on the blend

	Response (CQA)	Acceptance criterion

Encapsulation responses

measured on filled capsules

	Response (CQA)	Acceptance criterion

These are CQA specifications, not per-run pass/fail gates. In a characterization DOE you deliberately push some runs off-target (e.g. short dosing length → low fill weight) to map the edges. Runs are judged by how they inform the model and the acceptable region — not by whether each one meets spec.

Before you trust any of these numbers: the measurement system must be capable first. A blend-uniformity RSD is meaningless if the assay's own variation rivals the effect you're chasing. The protocol gates the DOE behind a Gage R&R check with numeric criteria (%GRR ≤ 30 %, ndc ≥ 5).

4 · Recommended designs & review What to do here: review the recommended design and randomised run matrix for each study. Tune the centre points and seed, and enter a response σ (and a target Δ) to size the smallest effect the design can detect. Export a run sheet (CSV) if you want it on the floor.

Draft Study Protocol (Pre-Protocol Design Aid) What to do here: review the assembled QbD/GMP protocol, complete the editable fields (equipment IDs, materials/lots, dates, signatures), then export to Word or print. Fill in every field and route it through your quality system before use. draft for review

Assembled from your inputs and mapped to ICH / FDA expectations. Fillable fields are editable; complete them, then export.

Unit operations in this study

Batch formula & materials

Blending

Encapsulation

3 · Responses & acceptance criteria iWhat to do here: pick the CQAs you'll measure and set each acceptance criterion. These are specifications defining the acceptable region — not per-run pass/fail gates; characterization runs are deliberately pushed off-target to map the edges of failure.

Blend responses

Encapsulation responses

3 · Responses & acceptance criteria What to do here: pick the CQAs you'll measure and set each acceptance criterion. These are specifications defining the acceptable region — not per-run pass/fail gates; characterization runs are deliberately pushed off-target to map the edges of failure.