Few statistics get reported as often — or as loosely — as process capability. A validation report says “Cpk = 1.45” and everyone nods. But Cpk and Ppk are not interchangeable, and quoting the wrong one can make a marginal process look capable.

The difference comes down to a single question: which variation did you put in the denominator?

The two flavors of sigma

Every capability index compares the width of your specification to the spread of your process. The indices differ only in how that spread is estimated.

Cp and Cpk use within-subgroup (short-term) variation. Sigma is estimated from variation inside rational subgroups — consecutive parts, one cavity, a single run — using the average range or average moving range. This deliberately excludes drift between subgroups, so it captures the process’s inherent, moment-to-moment noise.

Pp and Ppk use overall (long-term) variation. Sigma is the ordinary sample standard deviation of all the data, which absorbs everything: within-subgroup noise plus shift, drift, tool wear, lot-to-lot changes, and operator differences.

Because overall variation includes more sources, it is almost always the larger number. And since sigma sits in the denominator:

PpkCpkP_{pk} \le C_{pk}, nearly always. Cpk describes what your process could do. Ppk describes what it actually did.

What the “k” adds

Cp and Pp measure only whether the distribution is narrow enough to fit inside the specification. They ignore where it is centered — a process could be entirely out of specification and still post a high Cp.

The “k” versions account for centering by taking the worse of the two one-sided distances:

Cpu=USLxˉ3σwithinCpl=xˉLSL3σwithinCpk=min(Cpu,Cpl)C_{pu} = \frac{\text{USL} - \bar{x}}{3\sigma_{\text{within}}} \qquad C_{pl} = \frac{\bar{x} - \text{LSL}}{3\sigma_{\text{within}}} \qquad C_{pk} = \min\left(C_{pu},\, C_{pl}\right)

So Cpk=CpC_{pk} = C_p only when the process is perfectly centered, and the gap between them is a direct measure of how far off-target you are. Reporting Cp without Cpk hides a centering problem.

Reading the gap between Cpk and Ppk

The comparison is more informative than either index alone.

PatternWhat it usually means
Cpk ≈ PpkThe process is stable. Short- and long-term variation agree.
Cpk ≫ PpkThe process is capable moment-to-moment but drifts or shifts between subgroups. Look for tool wear, temperature cycles, lot changes, or setup differences.
Both low, similarInherent variation is simply too wide for the specification. Reducing variation — or revisiting the tolerance — is the only path forward.
Cpk < PpkUnusual. Often a subgrouping mistake: the subgroups aren’t rational, or the data isn’t in time order.

That third row deserves emphasis. If Cpk is comfortable and Ppk is not, improving the machine won’t help — the problem lives between subgroups, not inside them.

Which one goes in the report?

For medical device and pharmaceutical work, the honest answer is usually both, with the context that makes them interpretable.

  • Process qualification (PQ / Stage 2). You typically have a limited number of consecutive lots, so you’re measuring a short window. Ppk is the more defensible headline number because it makes no assumption that between-lot variation is absent. Report Cpk alongside it to characterize inherent capability.
  • Continued Process Verification (Stage 3). Now you have long-run data across many lots, operators, and material batches. Ppk is the number that describes what customers actually receive. Trend it over time.
  • Process development and improvement. Cpk is more useful for diagnosis: it tells you what the process is capable of if you can eliminate drift.

Whichever you lead with, state the estimation method — the subgroup size and how sigma was calculated. “Cpk = 1.45” is not reproducible; “Cpk = 1.45, n = 125 in 25 subgroups of 5, sigma from Rˉ/d2\bar{R}/d_2” is.

The three checks that come first

