Skip to content

Concept buildA worked example of how we would build this for a typical business. Not client work: no client, no client data, no achieved results.

Custom AI

Concept build

Visual Defect Triage for a Small Manufacturer

A concept build for a camera inspection step that sorts machined parts into pass, flagged or unsure with a detector trained on the plant’s own images. Unsure parts always go to a person, and the quality team keeps the final say on scrap and rework.

Concept build cover: a generic circuit board prop lit in graphite grey on dark ink, not client hardwareConcept build
Built for
A typical small manufacturer
Industry
Manufacturing
Market
India market
Typical timeline
6–10 weeks from defect catalogue to a supervised station, mostly image collection and labelling

The brief

The problem this concept answers

A typical small manufacturer in India inspects parts by eye at the end of the line. Inspectors are skilled, but attention fades over a long shift, defect calls vary from person to person, and the evidence for a rejected batch is often a tally sheet rather than an image. When a customer returns a lot, the plant struggles to show what was checked and when. Off-the-shelf vision systems are usually priced and specified for high-volume lines, and general-purpose AI models know nothing about this plant’s parts or what its customers count as a defect.

In the first version

  • Defect catalogue and one instrumented inspection station
  • Labelling workflow and a locked hold-out set
  • Detector training, versioning and per-class evaluation
  • Review queue and flagged-items view
  • Drift checks and a re-labelling routine

Left out on purpose

  • Automatic scrap or line-stop decisions
  • Dimensional measurement and metrology
  • Roll-out to more stations or plants, a later phase
  • Camera and lighting hardware, which the plant sources

Explainer

The build in seven slides

Watch the narrated video, step through the slides or read the transcript.

Explainer · 7 slides · about 44 s

Concept build

Concept build: Visual Defect Triage for a Small Manufacturer

Concept build, explained in 7 slides: a concept build for a camera inspection step that sorts machined parts into pass, flagged or unsure with a detector trained on the plant’s own images.

Concept build: Visual Defect Triage for a Small ManufacturerConcept build

Custom AI

Visual Defect Triage for a Small Manufacturer

A concept build for a camera inspection step that sorts machined parts into pass, flagged or unsure with a detector trained on the plant’s own images.

Concept build: Visual Defect Triage for a Small ManufacturerConcept build

The problem

What a typical small manufacturer is up against

A typical small manufacturer in India inspects parts by eye at the end of the line. Inspectors are skilled, but attention fades over a long shift, defect calls vary from person to person, and the evidence for a rejected batch is often a tally sheet rather than an image.

Concept build: Visual Defect Triage for a Small ManufacturerConcept build

The approach

How we would build it, in 5 steps

  • Defect catalogue and image collection
  • Labelling and a locked hold-out set
  • Detector training with licences in mind
  • Confidence thresholds and a review queue
  • Plant deployment and drift checks
Concept build: Visual Defect Triage for a Small ManufacturerConcept build

Architecture

How the pieces connect

Diagram: Station camera to Image prep (photo); Labelled images to Training job (labelled set); Image prep to Defect detector (frame); Training job to Defect detector (weights); Defect detector to Threshold rules (class + score); Threshold rules to QC inspector (unsure); Threshold rules to Inspection log (pass or flag); QC inspector to Inspection log (decision); Inspection log to Flagged items view (by shift).

Diagram with 9 parts: Station camera (source), Labelled images (source), Image prep (processing), Training job (processing), Threshold rules (processing), Defect detector (model), QC inspector (human), Inspection log (system of record), Flagged items view (system of record).

Connections:

  • Station camera → Image prep (photo)
  • Labelled images → Training job (labelled set)
  • Image prep → Defect detector (frame)
  • Training job → Defect detector (weights)
  • Defect detector → Threshold rules (class + score)
  • Threshold rules → QC inspector (unsure)
  • Threshold rules → Inspection log (pass or flag)
  • QC inspector → Inspection log (decision)
  • Inspection log → Flagged items view (by shift)
Concept build: Visual Defect Triage for a Small ManufacturerConcept build

Demo · sample run

Sample data

Three parts at one inspection station

Scenario: Three parts at one inspection station

  1. Part photographedSample part: a machined bracket from batch B-12, under fixed station lighting.Done
  2. Clear passNo defect above the threshold; the image and result are logged.Done
  3. Defect flaggedSecond part: burr on the mounting edge, high confidence, held for a rework decision.Failed
  4. Unsure resultThird part: a possible scratch, with confidence between the two thresholds.Needs review
  5. Inspector reviewsThe image is shown with the area marked; the inspector confirms a scratch.Handed to a person
  6. Logged for retrainingThe decision is saved and the image joins the next labelling round.Done
