Document versioning w DPP — dlaczego paszport musi wskazywać konkretną wersję dowodu?

Status funkcji: wersjonowane repozytorium Evidence, supersede/revoke i automatyczny impact preview są kierunkiem rozwoju DPP Compliance. Nie są obecnie oferowane jako aktywna funkcja samoobsługowa. Opisany model to rekomendacja architektoniczna; dokładne obowiązki dokumentacyjne zależą od właściwych przepisów produktowych.

Digital Product Passport powinien pozwalać odtworzyć nie tylko wartość pola, ale również źródło, które uzasadniało ją w chwili publikacji. Referencja do „najnowszej deklaracji” nie spełnia tego celu: dziś otworzy v5, choć przy tworzeniu paszportu zespół korzystał z v3.

Podstawowa reguła wersjonowania dowodów brzmi: dokument logiczny ma stałą tożsamość, a ocena i publikacja wskazują jego konkretną rewizję.

Document i document version to dwa obiekty

document_id opisuje dokument, np. deklarację materiałową konkretnego dostawcy. version_id identyfikuje dokładną rewizję treści, metadanych i zakresu. Adres pobrania jest sposobem dostępu do pliku, a nie tożsamością dowodu.

document_id: E-184
  v3 / version_id: EV-184-003 — superseded
  v4 / version_id: EV-184-004 — superseded
  v5 / version_id: EV-184-005 — current

Historyczny DPP v7 → EV-184-003
Nowa ocena produktu → EV-184-005

Przy późniejszym odczycie DPP v7 system nie rozwiązuje tego odwołania do v5. Musi zachować zarówno v3, jak i związek tej rewizji z opublikowanym snapshotem. Bieżąca informacja o revoke może być pokazana osobno, bez zmiany historycznej treści.

Minimalny model rewizji dowodu

Plik i merytoryczne metadane rewizji powinny być niezmienne. Jeżeli zmienia się scope lub data wykorzystana w ocenie, powstaje nowa rewizja, nawet gdy PDF ma ten sam hash. Status lifecycle zmienia się przez zdarzenie audytowe. Current oznacza wybraną rewizję, a nie automatyczne potwierdzenie ważności dowodu.

Relacja do produktu to nie relacja do historycznej oceny

Produkt może być powiązany z dokumentem logicznym jako źródłem przyszłych ocen. Wynik Data Mappera, decyzja review oraz published DPP muszą jednak utrwalić wybrany version_id, jego scope i wersję profilu wymagań.

Produkt → dokument logiczny (kandydat do kolejnej oceny)
Ocena → konkretna rewizja dowodu + profil wymagań
Opublikowany DPP → snapshot + konkretne referencje dowodowe

Takie rozdzielenie chroni również przed przypadkowym „naprawieniem” historii. Nowy dokument może poprawić bieżącą ocenę; nie powinien retroaktywnie uzasadniać decyzji, która powstała wcześniej. Nie wszystkie dowody są publiczne — referencja wewnętrzna nie oznacza uprawnienia do ujawnienia pliku przez QR.

Supersede i revoke mają inny wpływ

Supersede tworzy następcę. Poprzednia rewizja pozostaje zapisem użytym w przeszłości, a nowa trafia do przyszłych ocen w swoim zakresie. Aktywacja wymaga atomowej zmiany i kontroli wersji, aby dwie osoby nie ustanowiły różnych „current” jednocześnie.

Revoke wycofuje konkretną rewizję z dalszego użycia. Nie przełącza automatycznie na poprzednią wersję i nie usuwa zależności. System powinien wskazać aktywne oceny oraz publikacje korzystające z zakwestionowanego źródła i skierować je do oceny wpływu. Wcześniejsze review jest faktem historycznym, ale samo nie rozstrzyga aktualnej ważności dowodu.

Archiwizacja dokumentu jest jeszcze inną operacją: porządkuje listę roboczą, nie zmienia treści ani statusu ważności rewizji.

Impact preview przed aktywacją lub wycofaniem

Wersjonowanie plików ma sens dopiero wtedy, gdy można znaleźć miejsca użycia. Podgląd powinien pokazać produkty, komponenty, otwarte review, aktualne oceny, drafty i historyczne wersje DPP. Każda pozycja wskazuje dokładne powiązanie, a wynik odróżnia potwierdzony wpływ, możliwy wpływ i brak wystarczających danych.

Przykład:

E-184 v3 → nowa rewizja v4
428 produktów powiązanych
17 otwartych review
63 opublikowane wersje DPP korzystające z v3
126 produktów: zmiana scope — wymagana ponowna ocena

Zatwierdzony plan powinien utrwalać identyfikatory i oczekiwane rewizje. Kolejka re-evaluation wykonuje nowe oceny, nie przepisuje starych. Retry nie może tworzyć wielokrotnie tych samych zadań ani publikacji. Korekta publicznego DPP jest odrębnym procesem.

Dlaczego zwykły link „latest.pdf” nie wystarcza?

Nadpisanie obiektu w storage zmienia treść pod tym samym adresem. Czasowy signed URL z kolei wygasa. Dlatego trwałe referencje powinny opierać się na version_id, nie na jednej ścieżce nadpisywanego pliku lub tokenie pobrania.

Każda rewizja potrzebuje własnego klucza obiektu, sumy kontrolnej i kontroli dostępu organizacji. Eksport historii powinien zawierać pliki, metadane, powiązania i manifest checksum, aby dało się odtworzyć dowody poza systemem. Zobacz zasady ciągłości i eksportu DPP.

Usuwanie i retencja muszą znać historię użycia

Bezpieczna reguła operacyjna blokuje hard delete rewizji zaakceptowanej lub użytej w ocenie, supplier workflow albo publikacji. Powinna obowiązywać w UI, API i procesie czyszczenia storage. Nieużywany draft można usunąć, jeżeli nie ma powiązań ani ograniczenia retencji.

Nie jest to nakaz bezterminowego przechowywania każdego pliku. Okresy retencji, legal hold i obowiązki ochrony danych wymagają własnej polityki oraz kontrolowanych operacji. Zmiana planu abonamentowego nie powinna usuwać historii klienta.

ESPR wymaga aktualnych danych DPP i określa obowiązki dokumentacyjne dla produktów objętych właściwymi aktami. Model document_id/version_id, nazwy statusów i zasada snapshotu opisane tutaj są sposobem zapewnienia traceability, a nie literalnie narzuconym schematem bazy danych.

Jak sprawdzić narzędzie przed zakupem?

Wgraj dokument v1, przypisz go do dwóch produktów i przygotuj paszport. Następnie dodaj v2 z innym zakresem. Sprawdź, czy nadal można pobrać dokładną v1, znaleźć jej historyczne użycia i ocenić, które produkty mogą korzystać z v2. Potem przetestuj revoke: czy zachowuje historię i blokuje nowe użycie zakwestionowanej rewizji?

To lepszy test niż samo pytanie „czy jest wersjonowanie plików?”. Praktyczną procedurę aktualizacji certyfikatu i deklaracji opisujemy osobno. Jeśli budujesz pilotaż, ustal z nami model dowodów i źródła danych.