A capability index is only meaningful if its assumptions hold. Before you compute anything:

  1. Stability. Capability on an out-of-control process is a meaningless number — you’re estimating a parameter of a distribution that isn’t holding still. Plot an individuals or X̄-R chart first and resolve special causes.
  2. Normality. The conversion from Cpk to a defect rate assumes a normal distribution. Check it (normal probability plot; Anderson-Darling or Shapiro-Wilk). If the data is skewed — as flatness, roundness, particle counts, and most one-sided characteristics are — use a transformation or a non-normal capability method rather than reporting a normal-theory PPM you don’t believe.
  3. Adequate data. A capability index computed from a handful of parts is a very uncertain estimate of the process — uncertain enough that the point estimate alone can be misleading. This is the check most often skipped, and the one a reviewer is most likely to probe, so it gets its own section below.

How much data before you trust the number?

Cpk and Ppk are estimates, not measurements. They are computed from a sample mean and a sample standard deviation, both of which move around from sample to sample. Quoting “Cpk = 1.45” with no indication of how much data produced it is like quoting a dimension with no tolerance.

The uncertainty is larger than most people expect. Taking an observed Cpk of 1.33 and computing its 95% lower confidence bound:

nObserved Cpk95% lower confidence bound
151.330.89
201.330.95
301.331.03
501.331.10
1001.331.17
2001.331.21

At the popular n = 30, an observed 1.33 is consistent with a true capability barely above 1.0. You have not demonstrated a capable process — you have demonstrated that the process is probably not terrible.

The part that surprises people

Turn the question around, because this is the form that actually matters in a protocol: what do you have to observe in order to demonstrate that the true Cpk is at least 1.33?

nMust observe at least
151.95
201.83
301.71
501.61
1001.52
2001.46

Observing exactly 1.33 never demonstrates 1.33. The point estimate always sits above its own lower bound, so a study designed to “achieve Cpk ≥ 1.33” needs headroom — at n = 30, you need to see about 1.71. Acceptance criteria that require an observed 1.33 from 30 parts are, statistically, a much weaker claim than they appear to be.

This is the same trade you meet when sizing a verification study: more data buys a tighter bound, and higher true capability buys you the ability to prove it with less data.

Practical minimums

Conventions worth knowing, none of them regulatory requirements:

  • 25 subgroups of 4–5 parts (100–125 total) is the classic basis for an initial process study, and what PPAP-style submissions typically expect. It gives enough subgroups to assess stability and enough parts for a reasonably tight estimate.
  • n < 30 should be treated as indicative only — useful for development decisions, weak as validation evidence.
  • For Ppk you additionally need the data to span the sources of long-term variation you are claiming to cover: multiple lots, operators, and material batches. Ppk from a single lot is not a long-term index no matter how many parts it contains.

Whatever the number of parts, report the confidence bound alongside the point estimate. “Ppk = 1.52 (95% lower bound 1.28, n = 125)” is a defensible statement. “Ppk = 1.52” is a number that invites the question you didn’t answer.

(The bounds above use the standard Bissell approximation; simulation shows it is slightly conservative, giving about 97% coverage where 95% is nominal — so it errs in the safe direction.)

Why 1.33 became the benchmark

The familiar Cpk ≥ 1.33 target corresponds to a four-sigma distance from the mean to the nearer specification limit — about 32 defects per million on one side, assuming normality and perfect stability. Cpk ≥ 1.00 is three sigma, about 1,350 PPM one-sided.

These are conventions, not requirements. Nothing in the regulations names a number. The right target depends on the risk of the characteristic, which is why capability acceptance criteria belong in a risk-based justification tied to your FMEA — not copied from a textbook.

For a high-risk characteristic, 1.33 may be nowhere near enough. For a cosmetic attribute, insisting on it may be wasted effort.

Try it on your own data

You can work through these calculations — indices, expected versus observed PPM, the stability check, and the normality test — in our free Process Capability Explorer. It runs both the within and overall estimates side by side, so the Cpk-versus-Ppk gap is visible immediately.


Need a defensible capability rationale for a validation protocol or an audit response? Book a call or see our process capability services.

Process CapabilityCpkPpkProcess ValidationSPC