taguchi

Replace one-factor-at-a-time debugging with a designed experiment. An orthogonal array covers every pair of factor levels in a handful of runs, so any behavior caused by one factor or by a two-factor interaction is guaranteed to show up in at least one run. 11 binary factors need 12 runs instead of 2048.

Every run changes several factors at once. That feels wrong to debugging intuition — resist the urge to "change only one thing". The analysis is column-wise (compare all runs where factor X was at level 1 vs level 2), not row-wise, and the balance of the array is what makes that comparison fair.

Step 0 — gate

Confirm all of these before proceeding; otherwise use the cheaper tool and say so:

• 3+ candidate factors. One factor → plain bisection. Two factors → just run the 2×2 (4 runs).
• Runs are expensive. If a run is seconds, brute-force the full factorial instead.
• Factors are independently settable. If setting A=2 forces B=2, merge them into one factor.
• At most ~11 factors — that is the 2-level ceiling; 3-level factors cap out at 7 (plus one 2-level) in L18. More than that means the suspect list was never narrowed — shrink it first (the shrink skill in this plugin), then design the array for the survivors.
• The array has to be meaningfully cheaper than the factorial. Three 2-level factors are 4 runs against 8 — a 2x saving that does not pay for the ceremony or for confounding interactions. Below roughly 3x, run the factorial and read the interactions directly; design.py prints the ratio and says so.

Sibling skills cover the neighboring shapes: an expected single culprit among many boolean toggles → shrink; level counts that fit no array below → pairwise; optimizing knobs rather than hunting a culprit → tune.

Step 1 — factors and levels

Build the factor table with the user (or from the debugging context). Force every factor to 2 or 3 discrete levels:

• Boolean or on/off → 2 levels.
• Versions → current vs suspected-bad (2 levels), add a third only if a middle version genuinely discriminates.
• Continuous values (timeout, batch size, memory limit) → the two extremes of the plausible range; a midpoint only as a third level.
• A factor nobody can articulate a level for is not a factor — drop it or fix it at its current value.
• A factor you can observe but not set (region, node shape, neighbor load) is a covariate, not a column: record its value for every run and check it during analysis (step 5).