Scanning journey step by step: from a code on a battery to the right view of the right record

A scan begins with a code on a battery and ends with a view of a record. Between those points lie several steps, each of which can fail in a different way. The steps are: reading the symbol, decoding the payload, resolving the identifier to a record address, authenticating the reader where the tier requires it, applying access rules, and displaying the view for that tier. A reader who treats a scan as one act cannot diagnose a failure, because the failure could sit at any step.

A reader who works step by step can say whether the code was unreadable, the payload was wrong, the resolution failed, the authentication failed, or the display was incomplete. That precision is the purpose of this guide.

What happens when the symbol is read?

Reading the symbol means capturing the QR code image with a camera or an imager and decoding the modules into a payload, normally a URL or a structured identifier. Reading fails when the code is damaged, too small, low contrast, curved, reflective, or covered. Reading also fails when the scanner cannot handle the symbol version or the error correction level, although that failure is rare with modern phones. The reader should check the physical code first: is it visible, clean, undamaged, and within the scanner field of view at a reasonable distance. A code that reads on one phone and not on another may reflect scanner capability, lighting or angle rather than code damage. The diagnostic step is to try a second scanner and a second lighting condition before concluding that the code is at fault.

What happens when the payload is decoded?

Decoding produces a payload, normally a web address that contains the unique identifier. The payload should be short, stable and free from tracking parameters, session codes or marketing additions. A payload that contains a session code will fail on a later scan, because the session has expired. A payload that contains tracking parameters may still resolve, but it creates a denser symbol and a privacy question. The reader should inspect the decoded address before opening it, where the scanner allows, and should check that the domain matches the expected resolver domain for the record system. A payload that points to an unexpected domain, a short link service, or a file download is a reason to stop and verify, because the code may have been replaced or the resolver may have changed. Payload inspection is a security step as well as a diagnostic step.

What happens at resolution and authentication?

Resolution means translating the identifier in the payload into the address of the record. The resolver may be a central registry, an operator system, or a combination of both, depending on the architecture in force. Resolution fails when the identifier is unknown, the resolver is unavailable, or the record has been moved without a redirect. Authentication means establishing the identity and role of the reader where the tier requires it. Public tier access requires no authentication. Authorised tier access requires authentication of the reader and a legitimate interest check, as the system defines it. Authority tier access requires authentication as a notified body, a market surveillance authority or the Commission. A reader who reaches a login prompt for a public field has encountered an access error, not a normal step. A reader who reaches public fields without login, where authorised fields were expected, may be viewing the wrong tier.

What does the journey table summarise?

How is a failed scan reported?

A failed scan is reported step by step: the battery identifier as marked, the scanner type, the lighting and distance, the step at which failure occurred, the message shown, and the date and time. A report that states only that the scan failed cannot be acted on, because the operator cannot tell whether to reprint the code, fix the resolver, correct access rules, or repair the display. A step by step report allows the operator to assign the failure to the right owner: printing, resolver, access, or display. The report should also state whether a second scanner and a second condition were tried, so that scanner specific failure is not mistaken for code failure. Scan failure reports are part of record quality evidence, and they should be retained with the record check history.

What limits apply to a successful scan?

A successful scan proves that a code resolves to a view. It does not prove that the view is complete, current or accurate. Completeness, currency and accuracy require the record checks described in the requirements cluster. A scan is the route to the record, not a check of the record. This guide gives general educational information only and does not give legal advice for a particular battery, scanner or system.