EXPERTA

2.1 Questions

1. Can each family run in the browser with the same exactness as Phase 1?
2. For each family, what can the app compute, check and claim, so that each claim is provably correct?
3. What does the literature say about the choice of a design family, by people, by software and by LLMs?
4. How does the flow of the app change?

2.2 Method

• Package facts. A subagent read the CRAN reference manuals, NEWS files and check pages of the seven packages and of RcmdrPlugin.DoE (phase4-research/packages.md).
• Theory of the claims. A second subagent, on the most capable model, read the help pages, papers and source code. It also derived the conditions that the app can check (phase4-research/guarantees.md). The derived statements need a review by Alan R. Vazquez (Section 10.2).
• Literature. A third subagent searched for literature on LLMs and design of experiments, design-selection aids, sequential experimentation and computer experiments. It checked each DOI against Crossref (phase4-research/literature.md).
• Measurements. The controlling session ran each family in native R 4.6.1 and in WebR 0.6.0 (R 4.6.0) in Node, with the runtime of the app (phase4-probes/). The seven new package files came from repo.r-wasm.org with the approval of the author. They are not in git.

Not done in this investigation:

• The start in Chromium with the new packages.
• Qualitative factors in Dopt.design.
• The completeness flag of the column searches of oa.design.
• A review of the derived statements.

2.3 A note on names

• Section 18 (Phase 1 implementation sequence) names four milestones. Milestone 4 is "Evaluation, documentation and video". Section 17.1 uses "Milestone 4" in this sense.
• Section 1.5 names Phase 4 "Other design families". This investigation is about Phase 4.
• Proposal: keep "Phase 4" for the design families, and name its build steps 4A, 4B and so on, as Milestone 3 used 3A to 3C. Keep "Milestone 4" for the evaluation of Phase 1. The authors decide (Section 10.1).

3.1 Packages and size

The WebR index for R 4.6 lists the seven packages that Section 1.9 names, with the same versions. The dependencies of DoE.base (vcd, partitions, numbers, combinat, MASS, lattice, conf.design) are already in the runtime of the app.

No function of a planned family needs Tcl/Tk, a system call or parallel code. Only RcmdrPlugin.DoE needs Tcl/Tk.

3.2 The same design in WebR and in native R

Each design was made with the same call and the same seed in native R 4.6.1 and in WebR 0.6.0. "Identical" compares the full numeric design matrix (desnum), rounded to 12 significant digits.

The type dmax gave a different design in each new native session too (phase4-probes/dice-types.txt), and so did strauss. The cause is in the code: lhs.design calls set.seed(seed) but does not pass seed to DiceDesign::dmaxDesign or straussDesign. Without a seed, these functions take as.numeric(Sys.time()) as the seed (phase4-probes/dice-seed.R). The differential tests of Section 11 would fail for these types, as they must.

3.3 Time

These are Node times on one fast desktop computer. Section 7.9 requires a measurement of the start in Chromium, with the slow profile, before a release. The app should load the packages of a family only when the user confirms that family (Section 1.9), so the start of a two-level design does not change.

3.4 Facts that change the R templates

Argument names differ. Section 1.9 says that the functions share most argument names. The usage lines show this:

Seeds. Section 7.3 says that without randomization the design uses the standard order and the R code has no seed. This rule holds for fac.design, oa.design, ccd.design and bbd.design. It does not hold for lhs.design and Dopt.design: their algorithm draws random numbers, so the R code always needs the seed. ccd.design refuses one seed: "ccd.design needs a seed of length 2" (measured). The rule for the second seed is open (Section 10.1).

Versions. The lhs.design help says that a design repeats "within a package version" only. The project must record the lhs version. The import rule of Section 8.5 already keeps the stored run sheet when a new run differs.

desnum is not one thing.

• For ccd.design and bbd.design, desnum is the coded design.
• For lhs.design, desnum is the design in the unit cube.
• For Dopt.design, desnum is the model matrix, with columns (Intercept), A, ..., A:B.

The report helper must read the design columns of each family in its own way. Also, ffd_cube_matrix of Phase 1 cannot isolate the cube of a central composite design: the app needs a new extractor.

design.info stores few properties.

• ccd.design stores no axial distance.
• No family stores the GWLP.
• Dopt.design stores D, Dea, A and G in optimality.criteria.

The app must compute each property that it shows.

