Short answer
Acceptance standards turn a vague label like "bad solder joint" into an auditable one: the same photo is accept or reject depending on the standard, its revision and the product class chosen. Record which document, edition, clause and class each label follows. Standards supply definitions, not training data, and their text is copyrighted, so check what you may quote or ship.
Why labels need a written definition
An image labeled "defect" or "pass" carries an inspector's judgment. Without a reference, that judgment cannot be audited, reproduced or compared across suppliers. Acceptance standards provide the reference: written criteria for what is acceptable, often with pictures, agreed by an industry and revised on a schedule.
For a robotics or inspection-AI buyer, this changes how you specify labels. Instead of asking for "solder defects", you ask for labels aligned to a named document, edition and class, with the clause recorded per label. Disputes then become checks against text. For the general structure of label schemas, see defect taxonomy and label schema.
What the common standards define
IPC-A-610 provides visual acceptance criteria for electronic assemblies, covering solder joints, placement, cleanliness, coating and marking, in three product classes: Class 1 general, Class 2 dedicated service and Class 3 high performance, the strictest (IPC); secondary sources report the current revision as IPC-A-610J (2024), replacing Rev H (2020), so check the edition yourself. For electronics inspection data, see PCB and solder joint inspection.
IPC/WHMA-A-620 covers materials, methods, tests and acceptability criteria for crimped, mechanically secured and soldered interconnections and related assembly of cable and wire harnesses. The IPC store lists Revision F as current; the standard relies on process control methodology, has three product classes, and makes the user responsible for selecting the class (IPC/WHMA, A-620F). It does not set inspection frequency. Related data is covered in cable harness and connector inspection.
ISO 2859-1 is different in kind: an acceptance sampling system of single, double and multiple plans for inspection by attributes, indexed by acceptance quality limit (AQL), applicable to finished products, components, materials, records and procedures (ISO, 2859-1). It defines how many items to inspect and when to accept a lot, not what a defect looks like. Its role in labeling is covered in AQL sampling context.
What a standard changes about a label
| Element | Why it matters for labels | What to record |
|---|---|---|
| Document and edition | Criteria change between revisions | Standard ID plus revision year |
| Product class | Same feature can pass in one class and fail in another | Class selected by the product owner |
| Clause or section | Makes the label traceable to text | Clause identifier per label |
| Condition categories | Many standards distinguish target, acceptable, process indicator and defect | Which category each label uses |
| Customer overrides | Contracts may add stricter or looser criteria | Drawing or specification references |
| Sampling plan | Governs how many items were inspected, not defect appearance | Plan, inspection level, AQL (if used) |
| Measurement method | Some criteria require measurement, not visual judgment | Instrument and method |
The class decision matters more than buyers often expect. Because the user selects the class, two factories building the same product may legitimately label the same image differently. A supplier's archive labeled under one class cannot be assumed to fit your target class, and relabeling may be needed; see relabeling legacy defect archives.
Illustrative label definition aligned to a standard
# Illustrative only - identifiers and values are synthetic examples
label_definition:
label_id: SOLDER_INSUFFICIENT_001
governing_document: "IPC-A-610" # buyer confirms edition they hold
edition: "<year stated by buyer>"
product_class: 2 # chosen by product owner; labels valid only for this class
clause_reference: "<clause id from the licensed copy>"
decision_values: [target, acceptable, process_indicator, defect]
visual_criteria_summary: "annotator guide, paraphrased in-house; not quoted text"
example_images: internal, 10 per decision value
needs_measurement: false
borderline_policy: escalate to reviewer_B03; log as borderline
reviewed_on: 2026-10-09
sampling_context:
plan: "single sampling, normal inspection" # if applicable
aql: "<set by contract>"
Using standards well in a labeling program
- Pin the document set. List every standard, edition and customer drawing that applies, and freeze it for the project.
- Write an annotator guide in your own words. Annotators need rules and examples, not the standard's pages.
- Label the decision and the evidence. Store accept/reject plus the condition category and clause, so you can remap if the class changes.
- Handle borderline cases explicitly. Standards leave room for judgment near the line; treat these as their own category; see borderline samples.
- Measure disagreement. Even with a written standard, inspectors disagree; keep an audit sample.
Rights and licensing of standards text
Standards are copyrighted publications, usually sold per document or per seat. A label vocabulary that points to clause numbers is generally different from reproducing the text or its figures, but the boundary is a legal question. Ask what the license allows: internal use only, sharing with contractors, quoting in datasets, or embedding figures. The cited IPC store page lists A-620 as a paid standard.
If a supplier delivers labels, ask whether they were produced under a licensed copy and whether any delivered annotator guides contain copied text or images. Avoid shipping standards text inside a dataset unless the license says so. This is not legal advice.
Limitations: what standards cannot do
A standard defines acceptance. It is not a training set: it holds no large body of labeled images, no sensor data and no robot actions, and a few example photos do not train a detector. Standards also do not give pixel-level masks, severity scales for your product or regional variations in practice.
Applying a standard to images has its own limits. Many criteria depend on magnification, lighting, viewing angle or physical measurement that a photo cannot supply, so a photo-based label can only approximate the standard's own method. Standards cannot say how a humanoid should move to inspect or rework a part. They also change; labels tied to a withdrawn revision will drift out of date. Finally, a standard says nothing about the supplier's real process, so provenance still has to come from the supplier.
Worked example: one photo, two classes
Consider a photographed solder fillet that wets the pad on three sides but leaves a small gap on the fourth. Under a general-use class it may be recorded as acceptable; under a high-performance class, the same joint may be a defect or a process indicator. A dataset that stores only "pass" for that image may mislead buyers working to a stricter class. A dataset that stores the class, the clause and the decision category lets you remap the label. That is the practical reason to demand the full label record rather than a single binary flag.
Questions to ask suppliers
- Which standards, editions and product classes govern your labels?
- Who selected the class for each product, and is it recorded per image?
- Are labels stored with clause references and condition categories, or only pass/fail?
- Do you hold a licensed copy of each standard, and does it permit this use?
- Do the annotator guides or deliverables reproduce standards text or figures?
- What customer-specific criteria override the standard, and are they documented?
- Were the images captured with magnification and lighting adequate for the criteria?
- How often do inspectors disagree, and how is that measured?
- How were borderline cases handled and recorded?
- If the standard revises, how will labels be updated or flagged?
Discuss your requirements
If you can name the standards, classes and product types your labels must follow, discuss your humanoid training-data requirements with SourceX. SourceX reviews the requirement and follows up about potential US business sources of inspection imagery and records, checks the data and licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX can also arrange annotation, scoped case by case.
Start from the humanoid training data guide or the inspection, defect and failure data hub. The catalog pages on manufacturing quality records and expert annotations and labels are related.
Discuss your humanoid training-data requirements with SourceX
Sources
- IPC-A-610 Acceptability of Electronic Assemblies — visual acceptance criteria and product classes.
- IPC/WHMA-A-620F Requirements and Acceptance for Cable and Wire Harness Assemblies — harness acceptability criteria, class selection and licensing.
- ISO 2859-1 Sampling procedures for inspection by attributes - Part 1: Sampling schemes indexed by acceptance quality limit (AQL) for lot-by-lot inspection — AQL-indexed sampling schemes.