No position on customer personal data in a passport — ESPR Art. 10(1)(e) is unconditional

[LKSNDRTMLKV]

Regulation (EU) 2024/1781 Art. 10(1)(e) is an essential requirement of a digital product passport. This workspace has no position on it, anywhere.

The requirement

Verbatim:

"(e) personal data relating to customers shall not be stored in the digital product passport without their explicit consent in compliance with Article 6 of Regulation (EU) 2016/679;"

Read the list it sits in. Points (b), (f) and (g) of Art. 10(1) each defer to "the applicable delegated act adopted pursuant to Article 4". Point (e) does not. It is unconditional — a flat prohibition with one named exception, and that exception has a legal form (explicit GDPR Art. 6 consent), not a discretionary one.

Current state

Searched dpp-core and dpp-engine:

• 2016/679 — zero occurrences
• GDPR — zero occurrences
• personal data — one occurrence, in a dpp-core architecture document, as prose rather than a rule

No field is classified as personal data. No validation rejects it. No doc comment says it must not be stored. There is no stated position either way.

Why the absence is not neutral

The passport model carries free-text and semi-structured fields whose lawful content shades into personal data:

• Batteries Annex XIII point 4(d) requires "information and data resulting from its use, including the number of charging and discharging cycles and negative events, such as accidents, as well as periodically recorded information on the operating environmental conditions". Accidents involve people. That field is dated 18 February 2027.
• safetyMeasures, wasteBatteryInformation, testReportResults, sparePartsContacts and usageHistory.operatingConditions are all operator-authored strings.
• CIR (EU) 2026/1778 Art. 18 shows the Commission storing passport numbers and national identity card numbers for registry users. Different population, same class of data moving near the same pipes.

And storage is the irreversible half. A disclosure mistake can be corrected by re-serving; a storage mistake has already happened by the time anyone notices. That asymmetry is presumably why point (e) prohibits storing rather than publishing — and it is why the existing Disclosure lattice, which is a serving-time filter, does not answer this.

What this is asking for

A decision, not a patch. At least three shapes are defensible and they cost very different amounts:

1. A stated position, enforced by nothing. Document that free-text fields must not carry customer personal data, that the operator is the controller of what it submits (CIR 2026/1778 Art. 19(5) says so in terms), and that the platform neither inspects nor consents on their behalf. Cheapest, honest, and probably correct for a product with no users.
2. A lint. Flag free-text fields at publish time on obvious personal-data shapes. Catches accidents; produces false positives; needs a bypass, and the bypass is where the consent question reappears.
3. A modelled consent record. A passport-level attestation that explicit Art. 6 consent exists for named fields. Most complete, and by far the most expensive — and it makes the platform a participant in a consent chain it currently has no part in.

My reading is that (1) is right today and (2) becomes right when the first operator touches a battery passport's usage history — but the point of filing this is that the choice should be made deliberately rather than defaulted into.

Timing, stated honestly

Art. 10(1)(e) is an ESPR essential requirement, and no ESPR delegated act exists, so no product group is bound by it today. This is filed anyway because:

• the risk it addresses is live for the battery passport in seventeen months, through a field the annex expressly requires;
• the cost of answering it now is a paragraph, and the cost of answering it after data has been stored is not;
• and an audit that only records obligations already in force would never have surfaced it.

[LKSNDRTMLKV]

Decision: option 3 — a modelled consent record. Landing in 0.22.0.

Taken 2026-09-17, deliberately and against this issue's own recommendation,
which was (1) now and (2) later.

Recording what that choice accepts, because the issue named it plainly and the
reasoning should survive the decision:

• It is the most expensive of the three.
• It makes this workspace a participant in a consent chain it currently has no
  part in. CIR (EU) 2026/1778 Art. 19(5) puts the operator in the controller
  seat; modelling the attestation does not move that seat, but it does mean the
  passport now carries a claim about consent, and a claim in a passport is
  something a reader may rely on.

Why it is still the right call here: the alternative shapes both defer the same
question rather than answer it. Option 1 states a position nothing enforces, and
option 2's lint needs a bypass — and the bypass is exactly where the consent
question reappears, only later and with data already stored. Storage is the
irreversible half; the cheap options are cheap because they leave the
irreversible half unaddressed.

Timing is the reason it is 0.22.0 and not 0.21.0. Battery Annex XIII point 4(d)
— the usage-history field that expressly requires "negative events, such as
accidents" — applies from 18 February 2027. That is the deadline this has to
beat, not next week's cut, and designing a consent attestation under release
pressure is how a shape gets fixed before it is understood.

What 0.22.0 owes

• The attestation's shape: passport-level, naming the fields it covers, and what
  it asserts (that Art. 6 consent exists) versus what it cannot assert (that the
  consent is valid — that is the controller's).
• Where it lives. It is not a Disclosure class: the lattice is a serving-time
  filter and point (e) prohibits storing. A serving-time answer to a
  storage-time prohibition is the category error this issue already identified.
• Whether absence of the record makes a field refusable, and for which fields.
  A prohibition nothing can refuse is option 1 wearing option 3's clothes.
• Whether it is signed, and by whom.

Not in scope for it

Inspecting field contents for personal data. That is option 2, and taking option
3 does not smuggle it in — the platform still does not read what an operator
writes into a free-text field.