oa.design can return something else.

• If no array fits, it returns a full factorial (type = "full factorial").
• A column search such as columns = "min3" can stop with the warning "resources were not sufficient for optimizing column selection". It then returns the unoptimized allocation (measured: same GWLP as the default).

Random starts. With the default nRepeats = 5, 13 of 30 seeds gave a D-optimal design below the best D found (at most 1.44% lower). With 50 starts, all 30 seeds gave the best D. Time per design in native R: 0.003 s with 5 starts, 0.011 s with 50 starts (20 runs, quadratic model in 4 factors, 81 candidates). This is one example, not a rule. The number of starts must come from a measurement in the browser.

4.1 Four kinds of claim

Rules for all families:

1. The claim follows the returned design, not the request. The app reads design.info(d)$type and the design matrix.
2. A warning is part of the result. A warning that changes the meaning of the design removes each claim that depends on it.
3. Each family has its own post-checks. Phase 1 checks 3 and 4 (balance; coded values in $\{-1, 0, +1\}$) are false for axial runs, Latin hypercubes and most D-optimal designs. Check 7 (each $A_j$ is an integer) is false for non-regular arrays.
4. A property that depends on a model names the model. Rank, D-efficiency and rotatability refer to a model, for example the full quadratic model.
5. The words "optimal", "best" and "minimum aberration" need a bound or a reviewed reference. The name of an algorithm or of an option is not enough.

4.2 General full factorials and orthogonal arrays

Computed properties. $N$ runs, $n$ factors, factor $f$ with $s_f$ levels.

• Strength $t$: for every set of $t$ factors, each combination of levels occurs equally often. This is exact counting.
• GWLP (Xu and Wu, 2001). Code each factor with orthogonal contrasts of mean square 1. For a set $S$ of factors, $X_S$ holds the products of one contrast column per factor in $S$. Then

• A form without contrasts (derived; for review):

For $s_f = 2$, this is the formula of Section 7.6. A consequence: $N^2 A_j$ is an integer for every design, regular or not. Example (measured): the 36-run array for the levels (3, 3, 3, 2, 2) has $A_3 = 2.592593$, and $N^2 A_3 = 3360$. This integer check replaces Phase 1 check 7 for the new families.

• Resolution $R = \min\{j \ge 1 : A_j > 0\}$, and generalized resolution $GR$ and $GR_{\text{ind}}$ (Grömping and Xu, 2014). DoE.base::GR reports 5 for "at least 5".

Independent sources.

Measured: DoE.base::GWLP and an independent contrast implementation agree on 4 designs (phase4-probes/props.R).

Unsafe claims.

• "Optimal", "best array", "minimum aberration", "generalized minimum aberration". DoE.base claims none of them. A GMA claim needs a complete enumeration of the arrays of that size.
• "The columns minimize $A_3$" after the optimization warning, or with the default allocation.
• "Regular" from the flag in the catalogue oacat. The help says that the flag partly relies on a conjecture.
• "Orthogonal array" when the type is "full factorial".
• Alias chains in the style of Phase 1 ("A = BC") for a non-regular array. Aliasing in these arrays is partial.

Proposed claim.

Orthogonal array {ID} from the DoE.base catalogue, {N} runs. Computed from the design table: strength {t}; generalized word length pattern {A3, A4, ...}; generalized resolution {GR, or "at least 5"}. The main effects are orthogonal to each other. If interactions are active, the main-effect estimates can be biased. No optimality claim is made.

4.3 Central composite designs

Computed properties. Coded factors $x_1, \ldots, x_k$; a cube of $F$ runs; $2k$ axial runs at $\pm\alpha$; $n_{c0}$ and $n_{s0}$ center runs in the cube and axial blocks; $N$ runs.

• Axial distance $\alpha$, read from the design matrix.
• Rank of the full quadratic model, with $p = (k+1)(k+2)/2$ terms (plus block columns).
• Rotatability. For a cube of resolution V or more, $[iiii] = (F + 2\alpha^4)/N$ and $[iijj] = F/N$. The design is rotatable if and only if $[iiii] = 3\,[iijj]$, that is $\alpha = F^{1/4}$. Center runs do not change this.
• Orthogonal blocks. For one cube block and one axial block:

Measured.

