One Point Out of Limits

Do not accept the recalculation as offered. Deleting a point because it is inconvenient and then recomputing limits from the survivors is how a control chart is turned into a certificate of approval. The point stays on the chart.

Correct handling:

1. Treat it as a signal and investigate. The engineer's tool-change explanation may well be right - that is exactly what an out-of-control point is for. But the explanation must be verified against the record, not asserted after the fact.
2. If a verified assignable cause is found and corrected, the point is annotated on the chart with the cause, and the chart continues with the original limits - because the limits describe the process as it was, and you want to know whether the tool-change problem recurs. Limits are only recomputed when there is a deliberate, documented process change, and even then from a fresh baseline of stable data, never by subtraction.
3. The mixed signal matters. An X-bar point outside the limits while the R chart is in control means within-subgroup variation is stable but the subgroup mean shifted - consistent with a tool change or a set-up shift, not with a sudden increase in part-to-part scatter. That supports the engineer's story but does not license removal.

What to check about the limits:

• Were they computed including the out-of-control subgroup? Including a shifted point inflates the average range and widens the limits, making the chart less sensitive - which would also help explain the tight clustering around the centerline.
• Were the 25 subgroups taken under stable conditions (same lot, same tool, same operator regime)? A baseline that spans a known process change is not a baseline.
• Are the subgroups rational - five consecutive parts is correct for detecting within-hour variation, but a tool change inside a subgroup window would produce a range that hides the shift.
• Is n = 5 with hourly sampling fast enough to catch whatever is happening? Twenty-five hours of data is a short baseline for setting limits on a new chart.

What it suggests: on a stable, normally behaved process, roughly two-thirds of subgroup averages should fall within one sigma of the centerline, and 25 subgroups should produce something like 16 points in that band, with a handful beyond two sigma. Three points beyond one sigma out of 25 is far too few - the points are hugging the centerline. That is a signal in its own right, and the most common cause is that the limits are too wide, which makes the process look better controlled than it is.

Causes to check, in order:

1. Sigma inflated by the out-of-control subgroup or by a mixed baseline. If the average range was computed across a period containing a real shift, R-bar - and therefore the limits - is overstated. Compare limits computed with and without the suspect period; a large difference confirms it.
2. Stratification / mixed streams. If the plotted values combine two machines, two cavities, or two shifts, the pooled variation is larger than either stream's, widening the limits and flattening the pattern. Re-plot by stream - this is usually where the real signal appears.
3. Wrong sigma estimate. Limits built from overall (long-term) standard deviation rather than within-subgroup variation are systematically too wide for an X-bar chart.
4. Measurement resolution or rounding. If the gauge discriminates coarsely relative to the process sigma, averaged readings collapse toward the middle. Check the caliper's resolution against the tolerance and the observed spread.
5. Calculation error in the constants or the subgroup size. Unglamorous and surprisingly common.

What I would not conclude: that the process is unusually consistent. Centerline hugging is a chart problem until proven otherwise, and on this evidence the most defensible statement to the supplier is that the control limits cannot be validated, so neither can the capability figure computed against them.