Why SPC data cannot answer an auditor
A Cpk number in a spreadsheet is not process capability evidence. Without the characteristic, the specification limits, the sample window and the revision behind it, the number cannot answer the question an auditor actually asks.
An auditor points at a characteristic on the control plan and asks a direct question: show me the process capability for this dimension over the last quarter. The Cpk number exists somewhere. It is in a spreadsheet on a machine, in a standalone SPC package, or in a capability study run once at part approval and never refreshed. Producing an answer means finding that file, checking which revision it belongs to, confirming the specification limits it used, and trusting that the calculation was done the same way as last time. The number was there. The proof was not.
A Cpk number is only as good as its context
Process capability is a relationship, not a single figure. A Cpk of 1.4 means nothing until you can say which characteristic it describes, which specification limits it was measured against, which part revision was in force, how many samples it used, and over what window. Strip that context away and the number is just a value in a cell. Auditors know this, which is why the capability question is rarely answered by the number alone. They want to see the characteristic, the limits, the samples and the timeframe behind it, and they want to know that the same calculation would come out the same way today.
Where SPC data scatters
Statistical process control tends to live wherever the calculation was easiest to run. One line keeps control charts in a spreadsheet per machine. Another exports data into a standalone SPC application that has no link back to the released control plan. Capability studies are produced for part approval, saved as a document, and rarely recomputed as more data arrives. Each of these works in isolation. None of them stays connected to the capture records, the plan characteristic or the revision history that give the numbers meaning. So the SPC data drifts away from the context that makes it evidence.
What breaks when SPC lives apart from capture
- Capability figures that cannot be tied back to a released control plan characteristic and its specification limits
- Capability recomputed by hand, inconsistently, so the same characteristic reads differently across sheets
- Out-of-spec results that show on the chart but carry no record of what was done in response
- Capability studies run once at approval and never refreshed as the process produces more data
- Different sites and machines using different SPC formats, making cross-site capability review unreliable
SPC that comes from the capture record
The alternative is to let capability fall out of controlled measurement rather than a separate calculation step. When operators capture measurements against a released control plan characteristic, every sample already carries the part, revision, operation, specification and method. VoraControl builds SPC trends directly on that capture stream, so Cp and Cpk are computed from the same records that answer every other quality question, against the correct characteristic and limits. When a result moves out of specification, it hands off to Resolve, so the response is recorded alongside the signal instead of living in someone's memory. VoraAudit then surfaces live Cp and Cpk per characteristic as SPC and capability evidence, computed from the recent capture window rather than a study filed months ago. A characteristic that does not yet have enough samples to compute capability is shown honestly with that status, not hidden.
Capability is not a document you produce before an audit. It is a by-product of capturing measurement against the plan. When the samples, the limits and the response all live in one record, the capability answer is already there when the auditor asks.
Released control plans, inspection capture and SPC trends in one governed flow.
Talk to someone who understands manufacturing control and audit evidence. We do not do generic demos.