Lesson 4: Working Without the Field List
Lesson 4: Working Without the Field List
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.
From Lesson 3: what is the difference between a regulation being in force and a requirement being applicable to your product?
Show the answer
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
By the end of this lesson you should be able to:
- M5-O4Decide what work is safe to do while the field list is still unwritten.
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.
Read both sections. They set out, for the regime generally, the same split this lesson applies to the Aurelia S2.
Read: When Will Digital Product Passports Become Mandatory? (15 min read)
Sections that carry this lesson:
- What Depends on Delegated Acts
- What You Can Do Now
The article is the source of record. Where this lesson and the article differ, the article is correct.
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.
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
4 questions. Feedback is immediate, nothing is graded, and this does not gate your progress.
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?, sections What Depends on Delegated Acts and What You Can Do Now.
Module 5 · Lesson 4 of 4
Checking this device for saved progress.
Previous: In Force Is Not the Same as Applicable to You
Progress is saved on this device.