Most inspection projects that disappoint were specified in adjectives. “Detect all visible scratches.” “Reject damaged seals.” “No false rejects.” Each sentence sounds clear in a meeting and means something different to the quality manager, the line lead and the integrator. Integrators under schedule pressure tend to read ambiguity in whichever way is easiest to pass.

A spec that can’t be misread replaces adjectives with physical limit samples, measurable acceptance criteria, resolution math, an honest description of how parts arrive, reject handling, a false-reject budget, data requirements and an acceptance test agreed before anyone mounts a camera. It takes days to write and saves months of argument. Below is how we approach each part, followed by a template outline you can reuse.

Why “detect all defects” isn’t a specification

Every inspection system trades escapes against false rejects. Turn the sensitivity up and it catches more defects and rejects more good parts; turn it down and the reverse happens. A spec that asks for “all defects” and “no false rejects” at once hasn’t made that trade-off. It has handed it to whoever sets the threshold during commissioning, usually late on a Friday.

The spec’s job is to make the trade-off explicitly, in numbers, and to define exactly how those numbers will be measured.

1. Build a defect catalogue with limit samples

The defect catalogue is the heart of the spec. For each defect type, record:

  • a name and a short code used everywhere: on the HMI, in reports and in the model;
  • a description, the likely cause, and the zones of the part where it occurs;
  • a severity class, such as critical, major or minor;
  • the smallest size, or other measurable threshold, that must be rejected;
  • photos of typical examples.

Then build physical limit samples: for every defect, one part that is just acceptable and one that is just rejectable. These boundary parts settle more arguments than any paragraph of text. Label them, store them like gauges, and use them to align your human inspectors before you use them to train or test a model. If three experienced inspectors can’t agree on a limit sample, the system won’t either.

2. Write acceptance criteria you can measure

Rewrite each criterion until a person with a ruler and the limit samples could apply it. Compare:

  • “No visible scratches on the front face.” Visible to whom, under what light, from what distance?
  • “Reject any scratch longer than 2.0 mm or wider than 0.1 mm in zone A (front face). Scratches in zone C (inside the flange) are acceptable.” That one is measurable.

Zone maps are worth the effort. A cosmetic face the customer sees and a mating face nobody sees rarely deserve the same threshold, and a single global threshold usually means false rejects on the surface that doesn’t matter.

3. Do the field-of-view and resolution math

The smallest defect sizes the camera, not the other way round. A worked example with hypothetical numbers:

  • The part is 80 × 60 mm and can shift ±5 mm on the conveyor, so the field of view must cover about 90 × 70 mm.
  • The smallest defect to reject is 0.2 mm across. To be detected reliably it should span at least three to four pixels, so each pixel must cover no more than about 0.05 mm of the part.
  • That requires 90 ÷ 0.05 = 1,800 pixels horizontally and 70 ÷ 0.05 = 1,400 vertically, roughly 2.5 megapixels at minimum. A typical 5 MP machine-vision sensor, at about 2,450 × 2,050 pixels, leaves margin.
  • The conveyor runs at 0.5 m/s, so the part moves 0.05 mm, one pixel, in 100 µs. Exposure or strobe pulse length must stay at or below that.

The spec should state the requirements (smallest defect, field of view, line speed) and ask the integrator to show the math. If their numbers don’t close, you find out on paper rather than at acceptance. Lens resolution, depth of field and lighting matter as much as pixel count; our post on lighting geometry covers the last of these.

4. Describe line speed and presentation honestly

Integrators design for the line you describe, so describe the real one, bad days included:

  • minimum, normal and maximum rate in parts per minute, and conveyor speed;
  • part spacing: fixed pitch, or random and sometimes touching;
  • orientation: fixtured, or random, flipped or tilted;
  • position and height variation at the camera;
  • the number of SKUs, colors and materials, and how often changeovers happen;
  • the environment: ambient light, washdown, temperature, dust and vibration.

5. Specify reject handling

