Warum wir Junction um einen lebenden Datensatz gebaut haben

Jedes Produkt geht eine Wette darauf ein, wie sich sein Markt verhält. Unsere lautet, dass der digitale Produktpass (DPP) als einzureichendes Dokument behandelt wird, und dass sich das als der teure Weg erweisen wird.

Es lohnt sich, die Begründung zu erklären, denn sie bestimmt, was das Produkt tut und was nicht.

Die Wette

Darunter liegen zwei Tatsachen.

Der Wirtschaftsakteur muss die Datenrichtigkeit über den gesamten Lebenszyklus des Produkts aufrechterhalten. Diese Pflicht endet nicht zum Launch; sie läuft, solange das Produkt am Markt existiert, und der Pass soll Reparierenden und Recyclern lange nach dem Verkauf dienen.

Und Produkte ändern sich ständig. Lieferanten werden ersetzt, Materialien neu formuliert, Standorte verlegt, Zertifizierungen laufen aus. Keines dieser Ereignisse meldet sich von selbst bei einem Compliance-System.

Beides zusammen heißt: Ein einmal zusammengestellter Pass ist nicht bloß unvollständig. Er driftet leise aus der Genauigkeit, während alle glauben, die Aufgabe sei erledigt. Eine falsche öffentliche Aussage, von der niemand weiß, dass sie falsch ist, ist schlimmer als eine fehlende, zumal ungenaue Daten sowohl regulatorische Risiken als auch Schadensersatzrisiken gegenüber Verbrauchern tragen, wie in DPP-Sanktionen behandelt.

Was daraus folgt

Wenn der Datensatz aktuell bleiben muss, dann kann er kein separates Artefakt sein, das neben deinen Produktdaten gepflegt wird. Er muss aus der Quelle erzeugt und aktualisiert werden, während sich die Quelle ändert.

Junction hält den Produktdatensatz also an der Quelle und aktualisiert ihn, während sich das Produkt ändert. Die Einreichung des Passes wird zu einem Schritt in einem Prozess statt zu einem Projekt mit Frist.

Drei Konsequenzen, die wir bewusst in Kauf genommen haben.

Die Einrichtung ist mehr Arbeit, als eine Datei zu erzeugen. Sich mit dem zu verbinden, wo Produkt- und Lieferantendaten wirklich liegen, ist schwieriger, als einmal eine Tabelle zu exportieren. Wir halten diese Kosten für einmalig, während die Alternative jedes Jahr bezahlt wird.

Der Nutzen zeigt sich im zweiten Jahr. Ein lebender Datensatz ist am Launchtag nicht offensichtlich besser als eine erzeugte Datei. Er ist es offensichtlich beim ersten Lieferantenwechsel.

Es hilft nur, wenn die Daten darunter echt sind. Kein System verwandelt unbelegte Lieferantenaussagen in Nachweise. Die Lieferantenarbeit aus der Bereitschafts-Checkliste ist deine, und jeder Anbieter, der etwas anderes suggeriert, verkauft etwas, das bei einer Prüfung durchfällt.

Das Zweite, was der Code leistet

Die andere Designentscheidung, die genannt gehört: Wir verbinden Echtheit und Pass in einem Code pro Produkt.

Die Verordnung verlangt das nicht. Sie verlangt einen Träger, der zu einem Datensatz führt. Aber ein Code, den jeder fotografieren und nachdrucken kann, beweist nichts über das Exemplar, auf dem er klebt, und das heißt, dass gute Nachhaltigkeitsdaten an einem Produkt landen können, das nicht deins ist.

Die meisten Passsysteme behandeln den Scan als Weg zu Daten. Wir behandeln ihn als Weg zu prüfen, ob das Exemplar echt ist, und im selben Vorgang zu seinen Daten zu gelangen. Bemerkenswert: Die CIRPASS-2-Referenzarchitektur hat gar keinen Baustein für verbrauchergerichtete Echtheitsprüfung, was wir als Beobachtung zum Umfang dieses Modells festhalten und nicht als Aussage über das Produkt eines anderen.

Was das nicht ist

Es ist nicht die Behauptung, dass jeder die lebende Variante am ersten Tag braucht. Ein Unternehmen mit stabilem Sortiment und nur einem delegierten Rechtsakt vor sich kann vernünftigerweise einfacher starten.

Es ist eine Aussage darüber, wo die Kosten landen. Der Datei-Ansatz ist billiger zu beginnen und teurer zu halten, und das Halten läuft über die Lebensdauer jedes Produkts, das du verkaufst.

Quellen

• Europäische Kommission, *Digital Product Passport: FAQ*, Aktualisierung Januar 2026, Frage 3 zur
• Pflicht der Datenrichtigkeit über den Lebenszyklus, Frage 30 zu Schadensersatzrechten der
• Verbraucher.
• CIRPASS-2, *D4.1 Reference Architecture*, Version 1.1, 9. Juni 2026.