> 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: Working Without the Field List

> Academy Foundations Module 5 Lesson 4: what work a missing delegated act can invalidate, and what work is safe to do before the field list exists.

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

## Orientation

By now you can say, precisely, why a working plan entry is not a deadline and why a framework being
in force is not the same as a duty on your product. The question this leaves standing is practical:
if the field list for the Aurelia S2 has not been written yet, what are you supposed to do with the
next two years. The honest answer is not "nothing" and it is not "guess the schema." It is a specific
and fairly short list of work that a delegated act cannot invalidate, alongside a list of work it can
undo completely. This lesson gives you both lists, so idle time stops being the default.

In force describes the legal existence of the instrument itself, independent of any product. A
requirement only becomes applicable to your product once a delegated act covering it has been
adopted, entered into force, and passed its date of application. Being on a working plan sits
between those two states and promises neither.

## Learning Objectives

## What a Delegated Act Can Undo, and What It Cannot

Some preparation work depends directly on the content of a delegated act that has not been written.
Do that work early and a published act can force you to redo most of it. Other preparation work
depends on facts about your own organisation and product that no delegated act changes. Do that work
early and it survives the act intact, whatever the act eventually says.

**Vulnerable to being redone.** Final schema mapping, where a specific attribute is bound to a
specific field name and data type, is a guess until the act names the fields. Carrier artwork, sized
and formatted around a particular data payload, is a guess until the payload size and structure are
known. Attribute-level tooling built to validate against a schema is a guess until the schema exists.
Vendor selection made because a vendor claims support for "the coming requirements" is a guess dressed
as a decision, since nobody can support requirements that have not been published. All four share a
trait: they commit to a specific shape, and the act is the only thing that can supply that shape.

**Not vulnerable, and worth doing now.** Data ownership, deciding which function in your organisation
is accountable for a given attribute being correct, does not depend on what the attribute list turns
out to be. Identifier discipline, resolving the three conflicting internal identifiers the S2 already
carries down to one, does not depend on any act either; it is a problem you have regardless of what
gets published. Supplier relationships, specifically asking the contract manufacturer for composition
data it has never been asked to produce, do not wait on an act, because the manufacturer has to build
internal capability to answer at all, and that takes time independent of any deadline. Scope tracking,
knowing which of your product families sit on a current working plan and which do not, is monitoring
work, not implementation work, and it stays useful under any version of the act. Access-model design,
working out which audiences should see which categories of information, follows from the kind of
product you sell, not from a specific field list.

**The common misreading** is treating "we cannot start until the field list is published" as a single
true statement covering all work, when it is only true for the first group. Teams that adopt it as a
blanket rule spend the waiting period idle and then discover, once the act lands, that they also have
to spend the waiting period's worth of time doing the ownership and identifier work they could have
finished already. The opposite error, building final schema mappings and carrier artwork speculatively
so as not to look idle, produces the same lost time in the other direction: work done that has to be
redone once real fields exist.

#### [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory)

Read both sections. They set out, for the regime generally, the same split this lesson applies to
the Aurelia S2.

#### Sorting the S2's open tasks

Two tasks on the S2 backlog: "resolve the three conflicting product identifiers into one canonical
ID" and "finalise the passport data schema and order carrier artwork." The first belongs in the
safe category: no future delegated act changes which identifier the organisation should treat as
canonical, and leaving it unresolved only compounds confusion later. The second belongs in the
vulnerable category: ordering artwork sized for a payload nobody has specified yet is a bet, and
if the act specifies something different, the artwork run is wasted. The right move is to do the
first now and hold the second until an act exists, while still auditing where the underlying
attribute data currently sits, since that audit is safe work too.

#### Sort your own backlog into the two categories

List five open tasks from your DPP backlog. Mark each as either dependent on delegated act content
(vulnerable) or dependent only on facts about your organisation and product (safe). Move anything
marked safe to the front of the queue.

## Knowledge Check

## Takeaways

* Work that commits to a specific field, schema or payload shape is vulnerable to being redone once an act is published.
* Work that depends only on facts about your own organisation, such as ownership, identifiers and supplier relationships, is not vulnerable and should not wait.
* Scope tracking is monitoring, not implementation, and it stays useful under any version of a future act.
* Treating the field list as a blanket reason to do nothing wastes the only time you have before it arrives.

**If you remember one thing:** ask whether a task depends on the act's content or on your own organisation's facts, and only wait on the first kind.

## Sources

[When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory),
sections What Depends on Delegated Acts and What You Can Do Now.

## Related Docs

* [Module 5 assessment](/docs/academy/foundations/module-5/assessment)
* [Lesson 3: In Force Is Not the Same as Applicable to You](/docs/academy/foundations/module-5/lesson-3)
* [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory)
* [tieback Frameworks](/docs/knowledge-base/frameworks/overview)