The passport carries the operator's identifier but not the name and contact its cited basis requires

[LKSNDRTMLKV]

Passport::operator_identifier carries a pinned citation in its own doc comment:

Annex III, point (k) is the data-content basis — "the name, contact details and unique operator identifier of the economic operator established in the Union responsible for carrying out the tasks set out in Article 4 of Regulation (EU) 2019/1020 [...]"

The field is:

pub operator_identifier: Option<String>,

Three things are named in the basis. One is modelled. The name and the contact details have nowhere to live.

Why the manufacturer field does not cover it

ManufacturerInfo carries a name and an address, but the Art. 4 responsible operator is not necessarily the manufacturer — that is the point of the provision. For a product made outside the Union, the responsible operator is typically the importer or an authorised representative, and the passport currently has no way to say who that is, only an opaque identifier for them.

FacilitySnapshot does not cover it either: a facility is where the product was made, not who is answerable for it.

Why it is not urgent, and why it should still be filed

The identifier alone is enough for registry registration, which is the only consumer today, so nothing is broken. The gap shows up the first time a reader of a passport — a market surveillance authority, or anyone following Art. 4 — has to resolve the identifier to a contactable party out of band. The passport is supposed to carry that.

The design question, which is the actual work

Whether to add name and contact alongside the existing identifier, or to introduce a structured economic-operator type that carries all three plus a role, is not obvious and should be settled before any code:

• A structured type with a role also answers "which of these operators is the responsible one" when there is more than one, which the single-field model cannot express at all. That is the shape the provision implies.
• It also has to interact with TransferChain::current_operator(), which is already the authoritative record of who is responsible now. operator_identifier is deliberately frozen at publish and documented as such. Any new field has to declare which of the two it is, or it will be read as the wrong one.
• Whatever lands is envelope, so it is additive-only, and it is signed content that a transfer cannot rewrite. Getting the frozen-versus-current distinction wrong here is not a bug that can be patched later.

Prerequisite

The citation above is marked confirmed against the verbatim OJ text, but it is a citation to a data-content requirement, not to a field shape. Before modelling, read Annex III point (k) and Art. 4 of 2019/1020 directly and establish what "contact details" is required to contain — a postal address, an email, a named person — because that determines whether this is one optional string or a struct.

[LKSNDRTMLKV]

OJ read done, against the primary texts rather than any summary. Sources now held locally: the original OJ L, 2024/1781, 28.6.2024 and the consolidation 02024R1781-20240628; CELEX 32019R1020; CELEX 32023R0988.

Five things, and three of them change the shape this issue proposed.

1. The citation in the code is truncated, and the elided part matters

Annex III(k), verbatim and identical in the original OJ and the consolidation:

(k) the name, contact details and unique operator identifier of the economic operator established in the Union responsible for carrying out the tasks set out in Article 4 of Regulation (EU) 2019/1020 or Article 15 of Regulation (EU) 2023/988, or similar tasks pursuant to other Union law applicable to the product;

operator_identifier's doc comment quotes this as "…Article 4 of Regulation (EU) 2019/1020 [...]". The bracket hides two further limbs, and they are the ones that decide when the provision bites at all.

2. Article 4 does not reach most of our product groups

Art. 4(5) of 2019/1020 limits the article to a closed list of instruments: Regulations 305/2011, 2016/425, 2016/426, and Directives 2000/14/EC, 2006/42/EC, 2009/48/EC, 2009/125/EC, 2011/65/EU, 2013/29/EU, 2013/53/EU, 2014/29/EU, 2014/30/EU, 2014/31/EU, 2014/32/EU, 2014/34/EU, 2014/35/EU, 2014/53/EU and 2014/68/EU.

Of the twelve product groups in the catalog, exactly two are on it: construction (305/2011) and toys (2009/48/EC). Battery, textile, detergent, furniture, mattress, tyre, steel, aluminium, electronics and unsold-goods are not, which is precisely why (k) carries a GPSR limb and a catch-all.

So the field cannot be named or documented as "the Art. 4 operator". It has to be basis-agnostic, or record which basis makes the person responsible. This is the largest thing the issue did not anticipate.

3. The GPSR cross-reference points at the wrong article

Art. 15 of 2023/988 is "Cooperation of economic operators with market surveillance authorities". The responsible-person provision is Art. 16, "Responsible person for products placed on the Union market". Checked in both the original OJ and the consolidation of ESPR — the "Article 15" is what is printed, not a consolidation artefact.

