Manufacturing & Industrial
Quality Defect Detection API
Manual inspection catches most defects, disagrees with itself between shifts, and cannot tell you on Friday what was going wrong on Tuesday.
- Machine vision integrators
- Manufacturers
- Industrial software vendors
- Contract manufacturers
- Packaging and food processors
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Visual inspection on a production line has a consistency problem before it has an accuracy problem. Two inspectors apply the same written standard differently, the same inspector applies it differently at the end of a twelve-hour shift, and nobody can reconstruct afterwards why a particular batch was rejected. The resulting scrap and rework numbers are noisy enough to be hard to improve against.
Automated inspection changes that in two ways. It applies one criterion every time, which makes the measurement comparable across shifts and lines. And it produces a structured record per unit — what defect, where, how severe — which turns quality from a monthly yield percentage into something that can be correlated with machine, material lot, operator and process setting.
The requirement that governs everything is labelled examples. A classifier that distinguishes a scratch from a contamination mark from an acceptable surface variation has to be trained on images a quality engineer has labelled as exactly that. Several hundred examples per defect class is a realistic minimum, and most plants have none, because defective parts get scrapped rather than photographed. Collecting that dataset is normally the first phase of the project rather than something assumed to exist.
Who buys this
Machine vision integrators, Manufacturers, Industrial software vendors, Contract manufacturers, Packaging and food processors
What the API returns
What comes back
- Defect classification per unit with class, location and severity
- Inspection score with a pass, fail or review decision against your acceptance criteria
- Bounding regions and masks your operator interface can overlay on the image
- Confidence per detection, with low-confidence units routed to human review rather than decided
- Anomaly detection for unusual appearance that matches no trained class
- Process correlation linking defect rates to machine, lot, shift and settings
- Per-class performance reporting, so a weak class is visible rather than hidden in an overall figure
- Structured inspection records retained for traceability and batch investigation
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/inspect | Classify one image or image set for a unit |
| POST | /v1/inspect/batch | Inspect a batch asynchronously |
| POST | /v1/labels | Submit labelled examples to extend or correct a class |
| GET | /v1/classes/performance | Per-class precision, recall and sample counts |
| GET | /v1/analysis/correlations | Defect rates against machine, lot, shift and settings |
| GET | /v1/units/{id}/record | Full retained inspection record for one unit |
Request and response
illustrativeRequest
{
"unit_id": "unit_2026102100441",
"line_id": "line_03",
"images": [
{ "view": "top", "uri": "s3://plant-vision/line03/2026-10-21/441_top.png" },
{ "view": "side", "uri": "s3://plant-vision/line03/2026-10-21/441_side.png" }
],
"context": { "product": "P-440", "material_lot": "LOT-7712",
"machine": "press_02", "shift": "B" },
"acceptance_profile": "P-440_standard"
}Response
{
"unit_id": "unit_2026102100441",
"inspected_at": "2026-10-21T16:11:04Z",
"decision": "fail",
"inspection_score": 38,
"detections": [
{
"class": "surface_scratch",
"confidence": 0.93,
"severity": "major",
"view": "top",
"region": { "x": 412, "y": 188, "w": 96, "h": 14 },
"measured": { "length_mm": 7.4, "threshold_mm": 3.0 }
},
{
"class": "edge_burr",
"confidence": 0.61,
"severity": "minor",
"view": "side",
"region": { "x": 55, "y": 302, "w": 31, "h": 22 },
"note": "Confidence below auto-decide threshold; included for review"
}
],
"anomaly": { "flagged": false, "score": 0.12 },
"model": {
"version": "qd-2026.09",
"classes_trained": 7,
"class_sample_counts": { "surface_scratch": 1840, "edge_burr": 420,
"contamination": 310, "delamination": 41 }
},
"class_confidence_note": "delamination has 41 training examples; detections of this class are reported for review only",
"correlation_hint": { "material_lot": "LOT-7712",
"scratch_rate_vs_baseline": 2.4 }
}Where the data comes from
| Your production images | Captured on the line under the lighting and fixturing the model will run in — images from a lab bench do not transfer well |
| Quality engineer labels | The defining input. Class, region and severity labelled by someone who owns the acceptance standard |
| Existing inspection and scrap records | Historical reject reasons, useful for establishing which classes matter and roughly how often they occur |
| Process and machine data | Settings, speeds and temperatures at the time of production, which is what makes correlation analysis possible |
| Material lot and traceability data | Lot genealogy, so a defect pattern can be traced back to incoming material |
| Written acceptance standards | Your own specification documents, which define where the thresholds actually sit |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Image models trained on your own line's captures, because lighting, fixturing and camera geometry dominate transferability and a model trained elsewhere rarely survives the move
- Severity measured against your written thresholds where the defect is dimensional, so a decision is traceable to the specification rather than to a model's opinion
- Separate anomaly detection alongside classification, which is what catches novel defect types the classifier has never been shown
- Explicit per-class confidence thresholds, with under-sampled classes configured for review-only rather than auto-decide
- Augmentation and synthetic variation for rare classes, used cautiously and reported as such, since augmented examples are not substitutes for real ones
- Active learning: units near the decision boundary are surfaced for labelling first, which is the cheapest route to improving a weak class
- Per-class performance reporting with sample counts, so overall accuracy cannot hide a class that effectively does not work
- Drift monitoring on image statistics, because a cleaned lens, a replaced lamp or a new material supplier shifts the input distribution
What it changes for the business
Consistent criterion
One standard applied every time makes yield comparable across shifts and lines for the first time.
Defect data worth analysing
Structured per-unit records let quality correlate defects with lot, machine and settings.
Inspector effort redirected
Confident decisions clear automatically; people spend their time on the ambiguous units.
Traceability
Retained inspection records answer batch investigation questions that a yield percentage cannot.
How it fits into your product
How it embeds
- Inline inspection via synchronous calls, or batch for offline and audit use
- Edge deployment at the line where latency or network isolation requires it, which is the common case
- Detections returned as regions your operator HMI can overlay on the live image
- Label submission endpoint so quality engineers correct the model as part of normal work
- Results pushed into your MES or quality system against the unit and lot record
- Per-product acceptance profiles, so thresholds change with the product rather than the code
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
What do you need before this can work at all?
Labelled images from your own line — realistically a few hundred examples per defect class, captured under production lighting and fixturing. Most plants do not have them, because defective parts get scrapped rather than photographed. So the first phase is usually a capture and labelling exercise: install the vision setup, retain images, and have a quality engineer label them over several weeks. That is unglamorous and it is the phase that determines whether the rest works. We would rather scope it explicitly than promise a model and then discover the dataset does not exist.
What about defects that almost never happen?
They are the hard limit of this approach and we will not paper over it. A defect class with twenty examples cannot be learned reliably, however the training is arranged — and those rare classes are often the most expensive ones. Three honest responses: configure the class for review-only so detections go to a human rather than a reject gate, rely on the anomaly detector to flag unusual appearance without naming it, and keep collecting. Augmentation helps a little and is not a substitute for real examples. If your critical defect occurs twice a year, automated classification of that specific defect is not realistically available.
Can you use a model trained at another plant?
Rarely, and only as a starting point. Lighting, camera angle, fixturing, material finish and the acceptance standard itself all differ, and models are sensitive to all of them. Pretrained weights shorten training; they do not remove the need for your own labelled data.
Does this replace the inspector?
It replaces the repetitive part of the judgement and leaves the ambiguous part. Low-confidence units, anomaly flags and under-trained classes all route to a person by design. A configuration that auto-rejects on every detection regardless of confidence would be cheaper to run and worse, and we would advise against it.
Do images have to leave the plant?
No. Edge deployment at the line is the usual arrangement, both for latency and because production imagery is frequently considered confidential. Training may need images moved to a GPU environment, which can be your own, and that is agreed during discovery rather than assumed.
Related blueprints
Predictive Maintenance API
Failure probabilities, anomaly scores and maintenance recommendations for industrial equipment, served to your CMMS or plant software.
Factory Production Optimisation API
Bottleneck prediction, throughput forecasts and schedule recommendations from the production data a plant already records.
Industrial Parts Matching API
Cross-references equivalent components across manufacturers using part numbers, dimensions and technical specifications.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.