• The axial distance of ccd.design equals $F^{1/4}$ for alpha = "rotatable", and the formula above for alpha = "orthogonal". This holds for 3 to 6 factors (8 designs; props3.R).
• The default design for 3 factors has the moment ratio $[iiii]/[iijj] = 3.78$, so it is not rotatable. The rotatable designs have the ratio 3.

Unsafe claims.

• "Rotatable" for the default design.
• "Orthogonally blocked" after a change of center runs: $\alpha$ was set for the original numbers.
• "The design estimates the full quadratic model" from the resolution of the cube. The rank decides.
• A singular case (derived): with no center runs and $F = k^2$ (2 factors; 4 factors with a full cube; 8 factors with a 64-run cube), the rotatable $\alpha$ equals $\sqrt{k}$. All runs then lie on one sphere, and the quadratic model cannot be estimated. The rank check finds this.

The card must show the axial settings. For $\alpha > 1$, the axial runs lie outside the ranges in the request. If the user said that a range is a hard limit, the design breaks it. Face-centered designs ($\alpha = 1$) keep the ranges but are not rotatable.

Proposed claim.

Central composite design for {k} factors: {the Phase 1 statement for the cube}, {nc0} center runs in the cube block, {2k} axial runs at distance {alpha} (coded units), {ns0} center runs in the axial block, {N} runs. Computed from the design table: the full quadratic model can be estimated (rank {p} of {p}); rotatable: {yes or no}; blocks orthogonal to the model: {yes, no, or not blocked}. These axial settings lie outside the ranges you gave: {list}.

4.4 Box-Behnken designs

Computed properties.

• Match to the published design. Each Box-Behnken design combines a block design on the factors with full $2^m$ factorials on the factors of each block. The other factors stay at 0. Measured: rsm gives the published support sets for 3 to 7 factors, including the partially balanced design for 6 factors ({1,2,4}, {2,3,5}, {3,4,6}, {1,4,5}, {2,5,6}, {1,3,6}) and the seven triples for 7 factors. Each support block is a full $2^m$ factorial in $\pm 1$ (props3.R, props4.R).
• Rank of the full quadratic model. Without a center run, the sum of the squared columns equals $m$ times the intercept in every run, so the model matrix is singular (derived; Box and Behnken, 1960, Section 5). The app must refuse ncenter = 0.
• Rotatability. Measured ratios $[iiii]/[iijj]$: 2 (3 factors), 3 (4 factors), 4 (5 factors), 1.5 to 3 (6 factors), 3 (7 factors). Only the 4- and 7-factor designs are rotatable, as Box and Behnken (1960) report.

A documentation error in the package. The bbd.design help gives 14 non-center runs for 3 factors. The published design and the measured design have 12.

Proposed claim.

Box-Behnken design for {k} factors, as published by Box and Behnken (1960), with {n0} center run(s), {N} runs. Computed from the design table: it equals the published design; the full quadratic model can be estimated (rank {p} of {p}); rotatable: {yes for 4 and 7 factors, otherwise no}. No run has all factors at their extreme settings.

4.5 Latin hypercube designs

Computed properties on the unit-cube design $x_{uj} \in (0, 1]$, $u = 1, \ldots, n$:

• Latin hypercube property: for each factor $j$, $\{\lceil n\,x_{uj} \rceil : u = 1, \ldots, n\} = \{1, \ldots, n\}$. Each of the $n$ equal intervals holds exactly one run. This is a property of each margin only.
• Minimum distance $d_{\min} = \min_{u < v} \lVert x_u - x_v \rVert_2$, and the centered $L_2$ discrepancy (Hickernell, 1998), with DiceDesign::mindist and discrepancyCriteria as second sources.

Measured (30 seeds, 20 runs, 4 factors; props2.R):

The type "maximin" did not give the largest minimum distance. The name of a type is a search goal, not a property of the result. By default, maximinLHS optimizes on the integer grid and then draws random positions inside the strata.

Unsafe claims.

• "Optimal", "maximin design", "S-optimal".
• "Latin hypercube" for the DiceDesign types dmax, strauss, fact and faure, or after rounding, unless the check runs on the rounded values.
• "Uniform in two or more dimensions" or "orthogonal".

Two technical rules.

• DiceDesign rescales each column by its observed minimum and maximum if a value lies outside $[0, 1]$. The app must pass the unit-cube design.
• lhs.design does not randomize the run order of the lhs types. For physical runs, the help advises randomization.

