You have probably been offered a “vision assessment” and received a slide deck. A vendor accuracy figure, a bill of materials, a recommendation to pilot. The deck names a number without naming the conditions under which that number holds — and a recommendation to pilot every defect class on the part is a sign that nothing was actually profiled.
A feasibility audit is a different object. It is a document set, not a presentation, and its usefulness is measured by whether a plant manager can act on it line by line. That means every claim in it carries a verdict, an evidence source, and a boundary. The section of the audit that protects the pilot is the exclusion list — the defect classes it tells you to leave out, and why. A deliverable with no exclusions is a sales artefact wearing an engineering cover.
This is a walk-through of what the sections contain. Which defects turn out to be feasible is a separate question, covered in our breakdown of feasible and infeasible defect classes; how the line’s imaging conditions are measured is covered in the site survey. Here we are looking at the deliverable itself.
What does a CV inspection feasibility audit deliver in practice?
Four documents plus a decision record. Each has a defined shape.
| Section | What it contains | Evidence class |
|---|---|---|
| Defect-class catalogue | Every defect the line’s QA records recognise, one row each, with a feasibility verdict and the physical reason behind it | Buyer’s own QA/scrap records + on-line imaging trials |
| Imaging and fixturing findings | Measured illumination stability across shifts, specularity, part-presentation repeatability, conveyor speed and vibration | Direct measurement on the line |
| Achievable accuracy bands | Per-class detection-rate and false-positive ranges, each tied to an assumed throughput | Trial measurement on collected samples; stated as ranges |
| Cost model | Cost-per-inspected-unit for CV versus the existing manual workflow at the current defect mix | Buyer’s labour and scrap figures + audit-derived integration estimate |
| Go/no-go record | One decision per defect class, with the reason recorded and the excluded classes named | Derived from the four sections above |
Nothing in that table is a single blended number, and that is deliberate. A blended accuracy figure across a mixed defect set is not decision-grade — it hides the class that will fail and the class that was never at risk.
The defect-class catalogue and its verdicts
The catalogue is the spine. Each row is one defect class as the plant’s own QA taxonomy names it — not as a public dataset labels it — and carries a verdict: feasible, conditionally feasible, or excluded. Conditional verdicts state the condition explicitly: “feasible if part presentation is fixtured to ±2 mm rotation,” or “feasible at reduced line speed only.”
The reason field matters more than the verdict. A row that reads excluded — defect is sub-surface, not renderable in visible-light imaging tells the buyer something durable about their process. A row that reads excluded — insufficient confirmed instances in QA history to establish a detection rate tells them the class is unmeasured rather than impossible, which is a different engineering path. We keep those two reasons strictly separate, because collapsing them into a single “no” loses the information the plant needs next year.
Imaging findings written as constraints the pilot inherits
Findings are recorded with the variance actually present, not the variance the vendor’s demo assumed. Illumination measured across three shifts, with the drift figure. Specular response on the finish that is actually running. Part pose repeatability sampled over a production run rather than a staged set of ten parts.
Each finding is written as a constraint the pilot must respect, in language a controls engineer can implement: mounting geometry, exposure window, required fixturing change, and whether the change is a prerequisite or an optimisation. The profiling discipline here is the same one we apply in porting and performance assessments — measure the environment first, then bound what the software can be asked to do inside it.
Accuracy bands, stated as ranges tied to throughput
Any accuracy figure that arrives without a throughput assumption is incomplete. Detection rate and false-positive rate trade against each other through the confidence threshold, and the threshold you can afford is set by how much rework the line can absorb at its rated speed.
So the audit states, per class: a detection-rate band, a false-positive band, and the throughput at which both were measured. Bands are ranges because the measurement comes from a finite sample of confirmed defects — narrowing the range is the pilot’s job, not the audit’s. Where the sample was small enough that the band would be uninformative, the audit says so and the class moves to the unmeasured category rather than getting a number it cannot support.
These bands become the pilot’s success criteria directly: per-class detection rate on the buyer’s own defect set, false-positive rate at rated throughput, and a documented reason for each go or no-go. They also become the reliability targets the system must carry into hardening if the pilot succeeds.
The cost model: cost-per-inspected-unit, both ways
The comparison is not licence fee against inspector salary. It is cost-per-inspected-unit for a CV pipeline against cost-per-inspected-unit for the current manual workflow at the current defect mix, which forces several things into the open: how much manual work is actually displaced once sampling, rework triage, and audit tasks are accounted for; false-positive rework hours at the throughput the line must hold; fixturing and lighting capex; and integration engineering. The total-cost logic behind that comparison is developed further in our analysis of when CV inspection beats manual inspection on total cost.
The economic argument for running the audit at all is simple arithmetic on avoided waste: an audit is typically a fraction of the cost of a single pilot cycle that profiling would have shown to be infeasible. That is a planning heuristic drawn from how these engagements are scoped, not a benchmarked ratio — but the asymmetry is the point. Capital gets committed after the cost model exists, not before.
What a “no-go” looks like on paper
A no-go is not a refusal to work. It is a named class, a named physical or statistical reason, and where applicable an alternative: a different sensing modality, a process-side fix, or a recommendation to keep the class with human inspectors. Our view on where that boundary sits is set out in what CV inspection does not replace.
Practically, the audit runs against a scoped window on the line and needs three things: access to the line during normal production (not a cleaned-down demo state), a set of confirmed defect samples per candidate class drawn from real scrap, and the plant’s QA taxonomy and defect-frequency records. What the buyer owns at the end is the document set itself — catalogue, findings, bands, cost model, decision record — independent of whether they engage anyone to build the pilot. That independence is deliberate; a feasibility deliverable that only makes sense if you buy the next phase is not a feasibility deliverable. The wider decision framing sits in our parent piece on computer vision inspection feasibility in manufacturing, and the underlying capability work is described on our computer vision page alongside how we scope engagements.
Frequently Asked Questions
What does a CV inspection feasibility audit deliver in practice?
A document set, not a deck: a defect-class catalogue with a verdict per class, measured imaging and fixturing findings from the live line, per-class accuracy bands tied to throughput, a cost model in cost-per-inspected-unit terms, and a recorded go/no-go decision per class. The buyer keeps all of it regardless of what happens next.
What is in the defect-class catalogue, and how is a feasibility verdict recorded for each class?
One row per defect class as the plant’s own QA taxonomy names it, each carrying a verdict of feasible, conditionally feasible, or excluded, plus the physical or statistical reason behind that verdict. Conditional verdicts state the condition explicitly, and exclusions distinguish “not renderable by this imaging modality” from “not enough confirmed instances to measure.”
How are achievable accuracy bands stated honestly rather than as a single benchmark figure?
Each class gets a detection-rate band and a false-positive band, both reported at a stated throughput, because the confidence threshold that sets one determines the other. Bands are ranges because the measurement rests on a finite sample of confirmed defects; narrowing them is the pilot’s job. Classes with too few samples are marked unmeasured rather than given a number.
What does the cost model compare, and how is cost-per-inspected-unit derived?
It compares cost-per-inspected-unit for the CV pipeline against the existing manual workflow at the current defect mix — counting displaced manual work realistically, false-positive rework hours at rated throughput, fixturing and lighting capex, and integration engineering. The point is that the ROI decision is made before capital is committed.
What does a ‘no-go’ recommendation look like?
A named class, a named reason, and where one exists an alternative path — different sensing modality, a process-side fix, or leaving the class with human inspectors. The exclusion list is the part of the audit that protects the pilot’s result, so it is written to be defensible line by line.
So the honest question to put to any vision assessment you are offered is not what accuracy it promises, but which defect classes it is prepared to rule out — and whether it will tell you why.
Audit outputs worth paying for
A properly scoped feasibility audit produces three artifacts: annotated sample datasets, model performance benchmarks against your actual defect types, and infrastructure requirement specifications. Revisit it when your workload shifts.