Nothing turns on it for modelling, because Art. 16(1) imports Art. 4(2) and 4(3) of 2019/1020 wholesale ("Article 4(2) and (3) of that Regulation shall apply to products covered by this Regulation"), so both limbs land on the same person and the same tasks. Cite it as printed, with the note.

4. "Contact details" is never a free string — four provisions converge

Provision	Whose	Required
ESPR Art. 27(6)	manufacturer	name, registered trade name or registered trade mark, postal address, electronic means of communication — "on the public part of the digital product passport"; the address "shall indicate a single point"
ESPR Art. 29(3)	importer	the same four — also "on the public part of the digital product passport"
Art. 4(4) 2019/1020	Art. 4 operator	name, registered trade name or trade mark, contact details including the postal address
Art. 16(3) 2023/988	responsible person	name, registered trade name or trade mark, contact details including the postal and electronic address

So the answer to the issue's open question — one optional string or a struct — is a struct, with a floor of: name, registered trade name or trade mark, postal address, electronic address.

Two side-findings from the same read, both about ManufacturerInfo rather than this field:

• Art. 27(6)(a) is an explicit obligation to carry the manufacturer's postal address and electronic means of communication on the public part of the DPP. ManufacturerInfo has name and address (and country as of feat(domain)!: give the manufacturer a country #239) but no electronic contact. did_web_url is not that: a DID document is not an electronic means through which a person can be contacted.
• Annex III(g) attaches "the information referred to in Article 27(7)" to the manufacturer, and 27(7) is digital instructions, not contact details. The contact obligation is 27(6). Worth not conflating the two.

5. Frozen vs current is already settled — by Art. 9(1) and by our own code

ESPR Art. 9(1), final sentence: "The data in the digital product passport shall be accurate, complete and up to date."

So (k) wants the current responsible operator, not a publication-time snapshot. And the code already agrees: operator_identifier's doc comment states it is the publisher frozen at publish, explicitly not who is responsible now, with TransferChain::current_operator() named as the authoritative record.

Which reframes the gap. It is not "the model carries only the identifier":

• the identifier on the passport is a different thing — the publisher, frozen, and correctly documented as such;
• the name and role live on ResponsibleOperator inside TransferChain, which is stored in its own table (odal.passport_transfer), is not a field on Passport, and never reaches the passport document or the public view;
• the contact details are modelled nowhere.

So none of Annex III(k)'s three elements is actually in the DPP today.

6. The role is a closed set of four, and we are missing one

Art. 4(2) defines the responsible operator as any of: (a) a manufacturer established in the Union; (b) an importer, where the manufacturer is not established in the Union; (c) an authorised representative with a written mandate; (d) a fulfilment service provider established in the Union, where no other is.

OperatorRole has nine variants and no FulfilmentServiceProvider. A product whose only EU-established operator is a fulfilment service provider cannot state its responsible operator at all. Distributor, meanwhile, is in our enum and is not one of the four — the existing enum is a supply-chain taxonomy that overlaps this set without coinciding with it.

Recommended shape

Follow the FacilitySnapshot precedent, which exists for exactly this reason and says so: "copied by value at create time. Self-contained so the signed passport stays a complete record independent of the operator's mutable registry."

1. Add contact details to ResponsibleOperator — postal address and electronic address, plus the registered trade name/trade mark the four provisions all name. One type, so the chain and the passport cannot disagree.
2. Add FulfilmentServiceProvider to OperatorRole, with the Art. 4(2)(d) condition in its doc comment.
3. Add a responsible_operator envelope field on Passport, a snapshot of TransferChain::current_operator() taken at publish — additive, Option, signed content, never rewritten in place. Art. 9(1)'s "up to date" is then satisfied by the amend route (#250) issuing a successor when responsibility moves, which is the mechanism the chain and the signature already imply.
4. Separately, and not in this issue: ManufacturerInfo needs an electronic contact to satisfy Art. 27(6)(a).

Open sub-question worth settling before code, and the only one left: whether the snapshot records which legal basis makes the person responsible (2019/1020 Art. 4 / 2023/988 Art. 16 / other Union law), given §2 above. Recording it is honest and cheap; inferring it from the product group is derivable for the two groups where Art. 4 applies and a guess everywhere else.