Proposed claim.

Latin hypercube design of {n} runs for {k} factors, made by lhs::{function} (version {v}) with the seed {seed}. The function is a random search; it does not guarantee the best value of any criterion. Computed from the design table: each factor has exactly one run in each of its {n} equal intervals; minimum distance between runs {dmin} (unit cube); centered L2 discrepancy {CD2}.

4.6 D-optimal designs

Computed properties. Model matrix $X$ ($n \times p$) for the stated formula; candidate set $\mathcal{X}$; $M = X^\top X / n$; $d(x) = f(x)^\top M^{-1} f(x)$.

• Rank of $X$; it must be $p$.
• D criterion $D = \det(M)^{1/p}$. Measured: the app's own value, 0.465609, equals the AlgDesign value 0.466 (props.R).
• G-efficiency $G_e = p / \max_{x \in \mathcal{X}} d(x)$, and AlgDesign's $D_{ea} = \exp(1 - 1/G_e)$.

What the bounds mean (derived; for review). Let $\xi^*$ be the best approximate design on the candidate set for the stated model. Then

Both bounds are relative to the candidate set and to the stated model. $G_e$ is the sharper one. A bound from a near-optimal approximate design (Silvey, Titterington and Torsney, 1978) can be sharper still. In the example, $G_e = 0.604$ and $D_{ea} = 0.519$. Wheeler's vignette for AlgDesign shows a design with $D_{ea} = 0.749$ that is about 97% efficient, so the bounds are loose.