Concept build: Visual Defect Triage for a Small ManufacturerConcept build

Typical targets

What we would measure it against

  • Typical target80–90% recall on the plant’s known defect classesBasis: Hold-out evaluation on the plant’s own labelled images, agreed before launch and reported per class
  • Typical targetUnsure parts always reviewed by a personBasis: Design property: results between the agreed thresholds go to the review queue, never to pass or scrap
  • Typical targetFalse rejects held under a ceiling the quality team setsBasis: Thresholds are tuned on the hold-out set;
  • Typical targetAn image and a decision on record for every inspected partBasis: Design property: each inspection logs the image, result, confidence and any reviewer decision
Concept build: Visual Defect Triage for a Small ManufacturerConcept build

Next step

Scope a build like this for your business

A free call to map your workflow, data and the first version.

Book a Strategy CallFree 30-minute call · no commitment

Slide 1 of 7

Architecture

How the pieces connect

  • Station camera· source
  • Labelled images· source
  • Image prep· processing
  • Training job· processing
  • Threshold rules· processing
  • Defect detector· model
  • QC inspector· person
  • Inspection log· system of record
  • Flagged items view· system of record
Show the architecture diagram

Architecture of the Visual Defect Triage for a Small Manufacturer concept: Station camera → Image prep (photo); Labelled images → Training job (labelled set); Image prep → Defect detector (frame); Training job → Defect detector (weights); Defect detector → Threshold rules (class + score); Threshold rules → QC inspector (unsure); Threshold rules → Inspection log (pass or flag); QC inspector → Inspection log (decision); Inspection log → Flagged items view (by shift).

Diagram with 9 parts: Station camera (source), Labelled images (source), Image prep (processing), Training job (processing), Threshold rules (processing), Defect detector (model), QC inspector (human), Inspection log (system of record), Flagged items view (system of record).

Connections:

  • Station camera → Image prep (photo)
  • Labelled images → Training job (labelled set)
  • Image prep → Defect detector (frame)
  • Training job → Defect detector (weights)
  • Defect detector → Threshold rules (class + score)
  • Threshold rules → QC inspector (unsure)
  • Threshold rules → Inspection log (pass or flag)
  • QC inspector → Inspection log (decision)
  • Inspection log → Flagged items view (by shift)

Connections

  1. Station camera → Image prep (photo)
  2. Labelled images → Training job (labelled set)
  3. Image prep → Defect detector (frame)
  4. Training job → Defect detector (weights)
  5. Defect detector → Threshold rules (class + score)
  6. Threshold rules → QC inspector (unsure)
  7. Threshold rules → Inspection log (pass or flag)
  8. QC inspector → Inspection log (decision)
  9. Inspection log → Flagged items view (by shift)

Sample run

One run, step by step

Three parts at one inspection stationSample data
  1. Part photographedRoutine

    Sample part: a machined bracket from batch B-12, under fixed station lighting.

  2. Clear passRoutine

    No defect above the threshold; the image and result are logged.

  3. Defect flaggedStopped

    Second part: burr on the mounting edge, high confidence, held for a rework decision.

  4. Unsure resultNeeds care

    Third part: a possible scratch, with confidence between the two thresholds.

  5. Inspector reviewsA person takes over

    The image is shown with the area marked; the inspector confirms a scratch.

  6. Logged for retrainingRoutine

    The decision is saved and the image joins the next labelling round.

Build plan

How we would build it

