How to validate a vision system: a practical path through GAMP 5

Start with the process, not the software

Validation answers one question: does this system do what your process needs, reliably and demonstrably? So the first document is not a test script, it is a short user requirements specification that states what the station must achieve, in your words: which products, which quantities, which check, which record, which interfaces, who may do what.

Everything downstream traces back to that list. If a requirement is not written there, no test proves it, and no auditor can follow why you tested what you tested.

Where a vision station sits in GAMP 5

GAMP 5 sorts software by how much it is changed for you. A standard counting and inspection station that you configure, with cameras, expected quantities, roles and a detection model, is a category 4 configured product. You are not validating the vendor's source code; you are validating the configuration in your process, with a depth that follows risk.

That distinction saves a great deal of work. The highest-risk functions get the deepest testing, and the rest is covered by supplier documentation and the vendor's own verification evidence, referenced rather than repeated.

• Highest risk, deepest coverage

  Data integrity (audit trail, immutability, signatures), access control, and correctness of the count or inspection result.

• Moderate

  Interfaces to PLC and other systems, reporting, model management and backup or restore.

• Lower

  Convenience functions such as layout, language switching or dashboard views.

The document set

• User requirements (URS)

  What the station must achieve in your process, including the regulatory requirements it has to support.

• Risk assessment

  Which failures would affect product quality or data integrity, how likely they are and how they are detected. This sets the testing depth.

• Installation Qualification (IQ)

  The system is installed correctly on defined hardware: versions, checksums of the application and the model, camera identity, time source, network and access paths.

• Operational Qualification (OQ)

  Each function behaves as specified, including the challenge tests below, under normal and deliberately abnormal conditions.

• Performance Qualification (PQ)

  The station performs in the real process with your products and your operators, over enough runs to be meaningful.

• Traceability matrix (RTM)

  Each requirement mapped to its design, its test and its result, so an auditor can walk from a requirement to the evidence in one step.

The challenge tests that prove something

A test that only confirms a correct tray is counted correctly proves very little. Challenge the failure modes on purpose, with known inputs.

• Counting edge cases

  A tray with the exact quantity, one with a known shortfall, one with a deliberate extra unit, an empty station, and a partly covered tray. Record what the station reports for each, and what reaches the batch record.

• Damaged and atypical units

  If damage detection is used, include chipped and broken units, and units at the edge of the class definition, so the limits are documented rather than assumed.

• Data integrity

  Attempt to change a closed batch. Change a setting mid-run and find the entry in the audit trail with its old and new value. Export the trail and verify it independently.

• Access control

  Confirm that roles can do only what the matrix says, that the restriction is enforced on the server, that lockout works after failed logins, and that a leaver loses access.

• Interfaces

  Trigger a capture from the PLC or another system and confirm the result lands in the same record with correct attribution, and what happens when the connection drops mid-capture.

• Recovery

  Pull the power during a capture. Confirm what survives, what is marked incomplete, and that nothing silently loses a count.

The model is part of your validated state

This is the part most CSV templates were never written for. A detection model is configuration that materially determines results, so it belongs under change control like any other configured parameter.

Agree three things before go-live: which model version is validated, what is recorded with every result so the version is traceable afterwards, and what triggers revalidation. A model retrained for a new product usually needs its own PQ evidence for that product, while the rest of the qualification stands.

Record the model's checksum in the IQ and make sure each batch record carries it. Without that link, a question about a past count has no answer.

Keeping the validated state

• Change control

  Software updates, model changes, camera or lighting changes, and new products each need an assessed change, not a quiet swap.

• Periodic review

  Confirm the system still matches its documentation, review audit trail findings, deviations and user access.

• Backup and restore

  Test the restore, not just the backup. A backup that has never been restored is a hypothesis.

• Training records

  Operators trained on the current version, with the operator manual under document control.

What to ask a supplier for

A supplier cannot validate the system for you, but they can remove most of the writing. Ask for the functional specification, a requirements traceability matrix, IQ, OQ and PQ protocol templates, the release and build identity of the version you receive, and evidence from the supplier's own testing that your OQ can reference.

Steadeye ships that package with the station, on a GAMP 5 category 4 approach, so your QA executes and adapts rather than starts from a blank page.