Common Pitfalls

Statistical process control is a powerful discipline but one in which subtle mistakes produce plausible-looking yet incorrect results. This page catalogs the most common errors encountered when using the Numerics.NET SPC API, explains why each mistake matters, and describes how to avoid it. Where a pitfall is discussed in depth on another page, a cross-link is provided.

The mistake. Running a capability study ($C_p$, $C_{pk}$) on a process that has not yet been demonstrated to be in statistical control.

Why it matters. Capability indices quantify how well a stable process can meet specification limits. When the process contains assignable causes — shifts, trends, or sporadic spikes — the within-sigma estimate mixes common-cause and special-cause variation. The resulting index neither describes current behaviour nor predicts future conformance. A $C_{pk}$ of 1.6 on an out-of-control process tells you nothing useful.

How to avoid it. Always run and evaluate a control chart before requesting a capability analysis. Confirm that no rule violations appear on the relevant chart (XBar and R for subgrouped data; Individuals and MR for single measurements). Only proceed to capability after the process is confirmed stable.

Read more.Capability, Performance, and Assumption Diagnostics — Interpretation Cautions.

The mistake. Passing engineering specification limits (LSL, USL) to the control chart analysis instead of letting the library compute statistical control limits from the data; or, conversely, using computed control limits as acceptance criteria for product conformance.

Why it matters. Control limits (UCL/LCL) are statistical quantities derived from process data; they indicate whether the process is behaving consistently. Specification limits (USL/LSL) are engineering requirements on individual units; they define acceptable product. These are conceptually independent. A process can be in control yet produce out-of-spec product ($C_{pk}$ below 1.0), or it can produce in-spec product yet be statistically out of control.

How to avoid it. Never supply specification limits to the control chart constructor. The API accepts specification limits only through SpecificationLimits, which is a separate input to the capability analysis, not the chart. Keep these two concepts — and their corresponding API entry points — strictly separate in your code.

Read more.Choosing the Right Analysis.

The mistake. Using a P or nP chart (designed for defective units) when the measurement is the count of defects per unit, or using a C or U chart (designed for defect counts) when the measurement is a binary pass/fail per unit.

Why it matters. P and nP charts model the binomial distribution: each inspected item either passes or fails, and a defective unit is counted once regardless of how many defects it has. C and U charts model the Poisson distribution: a single unit can accumulate multiple defects, and the count is unbounded. Applying the wrong model produces incorrect control limits because the assumed variance structure differs.

How to avoid it. Ask: can a single inspected unit contribute more than 1 to the numerator? If yes, use C or U. If each unit is either defective or not (binary), use P or nP. The Choosing the Right Analysis page includes a decision table that formalises this distinction.

Read more.Attribute Charts.

The mistake. Reading a single UpperControlLimit scalar from a P or U chart result and drawing a single horizontal limit line in the chart renderer, when sample sizes actually vary by point.

Why it matters. When subgroup or lot sizes vary, the control limits for each plotted point depend on the size of that point's sample. Rendering a single horizontal line misrepresents the statistical limits for every point whose sample size differs from the average, potentially hiding true signals and generating false alarms.

How to avoid it. Always check whether the result reports per-point limit vectors. The result model exposes per-point upper and lower control limit sequences for variable sample-size charts. Pass those vectors to the renderer, drawing stepped or curved limit lines. A scalar limit property is only meaningful for fixed-sample-size charts (nP, C). See Result Model and Rendering Semantics for the full per-point vector API.

Read more.Attribute Charts — Variable Sample Sizes.

The mistake. Passing observations to an individuals or subgroup analysis in a non-chronological order (e.g., sorted by value, or in database retrieval order without an ORDER BY clause).

Why it matters. Control charts are fundamentally time-series tools. The moving range, the between- subgroup mean square, and the sequential run rules all depend on the order of observations. Shuffling the data changes the moving ranges, artificially deflates the within-sigma estimate, and makes run-rule evaluation nonsensical. A sorted dataset will typically show dramatically lower control limits than the actual process, producing a chart that looks wildly out of control.

How to avoid it. Sort by the time stamp or sequence number before calling any analysis method. If a reliable time sequence is unavailable, the data should not be analysed with a sequential control chart. See Data Contracts and Preparation for data ordering requirements.

Read more.Data Contracts and Preparation.

The mistake. Forming subgroups that mix observations from different machines, operators, cavities, or time blocks, rather than sampling consecutive units from one homogeneous stream.

Why it matters. The power of an XBar chart comes from the fact that within-subgroup variation reflects only short-term, common-cause noise, while between-subgroup variation may reveal shifts and trends. If a subgroup spans two machines, the within-subgroup variation captures between-machine differences, inflating the control limits and masking real process changes. This is known as violating the rational subgroup principle.

