Short answer
Error-proofing records list the mistakes a manufacturer expects at a step and the guard placed against each, such as a fixture that rejects a reversed part. They are text and images, not demonstrations. They can help define failure cases, test scenarios and labels for perception and evaluation, but they contain no motion or force data and cannot train control.
The buyer's problem
When a robot is evaluated on an assembly task, the interesting question is rarely whether it can do the correct sequence once. It is whether it notices, avoids or recovers from the mistakes people make. Collecting those mistakes from footage is slow, because well-run lines suppress them. The documents that describe them are a shortcut: a plant that has bothered to design an error-proofing device has, by definition, written down what error that device is meant to catch.
That makes error-proofing records unusual supporting material for an evaluation lead. They are not footage and they do not teach manipulation, but they can say what failure cases are realistic for a given step, how a plant classifies them and which ones matter enough to engineer around. This page explains where such records live, what they look like and how to source them with sensible expectations.
What the records are
Poka-yoke is the practice of designing a process or fixture so a mistake is either impossible or immediately visible. In records, it appears in several forms:
- Failure mode and effects analysis worksheets. IEC 60812 explains how FMEA, including the FMECA variant, is planned, performed, documented and maintained, and states that it applies to hardware, software and processes, including human action (IEC, 2018). A process FMEA row typically names a step, a way it can go wrong, an effect and a control. The standard is generic; each plant's worksheet format and scoring scheme are its own.
- Control plans and device lists. Tables of stations, the error-proofing device at each, what it detects and what happens on detection.
- Device drawings and photos. Images of keyed fixtures, sensors, gauges and visual aids installed at stations; the fixture side is discussed in fixturing and part orientation.
- Detection and escape logs. Records of when a device stopped a defective unit, or when a defect passed it and was found later.
- Corrective-action reports. Narratives explaining why a new guard was added after an escape.
Quality management systems generally rely on documented information and on evaluating performance and improving; ISO 9001:2026 lists support (including documented information), operation, performance evaluation and improvement among its requirements and is stated to be generic and optional to certify against (ISO, 2026). A plant may therefore hold these documents under a quality system, but do not assume any particular plant holds any particular record; that is a question for each supplier.
What the records can support
For a robotics buyer, the value lies in structure rather than motion:
- Failure taxonomies. A list of observed error types per step gives evaluation scenarios a basis other than guesswork. If the records describe a reversed polarized part or a missing fastener, a perception test can include those states.
- Label vocabularies. Names and codes for defects and error types can seed annotation schemes for images and video.
- Scenario design. An evaluation lead can build held-out test cases from error classes that a site considers significant, then check them against separate recorded material.
- Image links. If device photos or defect images are attached, they can add visual examples of the error state.
For visual material of the defects themselves, see sourcing defect image datasets for visual inspection models and the catalog page on manufacturing quality records.
Illustrative record schema
| Field | Example (synthetic) | Why a buyer cares |
|---|---|---|
| step_id | S-040 seat_connector | Joins the record to a step in footage or a job breakdown |
| error_mode | connector_half_seated | Candidate failure class for evaluation |
| detection_method | latch_sensor, visual_check, gauge | Shows whether the guard is a device or a person's check |
| control_action | line_stops, unit_flagged | Explains what follows detection |
| evidence_ref | img_0192 | Pointer to an image, if attached |
| escape_flag | found_at_test | Marks errors that slipped past the guard |
| revision_date | 2026-03 (synthetic) | Records change over time |
This is an Illustrative layout; actual worksheets vary and may be spreadsheets, scanned forms or entries in a quality system.
Existing assets, commissioned work and mixed routes
Error-proofing records are an existing-assets purchase almost by definition: a quality team writes them for its own use. Preparation is the main task. Records need to be parsed into fields, cross-referenced to images where those exist and cleaned of customer and supplier names, part numbers and any proprietary tolerances.
A commissioned route is less natural, but a buyer might ask a plant to record the correct and incorrect versions of a step, with the guard in place and out of place, as a test fixture for perception. That is a collection request, not an archive purchase, and it needs site approval. The sibling topic of line stoppages is covered in andon, downtime and stoppage logs, and the rework side in rework and repair operations.
Quality and acceptance criteria
Ask for a sample of rows before committing. Acceptable records typically show a consistent vocabulary, step IDs that map to a real job breakdown, a date and revision on each entry, and enough narrative to understand why the error matters. Reject sets where entries are boilerplate, dates are missing or the same cause is described in contradictory terms across sheets. Check the join keys early: if a record cannot be tied to a step in standard work and job breakdown sheets or to timestamps in MES records aligned to video, its use is limited to general vocabulary.
Limits: what these records cannot support
Error-proofing records say that an error is expected and guarded against. They do not show a person or robot handling the part, and they contain no actions, forces or trajectories. Training a humanoid's control requires robot or teleoperation data, not records, SOPs, footage or recognition labels alone. Records also describe intended controls, not actual behavior, so a documented guard may be missing, bypassed or changed on the floor.
Other limits:
- Selection. Plants document errors they anticipated or experienced; unanticipated failures are absent.
- Scoring noise. Severity and occurrence scores depend on local judgment and should not be treated as measurements.
- Absence is not evidence. A step with no listed error is not proven error-free.
Keep the use of this material clear. Records about errors at a step should serve evaluation of robot perception and recovery. They should not be turned into measures of which individual operator makes mistakes, and any license or consent should say so.
Permissions and provenance
Records usually name customers, suppliers, part numbers and, sometimes, employees who raised or closed a corrective action. A plant may be bound by supplier or customer confidentiality terms. Redaction or removing identifiers does not settle permissions, since the underlying content may remain restricted even when names are removed. Ask who owns each record type and whether any content is third-party. See manufacturing data confidentiality. This is not legal advice.
Questions to ask suppliers
- Which record types exist for the steps you care about: FMEA rows, control plans, device lists, escape logs or corrective actions?
- In what format are they held, and how many are scanned rather than structured?
- Do entries carry step IDs and revision dates?
- Are device photos or defect images attached, and under what rights?
- How does the plant score or classify errors, and has the scheme changed?
- Which names, part numbers and customer references must be removed, and who decides?
- Do the documents reflect current practice, or are they historical?
- Could the plant record a controlled demonstration of the error and its guard?
Discuss your requirements
If your evaluation set needs realistic failure cases, describe the steps, record types and permitted uses to SourceX. SourceX looks for US businesses that may hold suitable records, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. It follows up about potential sources; a request does not guarantee a match. The humanoid training data guide and the manufacturing hub show the neighboring sourcing routes, and the catalog page on SOPs, playbooks and knowledge bases covers related procedural documents.
Tell SourceX what your evaluation set needs to cover
Sources
- IEC 60812:2018 Failure modes and effects analysis (FMEA and FMECA) — how FMEA is planned, performed, documented and maintained, including for processes.
- ISO 9001:2026 Quality management systems - Requirements — generic requirements including documented information.