Detection is half the job. The spec should state:

  • the reject mechanism (air blast, pusher, diverter or line stop) and where it sits;
  • how parts are tracked from the camera to the reject point, normally by encoder;
  • how the system confirms a reject actually happened, such as a sensor at the reject bin;
  • what happens when the bin is full or the reject device fails;
  • the fail-safe state if the vision system faults: stop the line, reject everything, or alarm and continue. That is a decision for your quality team, not for the integrator.

Our article on encoders, handshakes and reject gates goes deeper on the integration side.

6. Set a false-reject budget

A false-reject budget turns “not too many false rejects” into money. A hypothetical example: a line runs 200 parts per minute across two 8-hour shifts, or 192,000 parts a day. A 0.5% false-reject rate scraps or reworks 960 good parts a day. At $0.40 a part, that is about $96,000 a year in parts alone over 250 production days, before handling. At 0.1%, it is 192 parts a day.

Write the budget per defect class and overall, next to the detection target for each class. An example pair: “critical defects: at least 99% of seeded defects detected; false rejects: no more than 0.3% of good parts.” Either number on its own is meaningless.

7. State data and traceability requirements

Decide up front what the system must record, and for how long:

  • which images to keep: every reject, plus a sample of passes such as 1 in 1,000;
  • the metadata stored with every record: time, line, lot, SKU, model version, confidence and reject reason;
  • the retention period, the storage location, and who owns the data;
  • interfaces to MES, historian or quality systems;
  • access control and audit trail, plus any electronic-records rules that apply, such as FDA 21 CFR Part 11 for regulated records.

8. Define the acceptance test protocol

The acceptance test is where the spec gets enforced, so write it into the spec rather than leaving it to the integrator’s template. Cover both the factory acceptance test (FAT) at the integrator and the site acceptance test (SAT) on your line:

  • The test set. How many good parts, how many examples of each defect class including limit samples, and who holds them. Keep them out of the training data.
  • Seeded runs. Known defective parts inserted blind into production flow at full speed, several times, to test detection and the reject mechanism together.
  • Repeatability. The same parts passed through repeatedly, for example ten parts ten times each, with every decision expected to agree, as in an attribute gauge study.
  • Pass criteria. Numbers taken from sections 1 and 6, with sample sizes large enough to measure them.
  • Witnesses and remedies. Who signs, and what happens if the system misses a criterion.

Our how we work page shows where FAT and SAT sit in a Perflens project.

A template outline

Copy this structure and fill every section with numbers:

  1. Purpose and scope. Line, station, products covered and what is out of scope.
  2. Products and SKUs. Dimensions, materials, colors and changeover frequency.
  3. Defect catalogue. Codes, descriptions, zones, severities, photos and limit sample IDs.
  4. Acceptance criteria. Measurable thresholds per defect and zone.
  5. Imaging requirements. Smallest defect, field of view, position tolerance and required pixel size.
  6. Line and presentation. Rates, speed, spacing, orientation and variation.
  7. Environment. Ambient light, washdown, temperature, vibration and available space.
  8. Reject handling and fail-safe. Mechanism, tracking, confirmation and fault behavior.
  9. Performance targets. Detection target and false-reject budget per class and overall.
  10. Data and traceability. Images, metadata, retention, interfaces and access.
  11. Integration. PLC, MES, historian, network and security requirements.
  12. Acceptance test protocol. FAT and SAT test sets, seeded runs, repeatability and pass criteria.
  13. Change control. What triggers revalidation or retraining: a new SKU, supplier or material.
  14. Sign-offs. Quality, production, maintenance, controls and the integrator.

Write it before you buy

A spec written after the purchase order tends to describe whatever the chosen system can already do. Write it first and you can compare integrators on the same terms, whether you are adding AI to existing cameras through a vision retrofit or buying a new cell. On our AI visual inspection projects, the inspection specification and defect catalogue are deliverables your quality team signs off, and everything that follows, from lighting design to the acceptance test, is measured against them.