Welding Dataset for Traceability: Fields, Labels and Sampling

A welding dataset becomes useful only when a production team can move from one signal or image back to the exact weld, part, procedure, equipment state, and inspection decision that created it. A folder of waveforms is not yet a traceable dataset. Neither is a spreadsheet of pass/fail labels with no link to raw evidence.

This guide defines a practical data structure for production welding: what to record, how to sample different channels, how to label outcomes without hiding uncertainty, and how to preserve the chain from process event to quality decision. It supports both audit retrieval and later analytics while keeping measured evidence separate from acceptance authority.

Key takeaways

• Give every weld event a stable ID before collecting high-rate signals.
• Store intended setpoints and measured values as separate fields with separate provenance.
• Choose sampling per channel; one rate is rarely appropriate for electrical, gas, thermal, visual, and status data.
• Keep observations, defect classifications, inspection results, and final dispositions as distinct records.
• Split machine-learning data by jobs, parts, batches, or time windows, not by adjacent frames from the same weld.
• Version schema, labels, transformations, and acceptance references so old results remain reproducible.

Table of contents

• What a production welding dataset must answer
• Core schema and field groups
• Sampling and time synchronization
• Labels, inspection outcomes, and leakage control
• Traceability and governance
• Implementation plan and acceptance tests
• Frequently asked questions

What a Production Welding Dataset Must Answer

Start from retrieval questions, not sensor availability. For any selected weld, the record should answer:

1. What part, joint, pass, and production order does this event belong to?
2. Which approved procedure and revision were intended for the work?
3. Who or what executed it: welder, operator, robot program, station, and equipment chain?
4. What did the equipment command, and what did independent or embedded sensors measure?
5. What inspections were performed, where, by which method, and with what result?
6. Who made the final disposition, against which documented acceptance basis?
7. Has any source value, label, or disposition changed since initial capture?

These questions align data engineering with welding quality. The official scope of ISO 3834-2:2021 covers comprehensive fusion-welding quality requirements in workshops and at field sites, but the purchased standard, contract, and applicable product rules determine required records for a specific job. A generic dataset template cannot replace that review.

For procedure qualification work, the ISO 15614-1:2017 catalog entry identifies procedure tests and their range of qualification within its stated materials and processes. That makes procedure identity and revision essential context, but it does not mean a waveform alone qualifies a procedure.

Core Schema and Field Groups

Use linked records rather than one extremely wide table. High-rate channels belong in time-series storage; identities, approvals, and revisions belong in structured metadata. Join them through immutable IDs.

1. Identity and genealogy

The minimum chain is job_id, part_id, joint_id, weld_id, and pass_id. Add assembly, serial, drawing, route, fixture, and batch IDs where those distinctions affect containment or analysis. Never use a timestamp as the only weld ID: clocks can shift, two stations can run simultaneously, and records can be imported later.

Material heat, consumable batch, shielding-gas batch, and repair-cycle identifiers may be relevant depending on process and contract. Keep unknown values explicitly unknown. Empty strings and reused placeholders such as N/A make later missingness analysis unreliable.

2. Procedure and execution context

Store WPS identifier and revision, process code used by the plant, joint design, material group, nominal thickness, position, pass sequence, operator or program identity, and station configuration. For manual steel welding, the current catalog page for ISO 9606-1:2012 covers qualification testing of welders in its stated scope. For mechanized and automatic welding, ISO 14732:2025 covers qualification of welding operators and weld setters within its scope. Your dataset should reference the actual personnel or program record used by the quality system rather than infer qualification from a name.

3. Commands, setpoints, and measured signals

Separate three layers:

Every channel needs units, sensor ID, range, resolution, sampling configuration, calibration or verification status, acquisition software version, and quality flags. If data comes from a controller rather than a separate sensor, identify that source. “Voltage” is not a sufficient field name when one value is a command, another is controller feedback, and a third is measured at the workpiece.

The ISO 17662:2025 scope addresses calibration, verification, and validation of equipment used to control relevant welding process variables in its defined production context. Use the applicable requirements to design equipment-status links; do not copy a universal interval into the dataset without checking the governing documents.

