# Process capability (Cpk): the proof for streamlining.

To justify controlling less often, you need objective proof, not a hunch. That proof exists: **process capability (Cpk)**, cross-referenced with deviation history. A highly capable, well-centered process doesn't drift between two controls — and that can be demonstrated, with the numbers to back it up.

Cpk > 1.33

the usual threshold for a "capable" process. Above 2, the process is so robust and well-centered that a deviation between two controls becomes highly unlikely.

Indicative capability benchmarks (Cpk).

**Cpk** measures both the spread of a parameter and its **centering** relative to the specifications. The higher it is, the more comfortable the margin. At a pharmaceutical site in Morocco, a tracked parameter showed a **Cpk of 3.63** (measurements at 400–403 mg for a 390–410 mg specification): in other words, an out-of-spec drift between two samplings is almost impossible.

We measure capability to validate… then forget it when it comes to steering.

Cpk is calculated during validation, then filed away in a report. Instead, it should inform a very concrete decision: how often to control? A process shown to be highly capable and with no deviation history doesn't need to be checked every 30 minutes — the data proves it, you just have to use it.

## What Cpk really tells you.

Three simple benchmarks to turn a number into a decision.

| Cpk | Reading | Implication for control |
| --- | --- | --- |
| < 1.0 | Process not capable | Close control justified; act on the process first |
| 1.0 – 1.33 | Borderline / to monitor | Keep the frequency; make it reliable before streamlining |
| 1.33 – 2.0 | Capable | Streamlining conceivable, cross-referenced with history and FMEA |
| \> 2.0 | Highly capable and centered | Strong candidate for lower frequency, with the proof to support it |

Indicative benchmarks — the decision is always made by cross-referencing Cpk, deviation history and risk analysis.

## Capable isn't enough: it must also be stable.

A high Cpk is a snapshot; the **history** is the movie. It's cross-referencing the two that makes the proof: a highly capable process _and_ with no OOS/OOT over several years is demonstrably stable over time. At that level, control frequency mainly guards against a risk that no longer materializes — and **machine barriers** (automatic rejection out of tolerance, stop on exceedance) already cover the residual chance of error.

[The complete method for streamlining IPC →](/en/blog/streamline-in-process-controls-ipc/)

## From proof to decision.

[In-process controls

### Streamline IPC without risk

The 5-step method in which Cpk is the 3rd pillar.

Read the article →](/en/blog/streamline-in-process-controls-ipc/) [Sampling

### AQL applied to the batch record

How capability translates into frequency via an AQL plan.

Read the article →](/en/blog/aql-sampling-plan-batch-record/) [Consulting

### Simplify deviation management

OOS/OOT history feeds the proof: detect, handle, learn.

Learn more →](/en/consulting/deviation-management/)

## Process capability & Cpk.

What is Cpk? +

Cpk is a process capability index: it measures the spread of a parameter and its centering relative to the specifications. A Cpk above 1.33 indicates a capable process; above 2, the process is highly robust and well-centered.

How does Cpk justify streamlining controls? +

A process with a high Cpk keeps a comfortable margin relative to the limits: an out-of-spec drift between two controls is very unlikely. Cross-referenced with a history free of OOS/OOT, this makes it objective that control frequency can be reduced without increasing risk.

Is Cpk enough to decide? +

No. Cpk is a snapshot; you have to cross-reference it with deviation history (the movie), a risk FMEA and machine barriers, then translate all of it into frequency via an AQL sampling plan. It's this body of proof that makes the decision robust and defensible in an inspection.

What should you do with a low-capability process? +

You don't streamline: you keep the control and act on the process first (centering, reducing variability, making the settings reliable). Streamlining an unstable process would amount to masking a real risk — the opposite of the goal.

## Let your capability speak.

Let's quantify the robustness of your processes to right-size your controls to real risk.