A New Barcode is a Window Into the Product's Entire Lifecycle
Blog Series: Food Data and Traceability, part 2.
The familiar EAN barcode is being replaced. The GS1 2D code is coming to packaging and retail checkouts, and with it, a packet on the shelf stops being a mute object: one scan can open up where the product came from, when it was made, and what happened to it along the way.
But here is the part that often gets missed. The code itself is small. Its value depends entirely on the data behind it.
The code is a key, not a container
GS1 Finland gives sound advice on getting started: you don't need to begin with the hardest option. A GS1 2D code with just the GTIN and a web link can be pre-printed on packaging, exactly like today's barcodes — no changes to production required.
The real benefits, as GS1 also points out, arrive with dynamic data: batch number, date, and the information that changes with every production run. And their recommendation is to keep the code light and use it as a key to backend systems, rather than packing everything into the code itself.
Which raises the practical question every production and quality team eventually asks: where does that backend data come from — and how does it stay accurate without anyone typing it in?
Dynamic data is born on the production line
Batch numbers, timestamps, production conditions, quality measurements — none of this is created in an office system. It is born on the line: on filling machines, ovens, extruders, packaging lines, sensors.
This is what our Owl platform does. Owl collects data directly from production — from a single device up to a complete line — and ties it to the batch and the product. That means the 2D code on the package can act as a key to information such as:
- Origin and location data – which site, which line, which raw material lot
- Traceability – the chain of events from raw material intake through processing to packing
- Production data linked to the product – process conditions, quality measurements, and timestamps for the exact batch in your hand
Instead of assembling this by hand for audits or recalls, it accumulates automatically, batch by batch, as production runs.
Start with one device, scale to the whole line
The same "you don't have to do everything at once" principle applies on the data side. Owl scales from a small pilot to a full production line, and from device level to line level. A typical path looks like this:
- Pick one product and one line — often even one critical device.
- Start collecting the data that the 2D code should be able to answer for: batch, time, conditions, quality.
- Connect that data to the GTIN and batch identifiers used in the code.
- Expand device by device, line by line, as the benefits become visible.
A pilot like this doesn't require a system overhaul, and it produces something concrete to show buyers, auditors and consumers alike.
Define the content together
GS1's final piece of advice is one we sign with both hands: deciding what the code should reveal is not an IT task alone. It needs packaging, production, quality, marketing and IT at the same table — and a partner who has connected production environments to data chains before.
That is the work we do daily at Trineria, and as a member of the Food Data Finland network we build it on GS1 standards, so the data you share is understood across the whole chain.
Thinking about what your packaging could tell the world? Get in touch — a small pilot is a very good place to start.
Next up: Finnish Food on Export Markets – Data Helps to Get there