> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://tieback.io/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server.

# Lesson 1: The Scan Path End to End

> Academy Foundations Module 4 Lesson 1: what actually happens between a scan and a displayed record, and why each hop in that path has an owner.

**Module 4, Lesson 1 of 4. About 8 minutes.**

## Orientation

Someone in your organisation will eventually ask "what happens when a customer scans it", and the
honest answer is a sequence of handoffs, not a single technical event. If you cannot describe that
sequence, you cannot say who is accountable when it breaks: when the carrier scans but the record is
stale, when two people see different things, or when the record does not load at all. This lesson
gives you the sequence, in the order it actually happens.

Public data is available to anyone who scans the carrier. Restricted data is available only to
specified user groups, such as market surveillance authorities or repairers, and is withheld from
everyone else at the point of delivery. The distinction is enforced when the data is served, not
by the carrier.

## Learning Objectives

## From a Printed Square to a Screen

A scan looks instant. It is not one step, it is a short chain, and every link in that chain is
something a different part of the organisation or a different vendor is responsible for.

**The physical carrier is read.** A phone camera or a scanner recovers a value from a QR code, a
Data Matrix or an RFID tag. At this point nothing has happened except recovering a string of
characters. No product data has moved yet.

**The value is recognised as an identifier.** The recovered string is parsed, usually as a web
address carrying a structured identifier, so that the reading device knows where to send it next.

**The identifier is resolved.** A resolver, a service built for exactly this purpose, receives the
identifier and decides where to route the request. Because resolution is a lookup rather than
something printed on the product, the destination can change long after the carrier was
manufactured, which is precisely what allows a passport to be corrected or moved without reprinting
a single label.

**The request reaches the party serving the data.** That party checks who is asking, which is where
public and restricted access are separated, then retrieves the current version of the record for
that audience.

**The record is rendered.** A consumer sees a page. An authority's system may receive structured
data directly, with no page involved at all.

**The common misreading** is to describe this as "the QR code shows the passport". A carrier shows
nothing. It hands over an identifier, and everything a person actually sees is produced several
steps later, by a service that was not printed on the product and can be changed independently of
it. Confusing carrier and record is why teams believe a passport is finished once the printing is
done.

The consequence worth sitting with: a broken scan can fail at any one of five separate points, and
diagnosing it means knowing which one. A worn carrier is a printing problem. A resolver returning
the wrong address is a configuration problem. A page showing stale figures is a data problem three
steps further back. Treating all three as "the QR code is broken" sends the wrong team to fix it
every time.

A tieback framework describing the seven stages a passport passes through end to end: product
creation, supplier data collection, data validation, passport publication, market access,
lifecycle updates and end of life. The scan path in this lesson sits inside stage five, market
access, and depends entirely on stage four having been done properly.

**Use it when** you need to explain why a passport project cannot be judged finished the day a
resolver goes live, or when a stalled programme needs to be diagnosed by stage rather than blamed on
"the technology".

**Where it fails:** it describes the flow of an individual passport, not how to design an
organisation's data governance, and it does not tell you which attributes belong in which stage for
your product group. Do not use it as a project plan with equal effort per stage: stage two, supplier
data collection, is usually the longest by a wide margin.

#### [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work)

Read these three sections in order. The first gives you the seven stage flow in full, the second
fixes the vocabulary this lesson depends on, and the third walks the scan path from the carrier's
side.

#### Diagnosing a failed scan on the Aurelia S2

A customer reports that scanning the trimmer's housing carrier shows a page with the wrong battery
capacity. The support team's first instinct is to blame the QR code.

Working through the chain: the carrier reads correctly and returns the right identifier, so the
carrier and the resolver are not the fault. The resolver correctly routes to the consumer facing
service. The service, however, is serving a cached copy of the record from before a running
production change to the battery pack was reflected upstream. The fault sits at data validation and
publication, two steps before the carrier was ever printed, and reprinting the carrier would have
fixed nothing.

#### Map your own scan path

Take one product, real or planned. Write down, in order, what happens between a scan and a
displayed record for your organisation today, or your best guess if it does not exist yet. Name
who owns each of the five steps in this lesson. Where you cannot name an owner, you have found a
gap that will surface as an unexplained support ticket later rather than as a design decision now.

## Knowledge Check

## Takeaways

* A scan is a chain: carrier read, identifier recognition, resolution, access check, retrieval, rendering.
* The carrier delivers an identifier only. It never carries the record itself.
* Resolution is configuration, not print, which is what makes correction possible after manufacture.
* Diagnosing a failed scan means locating which step failed, not blaming the carrier by default.

**If you remember one thing:** the scan is a handoff between several owners, and knowing the chain
is what lets you find the right one when something breaks.

## Sources

[How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work),
sections The Digital Product Passport Data Flow, Product, Identifier and Passport Are Three
Different Things, and How QR Codes and Other Data Carriers Fit In.

## Related Docs

* [Lesson 2: Identifiers and Resolvers](/docs/academy/foundations/module-4/lesson-2)
* [Module 4 overview](/docs/academy/foundations/module-4)
* [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work)
* [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier)