Roll Genealogy: Traceability for Packaging Converters
A packaging converter's material flow is unforgiving for traceability: rolls of film, foil, and laminate go in, and finished batches of pouches, sleeves, and labels go out. One input roll feeds many output lots. One output lot consumes many input rolls. When a customer calls about a delamination or a seal failure, the question that decides the size of your problem is simple: which input rolls touched that lot, and what else did those rolls touch?
Most converters cannot answer it. This post covers what roll genealogy capture actually requires at the machine, the queries it buys you, why your ERP lot fields and your machine monitoring system each miss half of it, and what it takes to implement on one converting line.
The Converter's Specific Pain
A food brand calls: pouches from lot PKG-0912-B are sealing inconsistently on their line. They want to know the extent of the affected material, and they want an answer today. To answer honestly you need three facts: which rolls of film and foil were mounted during that lot's run, what else was produced from those same rolls, and where any scrap was cut out along the way.
Without recorded genealogy, the honest answer collapses to a date range. If your records only say the lot ran sometime in the second week of September, everything from that window becomes suspect. The arithmetic of that collapse is brutal: a converter running three shifts and six finished lots per day accumulates roughly 156 lots over 26 production days. A "recall everything from that month" position means quarantining and dispositioning all of them, notifying customers who received them, and writing off good stock, because the two rolls actually responsible are somewhere inside 40-plus rolls of consumption you cannot reconstruct.
The complaint itself is usually narrow. One roll with an off-spec corona treatment, or one foil lot with a sealing-lacquer variation, touches a handful of output lots. The cost comes from the width of the answer, not the width of the defect. That width is a data problem, and it is fixable. This is the same genealogy problem described in lot traceability and recall genealogy, but converters feel it more than most industries because the many-to-many roll-to-lot relationship is the normal case, not the exception.
What Roll Genealogy Requires at Capture Time
Genealogy is not a report you generate afterwards. It is a set of facts you record while material is moving, or it does not exist. Four facts, captured at the line:
Roll identity at mount
When an operator mounts a roll at the unwind station, the roll's ID is scanned or keyed into the station terminal. Supplier rolls already carry a lot code on the core label or the roll wrap; if the supplier barcode is unreliable in practice, a keyable field with the printed code is enough to start. The critical part is that the ID is captured against the work order and the station, with a timestamp — not written on a paper traveler that gets transcribed at end of shift, if at all.
Timestamps tied to work order and station
A mount event means: roll X was on station Y, for work order Z, starting at time T. The station and time matter as much as the identity. Two identical rolls issued to the same work order are not interchangeable in a recall if one ran Monday on the pouch machine and the other ran Thursday on the slitter. Resolution to the station and the run window is what keeps the recall narrow.
Scrap recorded with position
Converting runs produce scrap mid-roll: a splice, a print defect, an edge crack. When the operator cuts out a defect, the scrap event should record how much was removed and, where practical, the position along the roll. Position matters because the defect rarely consumes the whole roll. A roll with 30 meters removed at meter 1,850 is still one roll in the genealogy chain — and the record of the removal is what proves the rest of the roll ran clean.
Finished-lot boundaries at rewind or slitter
The output side needs the same discipline: the operator closes a finished lot at the rewind or slitter station, and the system records which mount events were open during that lot's run window. The lot boundary is the operator's decision at the winder — a customer order quantity, a changeover, an end of shift — not an arbitrary calendar cut imposed later.
The Genealogy Query This Buys
With those four capture points, two queries become one-click answers instead of a day of interviews.
Backward: output lot → input rolls → suppliers. Lot PKG-0912-B resolves to film roll F-24081 from supplier A and foil roll C-24077 from supplier B, both mounted during its run window, with the 30-meter scrap cut from F-24081 at meter 1,850 already on record. Your containment conversation with the supplier starts from a specific roll code and run date instead of a hunch.
Forward: input roll → output lots → customers. That is the one that decides recall width. If the suspect material is roll F-24081, the query returns every finished lot whose run window overlapped that roll's mount events, and which customers received those lots. Suppose it fed four lots total: PKG-0912-B plus three siblings. The recall conversation covers four lots and the customers who hold them — not 156.
Both queries carry timestamps and machine context: which winder, which shift, who mounted the roll. When the quality manager asks "was this the night shift winder?" the answer is in the record, not in someone's recollection. If you want to pressure-test the setup before you ever need it in anger, a structured mock recall drill on real captured data will expose the gaps in an afternoon.
Why ERP Lot Fields Can't Do This
ERP lot tracking is lot-in, lot-out. It records that roll lot 24081 was received into the warehouse, and later that some quantity was issued to work order 4711. That is a goods-movement fact, not a production fact. The ERP record has no station, no mount timestamp, no run window, and no position. When two rolls are issued to the same work order, ERP can only say both touched every output lot from that order — even if they actually ran on different winders, three days apart. The recall width you were trying to shrink gets reinflated at the reporting stage.
The gap is resolution, and it is structural: ERP's unit of truth is the transaction, and transactions happen at the warehouse boundary, not at the unwind. MES versus ERP is exactly this division of labor — ERP owns orders, inventory, and costing; the layer at the machine owns who was mounted where, when.
Why Machine Monitoring Alone Can't Do This Either
The opposite half-measure is machine data without material identity. A monitoring system can tell you the winder ran from 06:14 to 09:40 at 180 meters per minute with two micro-stops. It cannot tell you which roll was on the unwind during that window. Speed and tension have no lot code in them.
So monitoring alone reproduces the same collapse from the other direction: "something ran during the complaint window" narrows to nothing without knowing what material was loaded. You need both halves — identity (which roll) from capture at mount, and context (when, where, at what condition) from the machine and operator events. Identity without context cannot answer "what else did this roll touch"; context without identity cannot answer "which roll was it." Genealogy is the join of the two.
Implementation Reality: One Line, Two Capture Points
The scope fear is what stalls most traceability projects, so it helps to see how small the footprint actually is on a single converting line. Two capture points cover it:
- At mount (unwind): operator scans or keys the roll ID, confirms the work order the terminal already shows, presses confirm. One event per roll.
- At rewind (lot close): operator closes the lot, enters good quantity and any scrap with position, presses confirm. One event per finished lot.
A shift that mounts eight rolls produces eight mount events and a handful of lot-close events. At under 10 seconds per event — scan, confirm the pre-filled work order, done — that is under two minutes of added operator time per shift. Compare that to the cost side of the ledger: one customer complaint without genealogy costs days of containment emails, warehouse walks with a clipboard, and a defensive "everything that month" answer that the customer remembers at the next supplier audit.
Two edge cases deserve a decision on day one. Splices: when a new roll is spliced onto the running web, the splice is a new mount event, and everything before the splice belongs to the old roll. Capturing the splice makes the boundary unambiguous instead of folklore. Partial rolls: a roll mounted, partly consumed, and returned to the warehouse keeps its roll ID, so the return event and the next mount event chain onto the same genealogy thread across runs. Neither case needs new hardware — both are just capture rules.
This is the general MES pattern — capture at the point of work, tied to the work order — applied to the converter's specific material shape. If you are still weighing whether the floor needs a system at all, start with what a MES actually is, or the narrower question of whether a small manufacturer needs one.
Frequently Asked Questions
Do we need machine data too?
Not for genealogy. Roll identity capture stands on its own and answers the recall question. Machine data — speeds, tension, stop events — answers a different question: why the defect happened on that roll and not others. It strengthens root cause analysis after containment, and it feeds OEE later. Sequence it that way: identity first, because a narrow recall is worth money on day one; machine context second, because it makes the same event record explain the defect. None of the recall-width arithmetic above depends on having a single sensor connected.
We already track lot numbers in ERP — isn't that enough?
It is enough to know a roll lot was issued to a work order. It is not enough to narrow a recall, because the ERP transaction carries no station, no mount timestamp, and no run window. Two rolls issued to one order looks identical in ERP to two rolls run on different winders days apart — and only one of those scenarios needs a customer notification. Genealogy is what happens between goods issue and goods receipt, and only capture at the line records it.
What about rolls that span multiple finished lots?
That is the normal case, and it is why forward genealogy matters more for converters than for discrete assembly. One 10,000-meter film roll might feed six finished lots across two days. The mount event opens the roll's presence at the station, lot-close events mark each boundary, and the query joins them by overlapping run windows. The record handles the many-to-many relationship by construction — this is precisely the case paper travelers and ERP transactions lose.
Know the Problem Roll Before the Complaint Arrives
Voltrus MES captures roll mounts and lot closes at the station, timestamped to the work order — so backward and forward genealogy is a query, not a fire drill. One line to start.
See Voltrus MES