Prove Automated Inspection on Your Own Products
It starts with a feasibility gate on your real samples, because some visual tasks are not solvable at your line speed and it is cheaper to know that in week one. What follows is imaging design, annotated data, a validated model and a controlled line test — reported per defect class, with missed defects and false rejects counted separately.
Check my vision use caseTalk to a manufacturing engineerIs this the problem you need to solve?
- Visual inspection depends on a person’s attention at the end of a long shift.
- The same defect type keeps reaching the customer and nobody can say how often.
- Inspection is the reason the line cannot run faster.
- A previous vision project was accepted on an accuracy number and failed on the defects that mattered.
Primary buyer: Quality Manager · Production Manager · Automation Manager · Engineering Manager · Plant Manager
What this PoC will prove
Recommended pilot scope
- One inspection station and one product family, including its real variants.
- A bounded, named set of defect or verification classes — not "any defect".
- Selected camera, lens and lighting, chosen after the imaging design step.
- One reject or operator-confirmation flow, so a decision leads to an action.
- Training, validation and acceptance samples kept strictly separate throughout.
What will be live during the PoC
How this PoC runs
Durations are typical, not guaranteed. What extends a schedule: missing or incomplete data, security and network approvals, hardware lead times, sample collection, installation access, the production schedule, ERP test access, and the time your team needs to review results.
No unplanned shutdown is expected. Any installation window or controlled interruption is agreed with you in advance and scheduled around production.
How success will be measured
| Metric | How it is defined | Where the number comes from | Type |
|---|---|---|---|
| Precision per defect class | Of the parts flagged for a class, the share genuinely belonging to it — reported per class, never averaged into one figure. | Held-back validation set | Technical |
| Recall per defect class | Of the parts genuinely showing a class, the share detected — reported per class and per product variant. | Held-back validation set | Technical |
| False accept rate | Defective parts passed as good. Counted and reported separately from false rejects, because their business cost is completely different. | Held-back validation set | Technical |
| False reject rate | Good parts rejected. The number that decides whether operators will keep the system switched on. | Held-back validation set | Operational |
| Confusion matrix and sample count | Full class-by-class matrix with the number of samples per class, so the reader can judge how much the result is worth. | Held-back validation set | Technical |
| Processing latency and line-speed compliance | Inspection time per part against the available cycle time, measured on the line rather than on a workstation. | MSF platform data | Technical |
| Uncertain classification rate | Share of parts the model could not decide confidently, which is what the operator-confirmation flow has to absorb. | Held-back validation set | Operational |
| Uptime and operator confirmation behaviour | System availability during the line test, and how operators actually handled confirmations and overrides. | MSF platform data | Adoption |
Before implementation, MSF and your team agree how each metric is calculated, where the baseline comes from, what data is excluded, and what result supports a rollout decision. This page lists what gets measured; the actual targets belong in the written PoC scope, not in a marketing claim.
What you need to provide
- Representative OK and NOK parts or images, covering every variant and every defect class in scope.
- Defect definitions, severity rules and the acceptable false-accept and false-reject levels.
- Cycle time, line speed, field of view and the environmental conditions at the station.
- PLC or reject interface details and any traceability requirement.
Who does what
Meta Smart Factory provides
- Discovery workshop and scope facilitation
- Solution configuration for the agreed scope
- Integration and connection work inside that scope
- MSF hardware listed in the proposal
- Training for the pilot users
- The KPI definitions and validation method
- Issue tracking and support during the pilot
- The final result report and rollout design
- The feasibility verdict, imaging design and a validated model version with its evaluation reproducible.
- Failure examples — the images it got wrong — rather than only the ones it got right.
You provide
- A named business owner and a named technical owner
- Timely access to users, the line, machines and approved systems
- An accurate explanation of the process and the master data
- Network, power, mounting and safety access
- ERP, PLC and vendor documentation, plus the experts who know them
- Representative samples or historical data
- Validation that the baseline is fair
- Feedback and the acceptance decision
- Enough genuine NOK samples per class; rare defects are the hardest and the most important to supply.
- Line access for the controlled test at normal production speed.
Defined in the written proposal
- Panel PCs, tablets, servers and GPU servers
- Cameras, lenses, lighting and enclosures
- Scanners, printers, RFID readers, meters and sensors
- Travel, installation, freight, import duty and local electrical work
- Whether hardware is rented or purchased
- Whether any PoC fee is credited against a rollout
Commercial terms, hardware ownership, travel, integration scope and any rollout credit are defined in the written PoC proposal. They are not the same for every product, and this page does not promise them.
What you receive at the end
- Feasibility verdict with the reasoning behind it.
- Imaging and lighting design validated on real parts.
- A validated model version with a reproducible evaluation.
- Metric report per defect class, with failure examples included.
- Risk and limitation list covering the conditions that degrade it.
- Hardware bill of quantities, integration architecture and rollout recommendation.
Dependencies, exclusions and limits
This PoC depends on
- Enough genuine NOK samples per class — this is the most common cause of a delayed vision PoC.
- Stable part presentation at the station, or an agreed fixture to achieve it.
Not included in this PoC
- Defect classes not named in the scope, and product variants not represented in the samples.
- Mechanical handling, fixturing and reject-mechanism construction.
Overall accuracy is never used as the acceptance metric — on an imbalanced defect set it can look excellent while missing every defect that matters. Results are reported per class with sample counts, and no claim is made for defect types, variants or conditions that were not in the validated set.
Go, adjust or stop — the decision gate
Frequently asked questions
How many sample parts do you need?
It depends on how variable the defect and the product are, and the feasibility gate gives a specific number for your case. As a rule the constraint is not OK parts — those are everywhere — but genuine NOK examples per class, especially the rare defects that are the whole reason for the project.
Why not just report accuracy?
Because on a line producing 2% defects, a model that passes everything scores 98% accuracy and catches nothing. Precision and recall per class, plus false accepts and false rejects separately, are the only numbers that describe what will actually happen on your line.
What if the feasibility gate says no?
You get the reasoning, the imaging evidence and, where one exists, an alternative — a different inspection point, a different lighting geometry, or a sensor-based check instead of a visual one. A clear no in week one is a good outcome compared with a failed cell in month nine.
Will it work on new defect types later?
Not automatically, and this is stated in the limitation list rather than glossed over. A model detects what it was trained and validated on. New defect classes need new samples, retraining and a fresh validation — which is a normal, plannable activity, but it is not free.
Related products and PoC programs
Request this Proof of Concept
Tell us the scope you have in mind and we will come back with a written PoC plan: what gets connected, what you provide, how success is measured and what the decision at the end looks like.