Perché abbiamo costruito Junction attorno a un registro vivo

Ogni prodotto fa una scommessa su come si comporterà il suo mercato. La nostra è che il passaporto digitale di prodotto (DPP) verrà trattato come un documento da consegnare, e che si rivelerà il modo costoso di farlo.

Vale la pena spiegare il ragionamento, perché determina cosa il prodotto fa e cosa non fa.

La scommessa

Sotto ci sono due fatti.

L'operatore economico deve mantenere l'accuratezza dei dati per tutto il ciclo di vita del prodotto. Quel dovere non finisce al lancio; dura finché il prodotto esiste sul mercato, e il passaporto deve servire riparatori e riciclatori molto dopo la vendita.

E i prodotti cambiano di continuo. I fornitori vengono sostituiti, i materiali riformulati, gli stabilimenti si spostano, le certificazioni scadono. Nessuno di questi eventi si annuncia da solo a un sistema di conformità.

Metti insieme le due cose e un passaporto assemblato una volta non è semplicemente incompleto. Scivola fuori dall'accuratezza in silenzio, mentre tutti credono che il compito sia finito. Un'affermazione pubblica sbagliata che nessuno sa essere sbagliata è peggio di una mancante, tanto più che dati inesatti portano sia esposizione verso le autorità sia rischio di risarcimento verso i consumatori, come trattato in sanzioni DPP.

Cosa ne consegue

Se il registro deve restare aggiornato, allora non può essere un artefatto separato mantenuto accanto ai tuoi dati di prodotto. Deve essere generato dalla fonte e aggiornato mentre la fonte cambia.

Quindi Junction tiene il registro di prodotto alla fonte e lo aggiorna mentre il prodotto cambia. Depositare il passaporto diventa un passo dentro un processo invece che un progetto con una scadenza.

Tre conseguenze che abbiamo accettato deliberatamente.

La messa in opera richiede più lavoro che generare un file. Collegarsi a dove vivono davvero i dati di prodotto e di fornitura è più difficile che esportare un foglio di calcolo una volta. Riteniamo che quel costo si paghi una volta sola e che l'alternativa si paghi ogni anno.

Il valore si vede nel secondo anno. Un registro vivo non è ovviamente migliore di un file generato il giorno del lancio. Lo è ovviamente la prima volta che cambia un fornitore.

Aiuta solo se il dato sotto è vero. Nessun sistema converte dichiarazioni non documentate dei fornitori in evidenze. Il lavoro sui fornitori descritto ne la checklist di preparazione è tuo, e qualunque fornitore suggerisca il contrario sta vendendo qualcosa che non reggerà un controllo.

La seconda cosa che fa il codice

L'altra decisione di progetto che vale la pena nominare: leghiamo autenticità e passaporto in un unico codice per prodotto.

Il regolamento non lo richiede. Richiede un supporto che raggiunga un registro. Ma un codice che chiunque può fotografare e ristampare non dimostra nulla sull'esemplare a cui è attaccato, il che significa che buoni dati di sostenibilità possono finire attaccati a un prodotto che non è tuo.

Quasi tutti i sistemi di passaporto trattano la scansione come un modo per raggiungere dati. Noi la trattiamo come un modo per verificare che l'esemplare sia autentico e raggiungere i suoi dati nella stessa azione. È interessante che l'architettura di riferimento CIRPASS-2 non abbia alcun blocco costruttivo per la verifica di autenticità rivolta al consumatore, cosa che segnaliamo come osservazione sull'ambito di quel modello e non come affermazione sul prodotto di qualcun altro.

Cosa questo non è

Non è la tesi che a tutti serva la versione viva dal primo giorno. Un'azienda con una gamma stabile e un solo atto delegato davanti può ragionevolmente partire più semplice.

È un'affermazione su dove cade il costo. L'approccio a file costa meno da iniziare e di più da mantenere, e il mantenimento dura per la vita di ogni prodotto che vendi.

Fonti

• Commissione europea, *Digital Product Passport: FAQ*, aggiornamento gennaio 2026, domanda 3 sul
• dovere dell'operatore di mantenere accurati i dati lungo il ciclo di vita, domanda 30 sui diritti
• di risarcimento dei consumatori.
• CIRPASS-2, *D4.1 Reference Architecture*, versione 1.1, 9 giugno 2026.