Control plans should drive the inspection record
When the control plan and the inspection record are separate documents, the link between requirement and measurement has to be rebuilt manually. That rebuilding is where audit evidence breaks down.
The control plan defines what needs to be controlled: the characteristic, the operation, the specification, the measurement method, the frequency. The inspection record shows what was measured. When those two documents exist in different places, in different formats, updated by different people, the connection between requirement and result has to be made by hand. Manual connections break at the worst possible time, usually when someone asks for evidence.
The gap between plan and capture
Most quality teams know their control plans. They know the characteristics that matter, the operations to watch, the specifications to hold. But the inspection records often live separately: a form, a spreadsheet tab, a folder of reports. The plan is updated when engineering changes something. The inspection records accumulate in whatever format the operator used that day. When an auditor asks "show me that inspection was done against the current control plan for this part and revision," that question spans two separate document systems, and someone has to manually prove the connection.
What breaks when plan and capture are disconnected
- Revision changes to a control plan that are not clearly reflected in the capture records for that period
- Characteristics in the plan with no corresponding inspection record, or the reverse
- Frequency requirements documented in the plan that cannot be verified from the capture data
- Out-of-spec results that cannot be linked to the specific characteristic and revision that flagged them
- Multiple operations sharing a spreadsheet, making filtering by plan or revision unreliable
Capture driven by the plan
The stronger model is to start the inspection record from the control plan. The plan defines the context: customer, part, revision, operation, characteristic. When a measurement is made against that context, the record carries the plan link automatically. The characteristic, the specification, the method and the revision in force at capture time are all part of the record, not added later. SPC trends, including Cp and Cpk, can then be built against the specific characteristic and plan context rather than reconstructed from a separate spreadsheet. Out-of-spec events are already linked to the requirement that was violated and hand off to Resolve, so the response is recorded against the characteristic that flagged it. The entire chain from requirement to measurement to response is intact from the moment capture happens.
What this means at audit time
When an auditor asks for inspection evidence against a specific control plan revision, the answer does not require a document search. The records already exist in plan context. Filtering by customer, part, revision or characteristic produces the relevant capture history directly. VoraControl is built around this model: capture happens against released plan context, and VoraAudit can answer the evidence question from those source records without a separate assembly step.
When capture is driven by the plan, every measurement is already a piece of evidence. The evidence work was done at capture time, not the night before the audit.
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.