> 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 3: Life After the Sale

> Academy Foundations Module 4 Lesson 3: why a passport has to keep working for years after the sale, who adds to it, and what that means for how it is designed.

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

## Orientation

Most product data projects finish when the product ships. A passport does the opposite: the sale is
the point at which its hardest obligations begin. A record that renders perfectly on launch day and
cannot be reached, updated or trusted five years later has not delivered what it was built for. This
lesson is about designing for that stretch of time rather than for the launch event.

The identifier points at the product and is meant to stay stable for as long as the product
exists. The resolver is the service that decides what a request for that identifier receives, and
it can be replaced without touching the identifier itself.

## Learning Objectives

## Compliance That Does Not End at the Sale

Traditional product compliance is built around a moment: a declaration is signed, a certificate is
issued, a file is archived, and the obligation is treated as discharged. A passport does not work
that way. It is a live record that has to remain reachable and accurate for a defined period, and
during that period new facts arrive that the record has to absorb: a repair, a replaced battery, a
software update, a change of owner, an end-of-life collection. The obligation is not "publish once
correctly" but "keep this true for as long as it is required to be true", which is a different kind
of commitment entirely.

That shift changes who touches the record after launch. The manufacturer is no longer the only
writer. A repairer may add what was replaced. A recycler may add how the product was processed at
end of life. Which actors may add which fields is decided per product group, but the pattern holds
generally: a passport designed as a one-way publication, readable but never extended, cannot support
the repair, resale and recycling outcomes it exists to enable.

**The common misreading** is to treat passport delivery as a project with an end date, the way a
website launch or a product recall notice has an end date. Publication is not the finish line; it is
the point at which the record's operating life begins, and everything from hosting continuity to
who owns each field for the next decade has to already be decided by then, not worked out
afterwards. An organisation that discontinues a product and quietly retires its web estate has, if
the passport's reachability depended on that estate, retired the passport along with it.

There is a contrast worth drawing precisely because it is tempting to skip. A product recall notice
is complete once it is issued and acted on: a fixed statement about a fixed moment. A passport is
closer to a patient record than a recall notice: it accumulates entries over a long life, each one
dated and attributable, and its value comes from the accumulation, not from the first entry alone.
Confusing the two leads teams to budget for a launch and starve the years afterwards.

A tieback framework describing the shift from document based, point in time compliance to
continuous, data based product accountability. It frames why a passport behaves less like a
certificate and more like a record that is kept true over time.

**Use it when** you are explaining to a compliance function used to point in time sign-off why
budget and ownership have to extend well past the launch date.

**Where it fails:** it explains the shift in principle, not which specific actors may write to which
field for your product group, and it will not tell you how long a given record must be retained. Do
not use it to draft a retention schedule; treat it as the reason such a schedule is needed at all.

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

Read the lifecycle updates and end of life sections together, then the section on how information
changes over time. These describe exactly what has to be designed for before publication, not
after.

#### The Aurelia S2, three years on

The S2's battery pack is replaced under warranty in year two by an authorised repairer, and the
original textile strap is later replaced by the owner with a third-party equivalent. If the
passport was built as a static page generated at launch, neither event is reflected anywhere, and
a recycler processing the unit in year six sees a battery pack that no longer matches the record.

If the passport was designed with lifecycle updates in mind, the repairer's replacement is logged
against the identifier, dated and attributed to the repairer, and the record a recycler sees in year
six is the current state of the product rather than the state it left the factory in. The
difference is not a technical feature added late. It is a decision made before launch about who may
write to the record and how those entries are dated and kept apart from the original data.

#### Name what changes after sale for your own product

List three events that could plausibly happen to your product after it is sold: a repair, an
ownership change, a software update, a component swap, a recycling event. For each, name who would
know about it and whether your organisation currently has any way of finding out. Where the answer
is "we would never know", you have identified a gap in the record's ability to stay true, not
merely a data entry backlog.

## Knowledge Check

## Takeaways

* A passport's obligation is to stay reachable and accurate after the sale, not just correct at launch.
* Publication is the start of the record's operating life, not the end of the project.
* Actors other than the manufacturer may be permitted to add lifecycle information, depending on the product group.
* Retiring the platform a passport depended on can retire its reachability, unless that was designed for in advance.

**If you remember one thing:** budget and ownership for a passport have to extend for years past
launch, because that is where its actual obligations sit.

## Sources

[How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work),
sections Stage 6: Lifecycle Updates, Stage 7: End of Life, and How Information Changes Through the
Lifecycle.

## Related Docs

* [Lesson 4: Why a Published Record Should Not Change](/docs/academy/foundations/module-4/lesson-4)
* [Lesson 2: Identifiers and Resolvers](/docs/academy/foundations/module-4/lesson-2)
* [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work)
* [How Will Digital Product Passports Change Product Compliance?](/docs/knowledge-base/standards-and-technology/how-will-digital-product-passports-change-product-compliance)