> 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 4: From Carrier to Record, and What Is Still Undecided

> Academy Foundations Module 1 Lesson 4: how a scan resolves into a passport record, and how to separate what is settled in law from what is still awaiting delegated acts.

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

## Orientation

Two things are left before the module assessment. The first is mechanical: what actually happens
between a scan and a rendered passport, because that path is where identifiers, access control and
longevity all become concrete. The second is a discipline: separating what is decided from what is
not.

The second matters more. Almost every stalled programme has the same root cause, which is a team
waiting for total certainty before doing work that certainty would not change.

The information layer. Governed, well sourced data can be mapped onto whichever field list a
delegated act eventually specifies.

## Learning Objectives

## From Carrier to Record

The chain is short and each link fails differently.

1. **A carrier is scanned.** It yields a string. If the string is a marketing URL, you have bound
   your product identity to a web estate that will be reorganised.
2. **The string resolves to an identifier.** This is the durable part, and it must outlive the
   product, the campaign and quite possibly the platform.
3. **The service determines who is asking.** Public, or an authorised operator, or an authority.
   This is where the access control property becomes real rather than aspirational.
4. **The record is assembled and served**, both as a human readable view and as structured data.
5. **The record persists** and remains reachable for the period the regime requires, which will
   generally outlast the product's commercial life.

Two consequences follow that are easy to miss. Reachability is an ongoing obligation, not a launch
task, so someone must own the resolver years after the launch team is disbanded. And because the
access decision sits at step three, a design that renders one page for everybody cannot be retrofitted
cheaply; the tiering has to exist in the data model.

## What Is Settled and What Is Not

The framework regulation is in force. The definition, the obligations, the concept of the data
carrier and unique identifier, the access tiering, and the responsibility of the operator placing
the product on the market are all fixed.

What is not fixed for most product groups is the specific field list, the exact timing, and the
detailed technical specification. Those arrive in delegated acts, per product group.

The correct behaviour under that split is narrow and worth memorising. Work that does not depend on
the field list should proceed now: identifying which of your products are in scope, assigning
attribute ownership, auditing where data actually lives, and fixing the quality problems you will
otherwise inherit. Work that does depend on the field list, such as final schema mapping and
carrier artwork, should wait, because doing it early means doing it twice.

**The failure mode** is inverting this: building carriers now because they are buildable, and
deferring the ownership work because there is nothing yet to point it at.

#### [What is a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-is-a-digital-product-passport)

Read these three sections. The middle one is the authoritative statement of the settled and
unsettled split; treat any other source that gives you a definitive field list for a product group
with suspicion until you have checked it against a published act.

#### What the Aurelia S2 team should do this quarter

**Deferred, correctly:** final attribute schema, carrier artwork and print tooling, the consumer
facing layout, and any supplier contract clause that enumerates specific fields.

**Proceeding now:** determine which regimes touch the trimmer, the battery pack and the strap.
Assign an owner to every attribute the team can already name. Audit where composition, repair and
conformity data lives today, and record honestly that a third of it sits with a contract
manufacturer who has never been asked. Fix the identifier problem, because the S2 currently has
three different codes in three systems and none of them is durable.

None of that work is invalidated by whatever the delegated act says. All of it is on the critical
path. And the identifier problem in particular gets more expensive every quarter it is left.

#### Sort your own backlog into now and later

List eight things your organisation believes it needs to do for passports. Sort each into
"depends on the field list" or "does not".

Then check the balance of effort. If most of your planned spend is in the first column, you are
scheduled to build things twice. If your second column is empty, you have not yet looked at
ownership.

## Knowledge Check

## Takeaways

* Scan yields a string, the string resolves to a durable identifier, the service decides who is asking, then the record is assembled and served.
* Reachability is an ongoing obligation with an owner, not a launch task.
* Access tiering must exist in the data model, because it is applied before rendering.
* The framework obligations are settled; field lists, timing and technical detail arrive per product group.
* Do the work uncertainty does not change: scope, ownership, data audit, identifiers.

**If you remember one thing:** you cannot know the fields yet, and you never needed to know them to
start.

## Sources

[What is a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-is-a-digital-product-passport),
sections How a Digital Product Passport Works, What Is Confirmed and What Is Not, and What to Do
Now.

## Related Docs

* [Module 1 Assessment](/docs/academy/foundations/module-1/assessment)
* [Lesson 3: The Four Layers](/docs/academy/foundations/module-1/lesson-3)
* [What is a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-is-a-digital-product-passport)
* [Glossary: Product Identifier](/docs/knowledge-base/glossary/product-identifier)