In-Process Inspection: How to Trigger It, Track It, and Close It Without Losing the Thread

Most in-process inspection programs fail in one of three places: no one knows when to trigger an inspection, the right procedure doesn't follow the event, or the finding never gets formally closed. Here's how to fix all three.

You have an in-process inspection program. It’s documented. It passed your last audit. And yet, somewhere on the floor right now, an operator is writing inspection results on a sticky note, a quality technician is hunting for the right procedure, and a nonconformance from three weeks ago is sitting in a state that nobody would describe as “closed.”

This is not a discipline problem. It’s a design problem.

In-process inspection fails in predictable ways. Understanding those failure modes — and building a system that closes them — is the difference between a program that produces audit evidence and one that actually catches problems before they ship.

What the standards actually require

ISO 9001:2015 §8.5.1 requires that production be carried out “under controlled conditions,” which includes “the implementation of monitoring and measurement activities at appropriate stages to verify that criteria for control of processes or outputs have been met.” That’s the mandate for in-process inspection: check at the right points, record the result, act on what you find.

ISO 13485:2016 §7.5.1 adds specificity for medical device manufacturers: documented procedures for production processes, with monitoring and measurement activities defined in advance. The FDA’s Quality Management System Regulation (21 CFR Part 820, effective February 2026) incorporates ISO 13485 by reference, so device manufacturers are now working from the same framework.

Neither standard tells you how to run in-process inspection. They tell you that you must, that it must be documented, and that the results must be traceable. The “how” is where most programs break down.

Failure mode 1: Nobody knows when to trigger an inspection

The most common in-process inspection problem isn’t that inspections don’t happen — it’s that the trigger criteria live in someone’s head.

“We check every 50 parts.” “We check at shift change.” “We check when something looks off.” These are real answers from real quality teams. None of them are wrong, exactly. But none of them are auditable, and none of them survive turnover.

What a trigger should look like:

A trigger is a defined condition that creates an inspection obligation. Common trigger types in manufacturing:

Time-based: every 2 hours at a given work center
Quantity-based: every 100 units produced
Event-based: after a setup change, material lot change, or equipment adjustment
Escalation-based: when an SPC chart signals a rule violation

The trigger type matters because it determines who’s responsible for declaring the inspection and what happens if they don’t. A time-based trigger with no declaration at hour 2 is a gap in your quality record. An event-based trigger with no declaration after a setup change is a potential source of undetected nonconformance.

What to do today: List every in-process inspection point in your control plan. For each one, write down the trigger condition in a form that a new operator could follow without asking anyone. If you can’t write it down, the trigger isn’t defined — it’s assumed.

Failure mode 2: The procedure doesn’t follow the event

An inspection event is declared. Now what?

In most paper-based or spreadsheet-based programs, the answer is: the operator goes to find the right procedure, or the right form, or the right revision of the right form. This takes time. It introduces error. And it creates a gap between the declaration of the inspection and the execution of it — a gap that widens every time someone picks up the wrong revision.

The right procedure for an in-process inspection is determined by two things: the part being inspected and the location where the inspection is happening. A plastic housing inspected at the molding press has different acceptance criteria than the same housing inspected at final assembly. A procedure that’s correct for one location may be wrong for another.

The linkage problem:

When a procedure isn’t linked to the inspection event, you get one of three outcomes:

The operator uses whatever procedure is handy — possibly the wrong revision.
The operator waits for a quality technician to bring the right procedure — delaying production.
The inspection doesn’t happen — and no one records that it didn’t.

Option 3 is the one that shows up in warning letters.

What to do today: Map your in-process inspection points against your procedure library. For each inspection point, identify exactly which procedure applies, at which revision. If the same part is inspected at multiple locations, make sure the procedure-location linkage is explicit — not assumed.

Failure mode 3: The finding never gets closed

An inspection happens. A nonconformance is found. A form is filled out. And then — nothing. Or rather, something happens, but nobody can prove what it was.

Closing an in-process inspection finding requires three things:

