Resolving out-of-spec exceptions

Resolve, under VoraControl at /control/resolve, is where out-of-spec results become managed exceptions. When a capture lands out of spec, an exception is raised automatically, so the follow-up is recorded alongside the measurement instead of in a separate system.

The three views

The register is split into Inbox (new out-of-spec results that still need review and a responsible person), Active (exceptions already owned, being worked on or waiting for a decision) and History (closed or cancelled exceptions with their evidence trail preserved). Overview cards summarize what needs review, what is in progress, what needs attention and the closed evidence count.

Reviewing an exception

Opening an exception shows the out-of-spec result in full: the measured value, the specification it failed, who measured it and when, and the plan context it was judged against. From there you assign a responsible person, set priority and severity, and add update notes as the work progresses.

Structured root cause

The exception carries structured root cause fields, recorded on the record rather than in a free-text comment: the analysis method used, the root cause (what actually caused the out-of-spec result), the corrective action (what was changed in the process to fix the cause), recurrence prevention (how it is prevented from happening again, including any error proofing), and an effectiveness check with its date and note.

Closing, reopening and the trail

Closing asks for a close-off note: what was done, and why the exception can be closed. Closed records move to History and stay available for review and reporting; nothing is deleted. If the issue returns, the exception can be reopened with a reason, and the reopen is part of the same trail.