A recall is not executed against your database. It is executed against physical objects sitting in a distribution centre, and the only thing tying them back to your records is whatever got marked onto them at production time. That last link, from business system to printhead, is the least examined part of most traceability architectures and the place they most reliably fail.

How Traceability Data Gets From Your ERP to the Production Line

Most traceability projects are scoped as software problems and budgeted accordingly. There is a database of lots and batches, a set of records satisfying a regulatory requirement, and a reporting layer that can answer questions about where a given batch went. All of that gets built properly, tested, and signed off. Then somebody asks how the lot number actually reaches the physical product, and the answer turns out to be an operator typing it into a keypad at the start of each shift.

That last link is where traceability systems break, and it is consistently the least examined part of the architecture. A recall is not executed against your database. It is executed against objects sitting in a distribution centre, and the only thing connecting those objects back to your carefully maintained records is whatever got physically marked onto them. If that mark is wrong, missing, or unreadable, the record behind it is worth very little.

What Traceability Actually Requires

In Canada the baseline for food is set by the Safe Food for Canadians Regulations, which came into force in January 2019 and are enforced by the Canadian Food Inspection Agency. The core obligation is often described as one step back and one step forward: a business must be able to identify who supplied a given food and who it was sent to next. The requirement that matters for this discussion is the linking mechanism, because records alone do not satisfy anything if the physical goods cannot be tied back to them. That link is a lot code or equivalent identifier applied to the product or its packaging.

Similar logic runs through the other regulated categories. Drug labelling under federal regulation requires lot numbers and expiry dates. Medical device manufacturers face unique device identification requirements in the markets they sell into. Canadian manufacturers exporting to Europe are picking up further obligations, including the packaging regulation and the phased introduction of the Digital Product Passport, which begins with batteries and expands from there. The pattern across all of them is the same: a record system on one side, a physical identifier on the other, and a legal requirement that the two correspond.

What a GS1 Barcode Actually Contains

The reason this is a data problem rather than a printing problem becomes clear once you look at how a compliant barcode is structured. A GS1-128 barcode is not a single number. It is a concatenation of fields, each introduced by a two-digit Application Identifier that declares what the following characters mean. Application Identifier 01 introduces the GTIN identifying the product. AI 10 introduces the batch or lot. AI 17 introduces an expiry date. AI 21 introduces a serial number.

That structure is what makes the code machine-parseable anywhere in the supply chain. A receiving system scanning it does not need a private agreement with the sender about field order or lengths, because the identifiers declare the structure inline. It also means the encoded content has to be assembled correctly at print time from several distinct data sources, since the GTIN comes from the item master, the lot comes from the production order, and the expiry is usually calculated from a production date and a shelf-life rule. Getting any of those wrong produces a barcode that scans perfectly and says something false, which is worse than one that fails to scan at all.

The Data Path From Business System to Printhead

The architecture that works looks roughly the same everywhere. The business system, whether that is an ERP or an MES sitting between the ERP and the floor, holds the authoritative values. A message template is defined for each product and label format, containing fixed text plus named variable fields for the elements that change. At production time, the system pushes the current values into the template and the marking equipment prints the resolved result. Industrial coding equipment is generally built to accept exactly this, exposing an interface over Ethernet or serial so an upstream system can select a template, set field values, and trigger printing without anyone touching the device.

The important design decision is which system owns the data. When the printer holds a stored message that an operator selects and edits, the printer has quietly become a second source of truth, and the two sources will diverge. When the printer holds only templates and receives all variable content from the business system at print time, there is one source of truth and the marking equipment is a rendering endpoint. The second arrangement is more work to commission and eliminates an entire category of failure. Vendors who take integration seriously, including REA Jet, describe interfaces to business systems as a standard part of the offering rather than a custom project, and that is the right expectation to hold suppliers to.

The Failure Mode Nobody Budgets For

The scenario that produces most real-world traceability failures is mundane. A line changes over, an operator selects the message for the new product, and either picks the wrong stored message or types a date incorrectly. Nothing alerts anyone, because from the equipment’s perspective it did precisely what it was told. Production runs for hours producing correctly printed, entirely wrong codes.

