> 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: Reading Scope Without Guessing

> Academy Foundations Module 2 Lesson 3: the Product Category Rollout Model, how to tell an adopted obligation from a stated priority, and which products are likely to fall into early scope.

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

## Orientation

Once you know your role, the next question is timing: is this product group already covered, about
to be, or not yet on anyone's list. This is where most confident answers turn out to be wrong,
because the language used to describe scope, "priority", "working plan", "expected", "confirmed",
gets flattened in conversation until it all sounds like the same thing. It is not the same thing,
and the gap between "named as a priority" and "legally required" is exactly where committed budgets
get burned on the wrong timeline.

This lesson is about reading scope claims the way you would read a contract: by asking what evidence
backs the sentence.

## Learning Objectives

## Coverage Has a Status, Not a Vibe

Coverage of a product group by a passport obligation exists only where a legal act in force names
that group and imposes the requirement. Being within the general reach of the framework legislation
is not coverage. Being named as a priority for future rule making is not coverage. Being the subject
of a consultation or a preparatory study is not coverage. Only an adopted, published act that names
the product group is coverage, and it has a date attached to it.

That distinction resolves into a small number of positions a product group can occupy, moving from
firmest to loosest: an adopted act already applies, or will apply on a fixed date; the group is
named as a priority for rule making, with work under way but no obligation yet; the group is
signalled in Commission analysis or discussion without a firm commitment to regulate it on any
timetable; or the group is simply within the framework's general reach, with nothing scheduled and
nothing that should be assumed.

The reason this staged reading matters in practice, and not just as a taxonomy, is that the correct
organisational response differs sharply between positions. An adopted obligation with a fixed date
justifies a funded programme with a deadline. A named priority justifies engagement in consultation
and early data preparation, but not a compliance deadline, because no delegated act yet exists to
comply with. A category with no legal act, only visibility, justifies nothing beyond ordinary data
hygiene: assigning it dates or budget lines produces a roadmap that ages badly and loses credibility
the moment the projected date passes.

**The common misreading** is to treat "named as a priority" as functionally equivalent to
"required", on the reasoning that regulation is clearly coming so acting as if it has already
arrived is prudent. It is not equivalent, and the two errors it produces run in opposite directions:
treating a priority group as already covered wastes money building to a specification that has not
been fixed and may change; treating it as nothing at all wastes the lead time that supplier data
collection genuinely needs. The correct response to a priority group is neither of those; it is
preparing the foundations, identifiers, data ownership, supplier clauses, that do not depend on
knowing the eventual field list.

A tieback framework that places a product category on a four stage maturity scale, from adopted
law through highest priority, signalled but undetermined, to long term expansion within the
framework's reach but unplanned, so an organisation can judge how soon an obligation is likely to
reach it.

**Use it when** someone claims a product category "requires a passport" or "will require one by" a
given date, and you need to establish what evidence actually supports that claim.

**Where it fails:** it describes a category's position, not a guarantee of onward movement. A
category can sit at an early stage for years, or never move at all, and being named in a working
plan does not guarantee a delegated act follows. Do not read the model as a countdown.

#### [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport)

Read the Definition and the rollout model first, then the two sections that apply the model to
real categories. Note, for each category mentioned, which stage it occupies and what evidence is
given for that stage.

#### Placing the Aurelia S2's components on the scale

The trimmer's removable lithium-ion battery pack sits in the category with the firmest position
of any passport related product today: an adopted, dated obligation exists for it, distinct from
the framework that will eventually cover the trimmer itself. The moulded polymer housing and the
textile shoulder strap sit differently again. Textiles have been named as an early priority for
rule making, so the strap warrants active preparation, though not a compliance date yet. The
polymer housing corresponds to no adopted or clearly prioritised category at the time of writing,
so it currently sits in the loosest position: within reach in principle, with nothing scheduled.

One product, three components, three different scope positions. Treating "the S2" as a single scope
answer would be wrong for at least two of its three regulated materials.

#### Score your own product's components

List the main materials or components in one of your own products. For each, decide which of the
four stage positions it currently occupies, and write down the one piece of evidence that would
move it up a stage, an adopted act, a working plan entry, or nothing yet published. If you cannot
name that evidence for a component, you have been guessing rather than reading, and that is the
gap to close first.

## Knowledge Check

## Takeaways

* Coverage requires an adopted, published act naming the product group, nothing looser.
* A named priority signals direction and sequencing, not an obligation or a date.
* The correct response differs by stage: comply to a fixed date, prepare foundations for a priority,
  monitor a signalled category, and do nothing beyond hygiene for the rest.
* Different components of one product can sit at different scope stages at the same time.

**If you remember one thing:** ask for the evidence behind any scope claim, an adopted act, a
working plan entry, or nothing, before you plan around it.

## Sources

This lesson draws on
[Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport),
sections Definition, The Product Category Rollout Model, Products Already Covered and Products
Expected Next, which is the canonical description of TBF-007.

## Related Docs

* [Lesson 4: The Data You Do Not Hold](/docs/academy/foundations/module-2/lesson-4)
* [Lesson 2: Who Carries Which Duty](/docs/academy/foundations/module-2/lesson-2)
* [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport)
* [tieback Frameworks](/docs/knowledge-base/frameworks/overview)