For electrical and process acquisition, WeldTrace records voltage, current, and wire-feed speed simultaneously at 25 kHz, with gas flow at 10 Hz. Those product-specific rates illustrate why each channel needs its own acquisition metadata. They are not universal sampling prescriptions for every welding process or sensor.

4. Outcomes and evidence

Inspection data should identify method, procedure, equipment, inspector or automated system, inspection time, coverage, location reference, observation, and result. Preserve source evidence links without embedding sensitive personal data into filenames.

An outcome hierarchy can contain:

• process observation, such as unstable current or interrupted gas flow;
• geometric or visual observation, such as undercut indication or bead-width deviation;
• NDT indication with method-specific location and sizing;
• engineering evaluation;
• final disposition: accept, repair, rework, concession, reject, or pending review.

Do not collapse these into one defect=true column. An indication is not always a rejectable imperfection, and a model alert is not an authorized disposition.

Sampling and Time Synchronization

Select rates from the measurement objective

Sampling should begin with the fastest phenomenon the team needs to resolve, the sensor and conditioning bandwidth, and the analysis to be performed. Electrical arc behavior, wire-feed variation, gas flow, robot position, thermal frames, and high-speed images operate at different useful rates. Oversampling every slow channel wastes storage; undersampling a fast channel destroys information before analytics begins.

Document for each channel:

• nominal and observed sample rate;
• sensor bandwidth and acquisition range;
• timestamp source and clock domain;
• trigger, pre-trigger, and post-trigger rules;
• dropped-sample and saturation flags;
• any filtering, resampling, compression, or unit conversion.

Keep raw samples separate from resampled analysis tables. A derived 100 Hz feature stream can be convenient for dashboards while the original waveform remains available for a later investigation.

Synchronize before combining modalities

Use one event timeline and record offsets between devices. Store UTC for cross-system ordering and a monotonic clock or sequence counter for local sample continuity. Confirm synchronization under real cycle conditions, including controller restarts, network interruptions, daylight-saving changes, and files imported after production.

For visual evidence, PoolDrop high-speed weld-pool imaging and process signals become more valuable when frame timestamps resolve to the same weld_id and pass_id. A screen showing two charts at the same time is not proof that their underlying samples are aligned.

The OPC Foundation companion-specification model explains how domain-specific information models add semantic interoperability to OPC UA. Whether a plant uses OPC UA, a PLC protocol, files, or APIs, the same principle matters: transport delivers values; a controlled information model defines what those values mean.

Estimate storage before rollout

Calculate storage from channel count, bytes per sample, sample rate, duty cycle, expected welds, and retention period. Add images, indexes, replicas, and backups separately. Then test actual compression on representative production data rather than assuming a ratio.

A good retention design has at least three tiers:

1. raw event evidence for the contractually required or risk-based period;
2. normalized records and derived features for search and trend analysis;
3. compact summary records for long-term genealogy after large raw files expire, if expiration is permitted.

Retention is a policy decision. Deleting source evidence because a model feature table exists can make later results impossible to reproduce.

Labels, Inspection Outcomes, and Leakage Control

Define labels as controlled records

Each label should carry a vocabulary version, source, method, location, timestamp, author or system, confidence where meaningful, and links to supporting evidence. If reviewers disagree, retain both observations and the adjudicated result. Do not overwrite uncertainty with false precision.

Use hierarchical labels where possible. For example, process_anomaly / gas_flow / interruption is more reusable than a free-text note. Keep acceptance status separate because one observed condition may be acceptable under one requirement and rejectable under another.

Avoid training-test leakage

Randomly splitting individual waveform windows or adjacent image frames often places near-duplicates from the same weld in both training and test sets. The test score then measures familiarity with that weld, not generalization to new production.

Split by an independent unit that matches deployment risk: production job, part, batch, joint family, operator, station, site, or time period. Keep all samples from one weld on one side of the split. For a future-site claim, reserve a site; for drift over time, reserve a later period.

The NIST AI Risk Management Framework treats validity, reliability, transparency, and ongoing risk management as lifecycle concerns. In welding, that means documenting dataset scope and limitations, testing against the intended production population, monitoring changed inputs, and keeping human authority where the approved workflow requires it.

