Per-weld traceability: from the sensor to the module record

A weld grade on a dashboard is easy. A weld grade that someone can find three years later, from the QR code of a returned module, and trust, is much harder. That second kind is what per-weld traceability is about.

I look at this from the data side. Models are only part of the job; the rest is making sure every result can be found, explained and defended. This post walks through the chain from the sensor sample to the module record, and the places where it usually breaks.

What per-weld traceability means

Per-weld traceability is the ability to retrieve, for any single weld in a battery module, its quality result together with the evidence and context that produced it. In practice that means six linked elements:

If any of the six is missing, the record becomes weaker evidence. Without the joint position you know a module had a bad weld but not which one. Without the model version you cannot explain why a weld graded "acceptable" in March and "marginal" in July.

The chain, step by step

Here is the chain we recommend for weld inspection:

1. Trigger. The welding controller signals the start of a weld, or the system detects it from the signal envelope.
2. Capture. Each sensor records its stream: sound, images, process signals.
3. Time stamp. Every stream is time-stamped on the hub, and each node's measured clock offset is written into the record together with its uncertainty.
4. Segment. The streams are cut into one segment per weld, using the trigger and the joint sequence of the weld programme.
5. Seal. Each data segment gets a cryptographic hash, and the segment is entered in a manifest.
6. Grade. The model computes features, an anomaly score, a class and, where trained, a severity grade.
7. Bind. The result is bound to module identifier, joint position, station and model version.
8. Publish. The record goes to the plant's quality system or MES, and the raw segments stay in retention according to policy.

Steps 3, 5 and 7 are where most systems cut corners, so they get their own sections below.

Identifiers: getting the keys right

The module identifier should be created once, as early as possible, and read at every station afterwards. If the module will become part of a battery that needs an EU battery passport, use the same identifier, or a documented one-to-one mapping. Article 77(3) of Regulation (EU) 2023/1542 requires the passport's unique identifier and QR code to comply with ISO/IEC 15459 parts 1 to 6, or equivalent standards; part 4 covers individual products and product packages. My colleague Clemens Saur explained why weld data itself is not a mandatory passport field, and where it can still be added voluntarily, in where weld quality data fits in the battery passport, but the identifier is the bridge between the two.

Joint positions need a scheme that does not depend on the weld programme's step numbers. Step numbers change when a programme is edited. A geometric address such as cell index, terminal and busbar does not.

A common trap is re-using module carriers or fixtures as identifiers. A fixture ID tells you where a module was, not which module it was.

Time: stamps, clock offsets and uncertainty

Each sensor node has its own oscillator, and clocks drift apart. If an audio stream and a camera stream disagree in time by even a small offset, a model that combines them can learn the wrong relationship, and an engineer reviewing a weld can misread cause and effect.

There are two honest ways to deal with this. One is a hardware timing reference; a hardware sync timer is in development with LarsLabs. The other is to measure the offset between each node and the hub continuously, and store that offset, with its uncertainty, in every record. Then any later analysis can correct for it and knows how far to trust the correction. The background is covered in time-stamping multimodal sensor data: why clock offsets matter.

What does not work is pretending the problem does not exist. A record that silently assumes all clocks agree cannot be audited.

Integrity: proving a record has not changed

A weld record may be used years later to decide a warranty case. At that point someone will ask: is this the data as it was recorded, or has it been edited since?

Three mechanisms answer that question:

• Per-segment hashes. A SHA-256 hash of each data segment, stored separately, shows whether the segment has changed.
• A versioned manifest. The manifest lists which segments belong to which record, with their hashes and the software version that wrote them.
• An append-only journal. Every event, including corrections, is added rather than overwritten, so the history stays visible.

The EU battery passport sets a similar bar for its own data. Article 78 of the Battery Regulation requires that "data authentication, reliability and integrity shall be ensured". Internal weld records are not bound by that article, but applying the same principles makes them far more useful as evidence.

Gaps need the same care. If a node loses power, the record must show the gap explicitly rather than stitching the data across it. A cognitive sensor that reports its own signal health and dropouts also helps here: a dropout is visible in the record instead of passing as a stream of apparently bad welds. The post on self-monitoring sensors and false alarms explains the principle.

Formats and interfaces

Records only stay useful if they can be read without the original software. Open formats matter more than elegant ones.

The table lists formats that suit different consumers. In practice a weld record is often a JSONL line with references to NWB or video files, plus a CSV export for the quality team.

Where the chain usually breaks

A short checklist of typical failure points:

• the module identifier is read after welding, so the first welds are bound to the previous module
• joint positions come from programme step numbers that changed after an edit
• the model version is not stored, so results cannot be explained after an update
• raw data is deleted after grading, so no one can re-examine a disputed weld
• clock offsets are neither corrected nor recorded
• power interruptions leave silent gaps
• results reach the MES, but the evidence stays on a local disk with no reference

How NeuroControls approaches this

Our recording software covers the time and integrity parts of this chain: every stream is time-stamped on the hub, node clock offsets are measured and written into each record with their uncertainty, segments are hashed with SHA-256 and listed in a versioned manifest, and an append-only journal keeps the history. After a power loss, the gap is logged, alerted and reported, and recording resumes by itself. Data exports to NWB, MKV/HEVC, JSONL and CSV; MES integration is available on request. Details are on the software page and the cognitive sensor page.

In the DIGIBATT360 research project (February 2026 to January 2029), coordinated by VARTA Storage with Fraunhofer IIS, Circulor, VRI and NeuroControls, we contribute cognitive sensing and returned-goods analysis. For weld inspection, the verdict is designed to go into the module's battery passport: not as a mandatory field, but as a voluntary entry linked to the module's unique identifier. More on that in the post on DIGIBATT360 and the battery passport data space.