How vendors word this. The JMP help calls a found design "only locally optimal". Design-Expert says that it builds an "approximately optimal design". Both give efficiency relative to an ideal orthogonal design. That reference holds only for two-level models in $\pm 1$ coding (Hadamard's inequality). It does not hold for quadratic models or constrained regions.

Unsafe claims.

• "D-optimal design", "optimal", "the best design".
• "D-efficiency {Dea}". $D_{ea}$ is a lower bound, not the efficiency.
• An efficiency without the model and the candidate set.

Proposed claim.

Design of {n} runs chosen from {Nc} candidate runs by the Federov exchange algorithm (AlgDesign {v}, {r} random starts, seed {seed}) for the model {formula}. The algorithm can stop at a local optimum; it does not guarantee the best design. Computed from the design table: all {p} model terms can be estimated; the D-efficiency, relative to the best possible design on these candidate runs for this model, is at least {100 Ge}%.

4.7 Derived statements for review

These statements come from derivations, not from a source that a person reviewed. Each needs a review by Alan R. Vazquez before the app uses it in a claim:

1. The GWLP form without contrasts, and the integer property of $N^2 A_j$ (Section 4.2).
2. The rotatability and orthogonal-blocking conditions for central composite designs, and the singular case $F = k^2$ without center runs (Section 4.3).
3. The singularity of a Box-Behnken design without center runs (Section 4.4).
4. The bounds $G_e$ and $D_{ea}$ on the D-efficiency, and the bound from an approximate design (Section 4.6).

5.1 LLMs and the design of experiments

• Vazquez, Rother and Charles-Gonzalez (2026) tested two LLMs on the construction of two-level fractional factorials: 36 tasks, 10 repeats each.
  • The models found optimal designs reliably for 8 runs, and up to about 8 factors for 16 and 32 runs.
  • Beyond that, the designs looked correct but had worse aberration, and the results varied over repeats of the same prompt.
  • This is the main evidence for Phase 1's rule that the LLM translates and does not design.
• Ying, Vazquez and Xu (2026) found that the order of the parts of a prompt changes the quality of the designs. This supports the prompt-order arm of Section 12.3.
• Other work uses LLMs to plan chemistry experiments or to guide Bayesian optimization (Boiko et al., 2023; Bran et al., 2024; Ranković, Griffiths and Schwaller, 2025). It measures task success, not the choice of a design family.
• Gap. The search found no study that tests whether an LLM can route a described problem to a design family. The search used few queries, so this is not proven. The routing slice of Section 8 can fill this gap.

5.2 Design-selection aids

• The NIST/SEMATECH e-Handbook (Section 5.3.3) chooses a design from the objective and the number of factors:
  • 2 to 4 factors with a response surface objective: a central composite or a Box-Behnken design.
  • 5 or more factors with a response surface objective: "screen first to reduce the number of factors".
  • Screening objective: full or fractional factorial designs, or Plackett-Burman designs.
• The Minitab Assistant first asks for screening or modeling.
• JMP offers central composite and Box-Behnken designs for up to 8 factors, and space-filling designs for deterministic systems.
• Stat-Ease prefers Box-Behnken designs when the corners of the region cannot be run.
• Early expert systems (Dexter, DXPERT) chose among tabulated designs with rules from consulting statisticians. These are known only from search summaries.

All aids use the same inputs: the objective, the number of factors, the type of each factor, the levels and the run budget. These are the inputs of the decision table in Section 1.9.

5.3 Sequential experimentation

Response surface work is sequential (Box and Wilson, 1951): a factorial design first, then axial runs and center runs for a quadratic model. A central composite design can be built by adding axial runs to a saved two-level design (DoE.wrapper::ccd.augment). The cube should have resolution V. With a cube of resolution III or IV, two-factor interactions stay aliased, and the rank check fails.

5.4 Computer experiments

A deterministic computer code gives the same output for the same inputs. Replication, randomization and blocking then lose their usual role, and space-filling designs replace them (Sacks et al., 1989; Santner, Williams and Notz, 2003). Latin hypercube sampling puts one point in each stratum of each input (McKay, Beckman and Conover, 1979). The routing boundary is the question "Does a run with the same settings give the same result?", not the word "simulation".

5.5 RcmdrPlugin.DoE as prior art for the flow

The menus of RcmdrPlugin.DoE ask, for every family, for a name, the number of factors and their levels or ranges, the number of runs, a seed and randomization. Each family then adds its own inputs:

• Central composite: the cube, the center runs, the axial distance.
• Box-Behnken: 3 to 7 factors, the center runs, blocks for 4 or 5 factors.
• Latin hypercube: the type.
• D-optimal: the candidate design, the model, the constraints and the number of starts.

This is a good model for the family fields of the step 2 card.

6.1 Inputs

6.2 Rules (the first rule that applies decides)

For each family, the pre-checks then test the budget. Examples:

• A quadratic model needs at least $(k+1)(k+2)/2$ runs.
• A Box-Behnken design needs 3 to 7 factors and at least one center run.
• DoE.base::oa_feasible must not refuse the array.

6.3 Clarification questions (fixed choices)

6.4 Boundary pairs for tests and for the evaluation

• "Check for curvature" with two-level factors → a two-level design with center runs; "fit a quadratic model" → a response surface design.
• "We cannot run all factors at their extremes at the same time" → Box-Behnken; "I already have a factorial" → add axial runs.
• Three-level qualitative factors → general factorial or orthogonal array, not a response surface design.
• "Simulation" with a repeatable output → Latin hypercube; "we simulate the process on a pilot line" → a physical experiment.
• Excluded combinations → D-optimal.

6.5 A tension with the scope rule

Section 1.6 says that the tool does not recommend a different approach. Two aids say "screen first" for a response surface goal with many factors. If the table gives this message, the tool recommends an approach. If it does not, the tool makes a large central composite design without comment. The authors decide (Section 10.1).

10.1 For the authors

1. Names. Should the build steps of Phase 4 be named 4A, 4B and so on, and should "Milestone 4" stay for the evaluation of Phase 1?
2. Scope of the paper (already in Section 17.1). Is it Phase 1 alone, with Phase 4 as future work, or a second paper?
3. The second seed of a central composite design. Options: the date seed plus 1, or a second date-based value. The rule must stay under the integer limit of R.
4. "Screen first". Does the decision table give this message for a response surface goal with many factors (Section 6.5)?
5. Analysis. Does Phase 4 make designs only, with the analysis of each family later?
6. Order. Section 1.9 orders the families by risk. The measurements support this order. They also show that DoE.base designs need no new package. Should general factorials and orthogonal arrays come first, possibly before Phase 2?

10.2 For Alan R. Vazquez (to send in one batch with the follow-up of his review)

1. The draft decision table (Section 6.2), especially the rows marked "table choice".
2. The derived statements of Section 4.7.
3. The claim sentences of Sections 4.2 to 4.6.
4. Whether a "near rotatable" statement for Box-Behnken designs with 3, 5 and 6 factors is useful, and on which measure it should rest.
5. The gold families of the routing slice.