What makes this expensive is that the error is discovered downstream, usually by a customer or a regulator, at which point the recall scope is everything produced since the last known-good point. Manufacturers who have been through this tend to arrive at the same conclusion, which is that removing manual entry from the changeover process is worth more than almost any reporting feature. The data was correct in the ERP the entire time. It simply never made it to the product.

Verification Closes the Loop

Sending correct data to the printer establishes intent, not outcome. The mark still has to be physically legible on the substrate, and industrial printing has plenty of ways to degrade: a partially blocked nozzle, ink adhesion failing on an oily surface, product moving at a distance the system was not set up for, or contrast too low against the packaging. A code that a scanner cannot read is functionally an unmarked product, and it will be discovered at the receiving dock rather than on your line.

This is why inline verification exists as a distinct capability. A camera or scanner positioned immediately after the printhead reads back every code, confirms the content matches what was sent, and grades the print quality against the standards that govern code readability. Failures trigger rejection at the point of production rather than a return weeks later. The architectural point is that verification should report back to the same system that supplied the data, closing the loop so the business system knows not merely that it requested a code but that a readable, correct one exists on a physical object. Suppliers offering inline verification alongside the marking equipment make this considerably easier to implement than stitching together hardware from separate vendors.

Sunrise 2027 Raises the Data Volume Sharply

The change worth planning around is GS1’s Sunrise 2027 initiative, which is moving retail point of sale from traditional linear barcodes to 2D codes such as DataMatrix and QR. The retail scanning implication gets the attention, but the consequence for anyone building product data systems is the payload. A linear barcode at retail has historically carried a GTIN and little else. A 2D code carrying GS1 Digital Link can hold the GTIN plus batch, expiry, serial number, material composition for recycling, and a resolvable web address pointing to product data hosted online.

That is a substantially larger and more structured payload, assembled per item rather than per product line, and it has to come from somewhere. For most manufacturers the data already exists across the ERP, the quality system, and the item master, having never been required in a single machine-readable field on the package before. The integration work of assembling it correctly at print time is the real project, and it is considerably larger than swapping a barcode symbology. Organizations that already run serialized 2D marking, principally pharmaceutical manufacturers, have solved this problem before, which is why their implementation patterns are worth studying regardless of your sector.

Why the Marking Hardware Constrains the Software

There is a hard limit that software architects consistently discover late. A dense 2D code needs sufficient resolution and contrast to be readable, and not every marking technology can produce it on every surface at every line speed. Large character equipment designed to put legible text on a corrugated case is not going to render a fine DataMatrix. High-resolution systems can, but the achievable result depends on the substrate, the standoff distance, and how fast the product is moving.

This means the physical marking method should be specified alongside the data model rather than after it. Deciding that every unit will carry a serialized 2D code commits you to a technology capable of producing that code on your actual product at your actual line speed, and that is a question about substrate and throughput before it is a question about software. High-resolution thermal inkjet systems are the common answer for dense codes on packaging, while other substrates and speeds point elsewhere. Establishing what is physically achievable early prevents the specific and painful outcome of designing a data structure that the production line cannot actually print.

Designing for the Boundary, Not the Database

Traceability is an integration problem wearing the costume of a compliance problem. The regulatory requirement creates the obligation, the database satisfies the recordkeeping, and neither does anything useful unless correct data reliably reaches a physical mark that a scanner can read weeks later in somebody else’s warehouse. The weakest point in nearly every implementation is the boundary between the business system and the production line, and it is weak specifically because it spans two teams that rarely scope work together.

The systems that hold up share a few characteristics. The business system owns the data and the marking equipment renders it, with no manual entry at changeover. Verification reads codes back and reports outcomes to the same system that supplied them. The marking technology is chosen against the real substrate and line speed rather than assumed. None of that is exotic, but all of it has to be decided deliberately, and Sunrise 2027 is going to expose every organization that deferred those decisions.