A part reaches an inspection station and fails three required checks: a missing component, an out-of-range dimension, and an incorrect mark. The inspection records three failure reasons. The overall decision is one rejected part.
If a report adds those failure-reason counters and labels the total "rejected parts," the number no longer represents how many parts received a reject decision. The distinction matters whenever several checks, cameras, or inspection attempts can produce results for the same item.
Keep the part result and failure reasons separate
The overall part result answers how the item was classified under the configured acceptance rules. The individual check results explain which requirements failed. Both are useful, but they answer different questions.
NIST's guidance on counts distinguishes nonconforming units from individual nonconformities. In inspection reporting, a part may contribute to several failure-reason categories while contributing once to the part-level reject total.
Failure reasons also describe observations, not necessarily separate root causes. A poorly presented part, for example, may cause several checks to fail together. Review the evidence before treating each reason as a different production problem.
Use the same population in the numerator and denominator
Consider a hypothetical first-pass run of 100 distinct parts. Ninety pass. Seven rejected parts each fail one required check, and three rejected parts each fail three checks.
The report contains 10 rejected parts and 16 failed checks. The part-level reject rate is 10 divided by 100, or 10%. Dividing 16 failed checks by 100 parts gives 0.16 failed checks per part. Labeling that value as a 16% part reject rate would misdescribe the run.
NIST's proportion guidance uses nonconforming items divided by the total items in the same population. A check-level failure percentage would need its own defined denominator of eligible check opportunities.
Define what qualifies for the inspected total. Missing results, skipped inspections, and no-reads need explicit handling. Some applications classify them as reject or hold conditions; others report them separately. A part without a usable result should not silently become a pass.
Define the session before comparing rates
A counter may cover a job, lot, shift, or the time since someone pressed Reset. Record that scope and use matching boundaries for the totals being compared. A reject count since the last reset cannot be divided meaningfully by an inspected count accumulated since yesterday.
Record recipe or inspection-rule changes as well. Adding a check can change the reported result even when the product has not changed. A comparison should make that difference visible rather than presenting every rate change as a production improvement or decline.
Keep reinspection visible
Sending a part through again creates another inspection attempt. It does not create another physical part. For a first-pass measure, preserve the original result. Record the later attempt, any rework, and final disposition separately.
A report can show first-pass rejects, repeat attempts, and the final accepted or scrapped quantity, provided each measure is clearly defined. If the system cannot associate repeat attempts with the original item, disclose that limitation before calling the count unique parts.
The part-level decision also differs from physical reject confirmation. A reject command, a confirmed removal, and a final scrap decision are separate events. Name the counter for the event it actually records.
Settle the counting rules early
Before using reject rate to compare jobs or shifts, ask:
- Does one count represent a part, a check, or an inspection attempt?
- Can one part appear in several failure-reason categories?
- Do numerator and denominator cover the same job, time, and inspection stage?
- How are missing results, resets, and reinspections handled?
- Does the reject total describe a decision, a confirmed removal, or scrap?
Discuss your inspection and reporting requirements with SSI. Clear definitions give production and quality teams a shared basis for reading the results.