The original FAIR Guiding Principles paper focuses on making digital assets findable, accessible, interoperable, and reusable. A factory dataset does not need to be public to benefit from persistent IDs, rich metadata, provenance, controlled access, and machine-readable relationships.

Track dataset versions

A dataset version should freeze:

• record-selection query and time window;
• included and excluded weld IDs;
• schema and unit definitions;
• label vocabulary and adjudication state;
• transformation and feature-code versions;
• train, validation, and test partition rules;
• known missingness, bias, and equipment changes.

Hash manifests and source-file inventories where practical. A model version without a resolvable dataset version cannot be independently investigated after a production change.

Traceability and Governance

The dataset should strengthen the existing quality record, not create a parallel truth. Connect it to digital WPS, PQR, continuity, and traceability records and to the plant’s controlled document and approval workflow.

Define ownership by layer:

Role-based access should prevent an analytics pipeline from rewriting approved quality records. Record corrections, approvals, exports, and deletions in an audit trail. Protect personal and customer data with the minimum fields needed for the use case.

When integrating shop-floor records with enterprise systems, the welding data historian and MES guide covers architecture and retention, while the MES and ERP traceability guide focuses on production-order and business-system links. This article’s narrower job is defining the dataset that those systems exchange.

Implementation Plan and Acceptance Tests

Phase 1: map one production family

Choose one repeatable joint family with known WPS, stable identifiers, measurable signals, and available inspection results. Map current records from order to disposition. List missing joins before adding new sensors.

Phase 2: capture a representative pilot

Collect normal production, planned starts and stops, parameter changes within approved bounds, repairs, known inspection outcomes, equipment restarts, and missing-data scenarios. Do not manufacture defect labels from process alarms. Use real inspection and authorized disposition records.

Phase 3: validate retrieval and data quality

Sample at least one normal weld, one repaired or held weld, and one record spanning a restart or shift change. For each, prove:

• every signal resolves to the correct weld and pass;
• units, channel source, and acquisition settings are available;
• procedure, operator or program, equipment status, and materials resolve correctly;
• inspection evidence and final disposition remain distinct;
• clock offsets and dropped samples are visible;
• a correction creates a new version rather than erasing the old record.

Phase 4: release a governed dataset version

Freeze the manifest, schema, label dictionary, known limitations, and split logic. Have welding quality review technical meaning and data engineering review reproducibility. Then connect derived features to dashboards or welding anomaly-detection workflows without turning a statistical alert into an undocumented acceptance rule.

Acceptance criteria for production use

A production dataset is ready when a reviewer can select a weld and retrieve its complete evidence chain, reproduce a derived feature from retained source data, identify every label’s origin, detect missing or unsynchronized channels, and determine which document and person authorized the final disposition.

If any of those checks depends on tribal knowledge, the dataset is still a collection project rather than a controlled production record.

Frequently Asked Questions

What should a welding dataset contain?

A useful welding dataset connects a stable weld ID to part and joint identity, procedure revision, material and consumable context, operator or program, equipment status, time-aligned process signals, inspection outcomes, label provenance, and record-version history.

What sampling rate should welding data use?

There is no universal rate for every signal. Select each channel’s rate from the phenomenon being measured, sensor bandwidth, required analysis, storage budget, and validation tests. Preserve acquisition settings and time synchronization as dataset metadata.

How should weld defects be labelled for machine learning?

Keep observations separate from final dispositions. Record the label vocabulary, source method, inspector or system, timestamp, confidence where applicable, affected location, governing acceptance basis, and every later revision.

Can setpoints replace measured welding parameters?

No. Setpoints describe intended machine settings; measured signals describe what the process delivered. Store both when available, identify their sources, and never merge them into one ambiguous field. The welding parameter monitoring hub explains the input-side record in more detail.

How should a welding dataset be split for model validation?

Split by an independent production unit such as job, part, batch, joint family, site, or time window rather than randomly splitting adjacent samples from the same weld. This reduces leakage between training and evaluation data.

Does collecting welding data prove compliance?

No. A dataset can support traceability and evidence retrieval, but compliance depends on the applicable contract, regulation, procedure, product standard, approved control plan, equipment controls, and authorized technical decisions.