A disposition decision: What happens to the affected material? Rework, scrap, use-as-is, return to vendor, sort? Each option has different documentation requirements. Use-as-is, in particular, requires a documented justification and — in regulated industries — typically a signature.
Evidence of execution: If the disposition was “rework,” what was reworked, by whom, and when? If it was “scrap,” how many units, and where did they go? The disposition decision is not the same as the disposition execution.
Closure conditions met: All containment checks completed. All notification actions (customer notification, supplier notification) completed. No open tasks hanging off the record.

The failure mode here is usually not malice — it’s that the system doesn’t enforce closure. A paper NCR form can sit in a folder indefinitely. A spreadsheet row can stay “in progress” for months. The record is technically open, but nobody is actively working it, and nobody is alerted that it’s stale.

What to do today: Pull your open nonconformance records. For each one, check: Is there a disposition decision? Is there evidence of execution? Are all containment checks resolved? If any of those answers is no, that record is not closed — it’s just old.

Building a system that doesn’t lose the thread

The three failure modes above are connected. A poorly-defined trigger means the inspection may not happen at all. A missing procedure linkage means the inspection may not be executed correctly. An incomplete closure process means the finding may not be resolved. Each gap compounds the others.

A well-designed in-process inspection system closes all three:

On trigger: The inspection obligation is created at the point of declaration — tied to a specific part, a specific location, and a specific trigger reason. The obligation is visible to the right people (quality technicians, quality engineers) immediately. If no one claims it, it doesn’t disappear — it stays open until someone does.

On procedure: When the inspection event is declared, the system matches the part and location against the procedure library. If exactly one procedure applies, it launches automatically. If multiple procedures apply, the technician picks from a short list. If no procedure is linked, the event escalates to a quality engineer — it doesn’t silently proceed without one.

On closure: The inspection event can only be completed when the linked procedure execution is in a terminal state. If the inspection required a sample, a disposition is required before the event closes. The associated task closes with the event. The audit trail captures every state transition — who declared it, who claimed it, who completed it, and when.

This is the architecture that Opwise uses for in-process inspection events. An operator or quality technician declares an event at their location. The system auto-matches the applicable procedure, launches it, and creates a task for the quality technician to complete. When the procedure execution is done and the disposition is recorded, the event closes — and the full record is available for audit.

A note on the “needs procedure” state

One scenario worth calling out explicitly: what happens when an inspection event is declared and no procedure is linked to that part at that location?

The wrong answer is to proceed without a procedure. The wrong answer is also to cancel the inspection.

The right answer is to escalate — immediately, to someone who can fix the linkage. The inspection event stays open in a “needs procedure” state. The quality engineer is notified. The technician can’t proceed until the linkage is resolved. The gap in your procedure library is surfaced in real time, not discovered at the next audit.

This is a feature, not a bug. An in-process inspection program that silently proceeds without a procedure is not a program — it’s theater.

What good looks like

A 90-person contract manufacturer making Class II medical devices runs in-process inspections at three work centers. Each work center has defined trigger criteria in the control plan. When an operator declares an inspection event, the system matches the part to the applicable procedure and launches it automatically. The quality technician works through the procedure steps, records the results, and — if a nonconformance is found — opens an NCR directly from the inspection record. The NCR carries the origin context: which procedure execution flagged it, which step, which defect code. Containment checks are completed. Disposition is recorded and signed. The NCR closes. The inspection event closes. The audit trail is complete.

That’s not aspirational. That’s what a well-configured in-process inspection program looks like when the trigger, the procedure, and the closure process are all connected.

Where to start

If your in-process inspection program has any of the three failure modes described above, start with the one that’s causing the most pain:

Unclear triggers: Spend an afternoon with your control plan and write explicit trigger conditions for every inspection point. Time, quantity, or event — pick one and document it.
Missing procedure linkage: Audit your procedure library against your inspection points. Find the gaps. Fix the linkage before the next audit finds it for you.
Incomplete closure: Pull your open NCRs. Set a 30-day target to close everything that has a disposition decision but no execution record. Then build the process that prevents the backlog from forming again.

None of these require new software. But if your current system makes any of them harder than they should be — if the trigger is a sticky note, if the procedure is a filing cabinet hunt, if the NCR is a spreadsheet row that nobody owns — that’s worth fixing too.