Typical timeline
6–10 weeks from defect catalogue to a supervised station, mostly image collection and labelling
Stack
  • Fixed camera and controlled lighting
  • Open-source labelling tool
  • YOLOX or another Apache-2.0 detector
  • GPU workstation or private cloud
  • Review queue for unsure parts
  • Flagged-items view by shift and batch
  • Locked hold-out evaluation set
  1. Defect catalogue and image collection

    We start from the quality team’s defect catalogue: each class, an example and what the customer accepts. A fixed camera and controlled lighting go on one inspection station, specified with the plant’s maintenance team, and we collect images of good and defective parts across shifts and batches. Rare defects get a longer collection window, not synthetic images.

  2. Labelling and a locked hold-out set

    Quality staff label images in an open-source labelling tool, and a second inspector re-labels a sample so we can see how often people agree. Before any training, a hold-out set of the plant’s images is locked away and the recall target for each defect class is agreed against it, so the test cannot be tuned to flatter the model.

  3. Detector training with licences in mind

    We fine-tune a permissively licensed open-weight detector, such as YOLOX under Apache-2.0, because some popular detector releases use the AGPL, which sits badly with closed plant software. Training reports recall and false rejects per class, and every model version is stored with the exact data it was trained on.

  4. Confidence thresholds and a review queue

    Each result carries a class and a confidence score. A confident result passes or flags the part automatically; anything between the agreed thresholds goes to a review queue, where an inspector sees the image with the suspect area marked. The inspector’s decision is logged, and the image joins the next labelling round.

  5. Plant deployment and drift checks

    Inference runs on a GPU workstation at the station or in the plant’s private cloud, so images stay under the plant’s control. A flagged-items view shows defects by shift, batch and class, and a weekly drift check compares recent results with the hold-out baseline, prompting re-labelling when lighting, tooling or material changes.

Typical targets

What we would measure it against

Targets for a typical business of this kind, not achieved results. A real project measures its own baseline first.
  • Typical target

    80–90% recall on the plant’s known defect classes

    Basis: Hold-out evaluation on the plant’s own labelled images, agreed before launch and reported per class

  • Typical target

    Unsure parts always reviewed by a person

    Basis: Design property: results between the agreed thresholds go to the review queue, never to pass or scrap

  • Typical target

    False rejects held under a ceiling the quality team sets

    Basis: Thresholds are tuned on the hold-out set; flagged parts are reviewed, not scrapped automatically

  • Typical target

    An image and a decision on record for every inspected part

    Basis: Design property: each inspection logs the image, result, confidence and any reviewer decision

Your project

What a real project adds

  • A data-path review

    Where each piece of data goes and which provider processes it; residency is checked per project, never assumed.

  • Model choice tested on your data

    Candidate models compared on a held-out sample of your own documents or images before one is chosen.

  • The deployment shape that fits

    On accounts in your name, self-hosted open-weight models, or on-premise as an Enterprise scope.

  • Monitoring and a refresh plan

    Drift checks, a review cadence and the steps to update the model or the index when your data changes.

Decisions this concept leaves for scoping

  • Automatic scrap or line-stop decisions
  • Dimensional measurement and metrology
  • Roll-out to more stations or plants, a later phase
  • Camera and lighting hardware, which the plant sources

FAQ

Questions about this build

Is a manufacturer running this defect triage system?

No plant is. This concept build describes how we would set up inspection for a typical small manufacturer in India, and the bracket, batch and defects in the demo are sample data. The recall range can only be confirmed on a real plant’s own hold-out images, which is why that test set is agreed before any training starts.

How many labelled images does the detector need?

It depends on the part and the defect. A few hundred labelled examples per defect class is a common starting point; clear, frequent defects need fewer, while subtle or rare ones need more. Image collection usually sets the timeline, which is why the plan starts collecting on the first day.

Will the system decide which parts get scrapped?

No. It sorts parts into pass, flagged and unsure, and people decide what happens to anything that is not a clear pass. Scrap and rework stay quality-team decisions, recorded with the image the system flagged, which also gives the plant evidence to show a customer when a lot is questioned.

Why does the detector’s licence matter?

Because it decides what the plant may do with its own software. Some widely used detector releases are under the AGPL, which can bring source-sharing obligations or the cost of a commercial licence. We default to permissively licensed detectors such as YOLOX under Apache-2.0 and record the licence of every model and library in the handover.

Do our part images have to leave the factory?

No. Training can run on a workstation on site or in a private cloud account the plant controls, and inference runs at the station. Images stay in the plant’s own storage; the only time they move is if the plant chooses to rent cloud compute for a training run.

Worked examples

More concept builds for this service

Concept builds are worked examples, not client work.

See all concept builds
Concept build

Custom AI

Private Knowledge Assistant on Your Own Cloud

A concept build for an internal assistant that answers staff questions from a firm’s own documents, inside the firm’s cloud account. Every answer cites its sources, and retrieval is filtered by each person’s existing document permissions, so nobody gets an answer built from a file they could not open.

  • Professional services
  • US market
  • Oct 2026

Next step

Have a workflow in mind? Let’s scope it together.

Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.

Free 30-minute call · no commitment

Send an RFP or security questionnaire