AOI Programming and Validation Guide

Published 31 July 2026Reviewed 17 September 2026Prepared and reviewed by SERVICEDIRECTORY

How this guide was prepared

SERVICEDIRECTORY reviewed the provider's published AOI explanation and organised the guidance around inspection objectives, defect size, sample coverage, optics and lighting, cycle time, false-reject control, programming, validation, and production integration.

Evidence boundary: SERVICEDIRECTORY did not independently validate a machine or production line. Detection capability, speed, repeatability, integration, and acceptance criteria should be demonstrated with representative samples and agreed test results. Read our editorial policy.

Why AOI programming is critical

AOI programming and validation turn a camera system into a controlled inspection process. A recipe defines where to inspect, which image tools to use, what variation is acceptable, how defects are classified, and what action follows a failed result. If these decisions are unclear, even capable equipment may produce missed defects, excessive false rejects, or inconsistent operator responses.

Programming should begin with an approved inspection requirement. Teams need to define defect types, locations, minimum relevant size, cosmetic limits, product variants, and any condition that cannot be judged optically. Quality, process, production, and equipment personnel should agree on the criteria before final thresholds are released.

Building a representative recipe

Collect approved products from normal production variation, not one ideal sample.
Include confirmed defects and borderline conditions near the acceptance limit.
Test expected colours, materials, suppliers, batches, orientations, and changeovers.
Verify image stability at the actual production speed and handling condition.
Record tool settings, tolerances, defect codes, software versions, and approvals.
Protect released recipes from uncontrolled editing and maintain secure backups.

A golden sample or reference image may be useful, but it should not become the only representation of an acceptable product. Normal variation must be understood so the system does not reject good items whenever appearance changes slightly.

Validation and false-reject review

Validation should demonstrate repeatable detection using a planned sample set. Run good and defective products more than once, review results by defect type, and record false accepts and false rejects. Where possible, challenge the system with borderline samples and production conditions such as minor position changes, vibration, surface variation, or ambient temperature.

False rejects need structured investigation. The cause may be lighting, focus, product movement, narrow limits, reflections, contamination, or genuine process instability. Do not simply widen every tolerance. Adjustments should preserve detection of the target defect and be revalidated before the revised recipe is approved.

Maintaining performance in production

Operators need instructions for loading, recipe selection, result review, cleaning, and escalation. Engineering teams should schedule calibration checks, image backups, software backups, lighting inspection, fixture maintenance, and periodic challenge tests. New suppliers, materials, tooling, or process settings may change product appearance and should trigger a recipe review.

Trend data can provide more value than a pass-fail signal alone. Recurring defects by station, cavity, component, or time may help production teams identify process drift. For the equipment, imaging, integration, and business considerations around implementation, read the AOI solution Malaysia guide.