Short answer
A defect detection dataset contains images of products or parts labeled good or defective, ideally with defect type, location and final disposition. For embodied AI this cluster also covers human procedural mistakes and robot manipulation failures. Such data trains inspection, error and failure recognition and builds evaluation sets; it does not teach a humanoid how to handle, reorient or repair what it finds.
Three kinds of failure data
A humanoid that inspects, assembles or serves needs to recognize when something is wrong. That covers three different datasets, and buyers often conflate them.
- Product defects. Images of parts, assemblies or packages with scratches, cracks, missing components, bad seals or misprints. Held by manufacturers with in-line machine vision, quality teams and inspection firms.
- Human task errors. Video of people skipping, reordering or botching steps, used to train error detection and to show what "wrong" looks like in a procedure.
- Robot execution failures. Logs and video of robots dropping, missing, colliding or stalling, used to train failure detection, explanation and recovery.
The first two can come from operating businesses. The third comes from robots, so it follows the specialist route described in the procurement and specialist collection hub. All three sit in the failure-and-quality layer of the humanoid training data guide.
What each kind can support, and what it cannot
| Data | Supports | Does not support |
|---|---|---|
| Labeled defect images | Supervised defect classification and segmentation; inspection test sets | Handling the part to find the defect; transfer to a different line without new data |
| Defect-free (nominal) image sets | Anomaly detection fitted on normal appearance | Defect type names or severity |
| Human mistake video | Step recognition, procedural error detection, examples of recoverable errors | Robot actions or the forces involved in correcting an error |
| Robot failure logs | Failure detection and explanation; recovery planning | Failures on a different embodiment or task family without adaptation |
The split between labeled defects and nominal-only data shapes what you buy. MVTec AD's training set is defect-free only, and its test set carries pixel-precise ground truth for more than 70 defect types (Bergmann et al., 2021). PatchCore, for example, fits on nominal images alone (Roth et al., 2021). Real archives rarely separate cleanly, and Real-IAD proposes a fully unsupervised setting that allows defective images in training, closer to an unsorted plant archive (Wang et al., 2024).
Which regime you need is covered in anomaly detection vs supervised defect classification.
Defects are not only surface marks. MVTec LOCO separates structural anomalies such as dents from logical ones such as a missing or misplaced component (Bergmann et al., 2022), which is closer to what a humanoid checking an assembly or a packed order must catch. Imbalance is the norm: VisA, for example, holds 9,621 normal and 1,200 anomalous images (Zou et al., 2022).
Human error data shows what goes wrong in procedures. Assembly101 recorded unscripted assembly with natural mistakes and introduced a mistake-detection task (Sener et al., 2022); IndustReal places many of its procedural and execution errors only in the validation and test splits (Schoonbeek et al., 2023), a useful pattern for evaluation design.
Robot failure data is scarce and often synthetic. REFLECT built the RoboFail dataset of failed executions and summarizes multisensory robot data for an LLM to explain failures (Liu et al., 2023). AHA generates failure trajectories by perturbing successful simulated demonstrations (Duan et al., 2024). RoboMIND does include real-world failures: about 5,000 failure demonstrations recorded with their causes (Wu et al., 2024).
Two limits recur. Inspection images show the defect, not how an inspector turned the part or changed the light to see it; that is the subject of active inspection by humanoids. And a model trained on one line, plant or product often degrades on the next, as domain shift across lines explains.
Sourcing routes
Existing assets. Manufacturers with in-line cameras or automated optical inspection keep reject images and sometimes passing images; quality teams keep nonconformance reports, dispositions and corrective actions; inspection firms hold client imagery they may not be free to license. Ask early whether passing images were retained, how long images are kept, and whether images can be joined to dispositions. Designs and customer identities usually appear in the data; see confidentiality in defect data.
Commissioned work. Rare and borderline defects often need deliberate collection: imaging physical defect samples on your own rig, recording staged procedural mistakes, or collecting near-threshold parts. If no existing asset fits, SourceX can scope a commissioned collection of new recordings.
Specialist route. Robot failure data comes from businesses already running robots, whose vendors often control the logs, or from specialist collection on your own embodiment. See robot manipulation failure datasets.
Public benchmarks. Many are non-commercial. MVTec AD, for example, is licensed CC BY-NC-SA 4.0. Check terms before building on them; the public dataset commercial license checks page lists what to look for.
How to evaluate inspection supply
- Label provenance. Was "defect" set by a camera threshold, an operator flag or a final material-review disposition? Only the last records the business's final decision on the part.
- Class balance. Counts per defect type, and how many rare classes have fewer examples than you would need to evaluate them.
- Leakage risk. Whether images can be split by part serial, lot, line and date so near-duplicates never straddle train and test.
- Imaging metadata. Camera, optics, lighting and recipe per image, and when any of them changed.
- Label agreement. Whether a double-labeled sample exists to estimate inspector disagreement.
- Retention. Date range kept and whether passing images were deleted.
- Rights. Whether customer-owned designs or client-owned inspection data are involved.
Illustrative record linking an image to its outcome
# Illustrative only — synthetic identifiers and values
image_id: img_line04_000918
part: housing_P220 (rev C)
station: aoi_station_04, recipe R-17, ring light, 12 MP
timestamp: 2026-02-11T09:42:07Z
lot: lot_7731
camera_call: reject (score 0.83)
inspector_call: defect, scratch, cosmetic
final_disposition: use-as-is (MRB_2026_0412)
defect_mask: masks/img_line04_000918.png
split_key: lot_7731 # all images from this lot stay in one split
The gap between camera_call, inspector_call and final_disposition is the reason to ask for linked records rather than reject folders.
Key pages in this cluster
| Group | Page | What it answers |
|---|---|---|
| Foundations | Anomaly detection vs supervised defect data | Which labeling regime your model needs |
| Foundations | Active inspection by humanoids | Why handling and viewpoint matter |
| Foundations | Synthetic vs real defects | When generated defects help |
| Foundations | Rare defects and class imbalance | Planning for scarce defect types |
| Product defects | Sourcing defect image datasets | The core sourcing guide for defect imagery |
| Product defects | In-line machine vision reject archives | What camera archives typically hold |
| Product defects | Inspection images linked to outcomes | Joining images to dispositions |
| Product defects | Assembly completeness verification | Missing and misplaced components |
| Product defects | Golden samples and reference images | Reference appearance for comparison |
| Product defects | Nonconformance reports | Quality records as training and test data |
| Labels | Defect taxonomy and label schema | Consistent defect classes |
| Labels | Defect severity and disposition labels | Severity and outcome fields |
| Labels | Pixel-level defect segmentation | Mask annotation specification |
| Labels | Inter-inspector agreement | Measuring label noise |
| Labels | Relabeling legacy defect archives | Fixing old labels before use |
| Human and robot failures | Human procedural mistake videos | Error detection from human task video |
| Human and robot failures | Robot manipulation failure datasets | Specialist failure data from robots |
| Human and robot failures | Failure reasoning data | Explanations, causes and corrections |
| Human and robot failures | Service-task failure examples | Spills, drops and breakage |
| Evaluation and rights | Defect detection evaluation sets | Building held-out inspection tests |
| Evaluation and rights | Leakage in defect datasets | Same part, lot or line across splits |
| Evaluation and rights | Domain shift across lines | Why models degrade on new lines |
| Evaluation and rights | Confidentiality in defect data | Designs, customers and suppliers |
Neighboring clusters
Pick errors and package damage are warehouse-specific; start at pick errors and mispicks in the warehouse hub. Assembly verification sits close to manufacturing and assembly, equipment wear to maintenance and tool use, and open, closed, clean or dirty states to product and object data. For catalog context, see manufacturing quality and inspection records and licensing images and inspection photos.
Discuss your requirements
Name the parts or tasks, the defect or error types, how labels must be defined and how the test set must be held out. Send the requirement to SourceX: it looks for US businesses that hold suitable records, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. SourceX reviews each requirement and follows up about potential sources; a request does not guarantee a match.
Tell SourceX what your evaluation set needs to cover
Sources
- The MVTec Anomaly Detection Dataset — defect-free training, pixel ground truth and non-commercial license.
- Beyond Dents and Scratches: Logical Constraints in Unsupervised Anomaly Detection and Localization — structural vs logical anomalies.
- SPot-the-Difference Self-Supervised Pre-training for Anomaly Detection and Segmentation — VisA normal and anomalous image counts.
- Real-IAD: A Real-World Multi-View Dataset for Benchmarking Versatile Industrial Anomaly Detection — defective images present in training data.
- Towards Total Recall in Industrial Anomaly Detection — anomaly detection fitted on nominal images only.
- Assembly101: A Large-Scale Multi-View Video Dataset for Understanding Procedural Activities — unscripted assembly with mistakes.
- IndustReal: A Dataset for Procedure Step Recognition Handling Execution Errors in Egocentric Videos — errors concentrated in evaluation splits.
- REFLECT: Summarizing Robot Experiences for Failure Explanation and Correction — robot failure explanation and the RoboFail dataset.
- AHA: A Vision-Language-Model for Detecting and Reasoning Over Failures in Robotic Manipulation — simulated failure generation.
- RoboMIND: Benchmark on Multi-embodiment Intelligence Normative Data for Robot Manipulation — real-world failure demonstrations with causes.