Last updated: 28 September 2026 · By Hari Phi, CEO & Co-founder, TechieYan Technologies
Short answer: a computer vision vendor RFP for a manufacturing plant should specify acceptance metrics at real line speed (detection rate, false-reject rate, and latency), the deployment target (edge device, industrial PC, or cloud), lighting and camera conditions, integration with your PLC and reject mechanism, data and model ownership, and a fixed-scope pilot on one line with go/no-go criteria. Vendors that only quote “accuracy” on a curated dataset should be treated as a risk.
Key takeaways
- Write acceptance criteria as false-reject rate and escape rate at line speed, not a single accuracy number.
- Specify where inference runs and the maximum latency your reject gate can tolerate.
- Vision without PLC integration is a dashboard — put reject logic in scope.
- Own your images, labels, model weights, and training pipeline. Sign NDAs before sharing data.
- Score vendors with a weighted matrix so the decision survives procurement review.
TechieYan Technologies builds production computer vision systems for manufacturing, logistics, and defence-adjacent programmes from Hyderabad, India — including edge inference, PLC integration, and full source and model handover. Use this checklist to evaluate any vendor, including us.
1. Define the inspection problem precisely
Before any vendor meeting, document what the system must decide and how fast. Vague problem statements produce vague quotes.
- Defect catalogue: each defect type, with example images, minimum defect size, and severity.
- Line conditions: parts per minute, conveyor speed, part orientation, and how many SKUs or variants run on the line.
- Decision: pass/fail, grade, count, measure, or read (OCR) — and what happens to a rejected part.
- Current baseline: today’s manual inspection escape rate and false-reject rate, if known.
2. Acceptance metrics that matter on a production line
Ask every vendor to commit to these metrics, measured on your line, at your speed, with your parts.
| Metric | What it means | How to test it |
|---|---|---|
| Detection rate (recall) per defect type | Share of real defects the system catches | Seeded defect runs plus a hold-out set the vendor has never seen |
| Escape rate | Defective parts that pass inspection | Audit a sample of passed parts manually during the pilot |
| False-reject rate | Good parts wrongly rejected — the metric that costs money every shift | Count rejects and re-inspect them over full production shifts |
| Latency (capture to decision) | Time from image capture to the reject signal | Measure at peak line speed; must fit your reject-gate window |
| Throughput | Parts per minute handled without dropped frames | Run at maximum rated speed for a full shift |
| Uptime | Share of production hours the system is available | Monitored by the system and reported weekly |
“95% accuracy” on its own is not an acceptance criterion. On a line where defects are rare, a system can score high accuracy while missing most defects.
3. Data, labelling, and dataset ownership
- How many labelled images per defect class the vendor needs, and who labels them.
- How rare defects will be handled — seeded samples, synthetic data, or anomaly detection.
- Where images are stored, for how long, and who can access them.
- A written statement that you own the raw images, labels, and derived datasets.
4. Where inference runs: edge, industrial PC, or cloud
| Option | Strengths | Trade-offs |
|---|---|---|
| Edge AI module (e.g. NVIDIA Jetson class) | Low latency next to the camera, works without internet, compact | Limited compute for very large models; needs thermal planning |
| Industrial PC with GPU | More compute, several cameras per station, easier upgrades | Higher cost and cabinet space; needs a dust and heat-rated enclosure |
| On-premise server | Central management across lines, data stays on site | Network latency to the reject gate must be tested |
| Cloud | Fast iteration, analytics across plants | Usually unsuitable for real-time reject decisions; bandwidth and connectivity risk |
For most in-line inspection in Indian plants, inference at the edge or on an industrial PC is the default, with cloud used only for dashboards and retraining.
5. Lighting, optics, and environment
Most vision failures are optical, not algorithmic. Require the vendor to specify cameras, lenses, lighting (backlight, dome, ring, structured light), and enclosures, and to test under your conditions: ambient light changes across shifts, vibration, dust, oil mist, heat, and part colour or finish variation.
6. PLC and reject mechanism integration
Vision without reject logic is a dashboard. Put the following in scope:
- Trigger source (encoder, photo-eye, PLC signal) and timing.
- Reject output via digital I/O, Modbus TCP, OPC UA, or PROFINET/EtherNet/IP as your PLC requires.
- Fail-safe behaviour: what the line does if the vision system stops responding.
- Traceability: saving the image and decision for every rejected part, linked to batch or serial number.
7. Security, privacy, and compliance
If cameras can capture workers, your RFP should address India’s Digital Personal Data Protection Act, 2023 — including masking or avoiding personal data where possible. Also confirm network segmentation for camera and inference devices, remote-access controls, and patching responsibility.
8. After go-live: monitoring and retraining
- How the vendor detects drift (new supplier material, lighting changes, new SKUs).
- Who reviews borderline decisions and feeds them back into training.
- Retraining cadence, model versioning, and rollback. See our MLOps practice.
9. Commercials, IP, and ownership
You should own model weights, training code, deployment scripts, and configuration — with NDAs signed before any data is shared. Ask for pricing split into pilot, per-line rollout, and annual support, and check whether the vendor charges per-camera or per-inference licence fees.
10. Structure the pilot
Run a fixed-scope pilot on one line or station, with the acceptance metrics above agreed in writing before it starts. A typical path is a 2–4 week feasibility sprint on sample images, then a live pilot on the line, then a plant rollout only after the go/no-go gate is passed.
Vendor scoring matrix (suggested weights)
| Criterion | Suggested weight | What a strong answer looks like |
|---|---|---|
| Line-speed metrics committed in writing | 25% | Recall, false-reject rate, and latency per defect type, tested on your line |
| Integration capability | 20% | PLC, reject gate, MES/traceability experience with references |
| Optics and hardware engineering | 15% | Named cameras, lighting, and enclosures, tested in your environment |
| Data and model ownership | 15% | Full handover of data, weights, and code; no hidden licence fees |
| Support and retraining plan | 15% | Drift monitoring, retraining process, local response times |
| Total cost of ownership | 10% | Transparent pilot, rollout, and annual costs |
Red flags
- A single accuracy number with no false-reject rate or line-speed test.
- No plan for lighting, or a demo recorded under studio conditions.
- The vendor keeps the model weights or your images.
- Reject logic and PLC integration are “phase two”.
- No named person responsible for retraining after go-live.
Related resources
- Computer vision development services
- Deep-tech engineering for manufacturing
- Manufacturing case study
- How to choose an AI development partner in India
- Engagement models: POC sprint, milestone build, retained pod
FAQ
What should a computer vision vendor RFP include?
A defect catalogue with example images, line-speed acceptance metrics (detection rate, escape rate, false-reject rate, latency), the deployment target, lighting and environment conditions, PLC and reject integration, data and model ownership, security requirements, and a fixed-scope pilot with go/no-go criteria.
What accuracy should a visual inspection system achieve?
Set targets per defect type for detection rate and false-reject rate at line speed, based on the cost of an escaped defect versus a wrongly rejected good part. A single overall accuracy figure is not enough.
Should vision inference run at the edge or in the cloud?
For real-time reject decisions, run inference at the edge or on an industrial PC next to the line. Use cloud or on-premise servers for dashboards, analytics, and retraining.
How long does a computer vision pilot take?
A feasibility sprint on sample images typically takes 2–4 weeks, followed by a live pilot on one line. Plant-wide rollout should wait until the pilot passes agreed acceptance tests.
About the author
Hari Phi is CEO and Co-founder of TechieYan Technologies. He has a decade of industrial work across IoT, applied AI, computer vision, and production robotics, leading builds for manufacturing, infrastructure, and defence teams. More about our team · LinkedIn.
Book a procurement call — Hyderabad, India.
