What Actually Belongs on a Traceability Label

A traceability label's only job is to answer one question fast: if this unit turns out to be a problem, what else was made under the same conditions, and where did it go? Most of the labels we've seen in the wild (printed from a general-purpose label template, or typed fresh for each run in a word processor) technically have "a bunch of information on them" without actually answering that question quickly under pressure.

Here's what the label needs to carry to actually work, and why each field earns its place.

The minimum that makes a label traceable

• Product identity. The SKU or part number, and a human-readable product name. Not just one or the other, the SKU disambiguates variants that look identical on the floor, and the name is what a person scans for visually.
• Production date. The actual date the unit was made, not the date the label was printed. These drift apart more often than you'd expect, especially on a line that runs overnight or across a shift change.
• Line identifier. Which physical line produced it. If a quality issue traces back to a specific extruder, die, or calibrator, this is what narrows "somewhere in the plant" down to "this line, this week."
• Run or lot number. One identifier that ties every unit from the same continuous production run together. This is the field a recall actually pivots on: "pull everything with lot number X," not "pull everything from that general timeframe."
• Order or customer reference. Which order this production run fulfilled. Without this, a lot number tells you what was made, but not where it went, and "where did it go" is the other half of a recall.

What's situational but usually worth adding

• Part number, if it's distinct from the SKU. Some shops track an internal SKU and a customer-facing or industry-standard part number separately. If yours does, both belong on the label, whichever one the customer's receiving dock is looking for.
• Company or facility branding, if you run multiple plants or co-pack for other brands. A label that's correct in isolation is still ambiguous if it doesn't say which facility it came from.
• A scannable barcode of the lot number. Once you have a real lot number, the marginal cost of also printing it as a Code 128 barcode is close to zero, and it's the difference between someone reading fifteen characters correctly under fluorescent lights at 6am and a scanner reading them instantly, every time.

Why this usually breaks down in practice

The failure mode isn't "we forgot a field." It's that these fields live in different places. The order lives in the order system, the line and run come from whoever's running the schedule, and the lot number gets assigned (or worse, invented) at print time, so someone has to manually reconcile all of it onto a label template before every run. That reconciliation step is where errors get introduced: a lot number that doesn't actually match what's in the production log, a date that's wrong because the label was pre-printed the night before and the run slipped.

The fix isn't a better label template. It's not needing to reconcile in the first place, generating the label directly from the same record that already has the line, the date, the run, and the order attached to it, so there's nothing to retype and nothing to get out of sync.

That's the model RunMark uses: every scheduled production run gets a stable lot number (built from date, line, and run), and label generation pulls product, line, date, run, order reference, and part number straight from that run record, with an optional scannable barcode of the lot number on the label itself. Nothing on the label is typed twice, because nothing on the label is typed at all after the run is scheduled.

If you're setting up labels for the first time, start with the five fields in the first list above. Everything else is worth adding once those are solid, not before.