Digital Product Passport jest zarządzanym interfejsem danych, a nie stroną pod kodem QR
Unijne rozporządzenie ESPR tworzy framework Digital Product Passport, ale dokładny zakres danych dla danej grupy produktów wynika z właściwych aktów delegowanych. To kluczowe dla architektury. Platforma DPP nie powinna na sztywno zakładać jednego uniwersalnego passport schema dla wszystkich produktów.
Art. 9–11 rozporządzenia (UE) 2024/1781 definiują podstawowe zasady: passport może być określony na poziomie modelu, batch lub item; jest połączony z trwałym unique identifier przez data carrier; dane mają być poprawne, kompletne i aktualne; dostęp może zależeć od aktora; a system ma opierać się na otwartych, interoperacyjnych i machine-readable rozwiązaniach. Problem programistyczny to więc identity, schema governance, access control i trwała dostępność.
1. Oddziel product identity od passport version
Product identifier odpowiada „co to jest?”. Passport version odpowiada „jakie dane były prawidłowe dla tego obiektu, w tej wersji schema i w tym momencie?”. Stabilne identity produktu, partii albo sztuki może mieć wiele wersji paszportu wraz z korektami, nowymi wymaganiami albo danymi lifecycle.
2. Model, batch i item muszą być jawne
| Poziom | Typowe zastosowanie | Implikacja |
|---|---|---|
| Model | Wspólna specyfikacja | Jedno identity dla wielu sztuk |
| Batch | Production run lub material evidence | Lineage i manufacturing context |
| Item | Indywidualny serialised object | Unikalna historia service/lifecycle |
Nie zakładaj globalnie wymaganego poziomu. Passport definition powinien zawierać level, a policy konkretnej grupy produktów określa, do jakiego identity prowadzi carrier.
3. Data carrier powinien być resolverem, nie bazą danych
QR, barcode lub inny dozwolony carrier powinien rozwiązywać persistent identifier. Nie musi zawierać całego passportu. Dzięki temu dane mogą się zmieniać, a fizyczne odniesienie pozostaje stabilne. Resolver powinien obsłużyć canonical endpoint, locale i actor-aware presentation bez zmiany identity.
4. Użyj schema packages zamiast jednego wielkiego JSON
Utrzymywalna platforma DPP potrzebuje registry schema packages: definicji pól, units, validation rules, vocabulary, required/optional, access class, provenance i reguły product group, która aktywowała dane pole. Każda passport version wskazuje wersję schema, względem której została zwalidowana.
Nowe wymagania tworzą nową wersję schema i kontrolowaną migrację albo enrichment, zamiast przepisywania historii.
5. Access rights należą do policy, nie do frontendu
ESPR przewiduje różny dostęp dla różnych aktorów. Consumer view, manufacturer workspace, repairer i authority mogą oglądać inne pola tego samego canonical passport record. Uprawnienia implementuj na warstwie API/domain. Samo ukrycie pola w UI nie jest access control.
6. Zapisuj, kto może tworzyć i aktualizować dane
DPP jest z natury multi-party. Dane mogą pochodzić od producenta, dostawcy, certifiera, serwisu lub innego uprawnionego podmiotu. Zachowuj provenance pola albo sekcji: source organization, actor, timestamp, source document/API i verification state. Dla danych wyliczanych zapisz metodę derivation.
7. Availability i backup są wymaganiami produktu
Architektura powinna działać dłużej niż marketingowa strona: stable identifiers, eksportowalne dane, recovery, provider exit, zmiana domeny i scenariusz zakończenia działalności. Passport nie powinien znikać wraz z końcem subskrypcji SaaS.
8. Interoperability wymaga kontrolowanej semantyki
„Open format” nie wystarcza, jeśli dwa systemy inaczej rozumieją to samo pole. Utrzymuj canonical units, code lists, vocabulary i mapping rules. API powinno wystawiać schema/version identifiers.
9. DPP i traceability to powiązane, ale różne bounded contexts
Traceability odpowiada, skąd pochodzi materiał i jak zmieniał się stan. DPP jest regulowanym interfejsem informacji dla product identity. Łącz je stabilnymi ID i evidence references zamiast jednym gigantycznym modelem.
Szerszy model znajdziesz w pillarze EUDR/DPP/traceability oraz Supply Passport OS. Wdrożenia: Compliance & Traceability Software Development.
Checklist architektury DPP
- Stable product/batch/item identity oddzielone od passport version.
- Konfigurowalny identity level.
- Data carrier rozwiązujący persistent identifier.
- Wersjonowany schema registry.
- Server-side actor access policy.
- Provenance i update authority.
- Long-lived availability, backup i provider exit.
- Open, machine-readable i semantically controlled integrations.