How to avoid it. Ensure that each subgroup consists of units produced under essentially the same conditions within a short time window. If multiple streams are present (multi-cavity, multi-spindle), analyse each stream separately or use a specialised multi-stream chart.

Read more.Choosing the Right Analysis — Subgrouping Strategy.

The mistake. Requesting an XBar-R chart with subgroup sizes greater than 10 (or in some implementations, the library's documented maximum).

Why it matters. The range statistic R = max − min becomes a highly inefficient estimator of within-subgroup spread as subgroup size increases. For subgroups larger than roughly 10, the unbiasing factor $d_2$ is tabulated only under normality assumptions and becomes increasingly sensitive to departures from normality. The XBar-S chart (using the subgroup standard deviation S and the c₄ unbiasing constant) is the correct choice for larger subgroups and is also supported by the library.

How to avoid it. Use XBar-R for subgroup sizes 2–10 and XBar-S for sizes above 10. The library documents the supported range in the Support Matrix and will raise a diagnostic or exception when a subgroup size falls outside the valid range.

Read more.Variables Charts — XBar-R and XBar-S.

The mistake. Passing sequences that contain NaN or leaving gaps in the input without understanding how the library handles them.

Why it matters. The library's data contracts specify how missing values are treated for each chart type. For individuals charts, a NaN in the observation sequence breaks the moving-range chain: the ranges immediately before and after the gap are set to missing, and the point is excluded from the sigma estimate. For subgrouped data, a subgroup with any NaN member may be dropped entirely or have its effective size reduced, depending on the chart type. Callers who are unaware of these rules may misinterpret gap-induced control limit widening as a real change in process behaviour.

How to avoid it. Read the missing-value handling rules in Data Contracts and Preparation before designing the data pipeline. Decide whether gaps in the data should be represented as NaN (and let the library handle them) or whether the time series should be pre-filtered to exclude missing points.

Read more.Data Contracts and Preparation.

The mistake. Configuring the standard Western Electric (WECO) or Nelson run rules on an EWMA or CUSUM chart.

Why it matters. Run rules such as “8 consecutive points on one side of the centre line” or “6 points in a row continuously increasing” are designed for Shewhart charts, where successive plotted values are independent (or nearly so). EWMA and CUSUM statistics are explicitly constructed to be autocorrelated: each plotted value depends on all previous values. Applying Shewhart-designed rules to correlated statistics produces enormous false-alarm rates and renders the rules meaningless.

How to avoid it. Use only the boundary-crossing signal (a point outside the control limits) for EWMA and CUSUM charts. These charts are self-contained; their increased sensitivity to small shifts comes from the cumulation mechanism itself, not from run rules.

Read more.Time-Weighted Charts (EWMA and CUSUM).

The mistake. Concluding that a process is “perfect” or “requires no action” solely because no control chart violations were flagged and $C_{pk}$ exceeds a target threshold.

Why it matters. A clean result means the tested signals were not detected in the available data. It does not mean the process will remain in this state, that no assignable causes exist, or that the study period was representative of all operating conditions. Small sample sizes reduce the power to detect real shifts; short study periods may not capture seasonal or batch-to-batch variation; run rules have finite sensitivity.

How to avoid it. Report the absence of detected signals, not the absence of problems. Supplement point estimates with confidence intervals; document the study period and sample size in any capability report. Continue monitoring with ongoing control charts after the initial capability study.

Read more.Result Model and Rendering Semantics — Interpreting Absence of Violations.

The mistake. Citing a non-significant Anderson-Darling or Shapiro-Wilk p-value as proof that the process data are normally distributed, and then using this as justification for publishing $C_p$/$C_{pk}$ without caveats.

Why it matters. Hypothesis tests for normality — including the Anderson-Darling test returned in CapabilityAssumptionDiagnostics — have low statistical power in small samples. A p-value of 0.30 with n = 30 observations is entirely consistent with a moderately skewed distribution. Failure to reject does not establish normality; it establishes only that the available data do not contain strong evidence against normality. In small samples this is a weak statement.

How to avoid it. Treat the normality test p-value as advisory, not conclusive. Supplement it with a normal probability plot (Q-Q plot) and subject-matter knowledge about the physical process. If the process is bounded (e.g., a proportion, a time-to-event) or known to be skewed, consider transformation or a non-normal capability model even if the formal test is non-significant.

Read more.Capability, Performance, and Assumption Diagnostics — Assumption Diagnostics.

Other Resources