I ran into a useful event-day reminder this week: data can be correct while the physical product carrying it still fails.
The ticket contained a valid QR code. The scanning software understood the credential format. Yet one printed ticket could sit in front of a phone camera without being recognised reliably.
That sent the investigation across a boundary that is easy to ignore in software.
The problem was not only what the QR code contained. It was how the code became a physical object.
Correct data is only one layer of correctness
A QR code can encode exactly the right value and still be difficult for a camera to detect.
The scanner first has to recognise that there is a QR code in the image before it can decode what is inside it. Print scale, contrast, surrounding space, the ticket design and the camera environment all affect that first step.
That distinction mattered because another ticket could still be recognised.
Intermittent success made the problem initially look like scanning logic. Comparing the rendered tickets made the other layer visible: the code needed enough visual separation from the design around it for a camera to locate it consistently.
The encoded credential was correct. Its presentation was not robust enough.
The screen was not the final medium
This is where browser testing can give false confidence.
A ticket viewed on a laptop is not the same artifact as a downloaded PDF, a printed ticket, a screenshot on somebody's phone or a piece of paper being scanned under poor event lighting.
The software eventually has to survive the medium the user actually carries to the door.
The fix therefore was not complete when the component looked better in the browser. I needed to inspect the rendered artifact and test the interaction the way event staff would actually experience it.
There were two different failure layers
The incident also reinforced that QR reliability has at least two separate sides.
One is generation: can the ticket produce a machine-readable code with enough visual separation to survive its design and output medium?
The other is detection: can the device and browser find and decode that code reliably under real camera conditions?
Improving one does not automatically prove the other.
Thinking about those as separate boundaries made the debugging much clearer than treating "scanner not working" as one undifferentiated problem.
Fallbacks have to preserve the same truth
I also wanted the fallback path to behave like a fallback rather than a second ticket-validation system.
Different devices may need different ways to recognise a code, but once something has been recognised, the same product rules should decide what that credential means.
That separation lets the capture layer evolve without quietly creating different admission rules depending on which phone happened to scan the ticket.
The implementation details of that boundary stay private because this is part of a live event-day system. The reusable lesson is that compatibility code should change how an input is acquired, not create a second source of business truth.
What changed in how I test tickets
The regression test for this class of problem cannot stop at "the QR library returned valid output."
For something intended to cross the boundary between software and the physical world, I now want evidence at multiple levels: the underlying credential is correct, the rendered artifact preserves the visual properties required for detection, and the finished ticket is tested on the actual type of device and medium it is supposed to survive.
That is a much better definition of "the QR works."
What I would show publicly
The portfolio does not need a real customer ticket or a live scannable credential to prove this work.
The right visual is a synthetic ticket crop showing the QR presentation before and after the rendering correction, using a deliberately non-production pattern.
That demonstrates the actual engineering problem without exposing an event, attendee, ticket reference, scanner session or any part of the private admission system.
The incident was small in code and large in consequence.
That is common in product engineering. Sometimes the most important bug is not in the algorithm. It is at the boundary between the thing the software thinks it produced and the thing a person actually has to use.