Por qué construimos Junction alrededor de un registro vivo

Todo producto hace una apuesta sobre cómo se comportará su mercado. La nuestra es que el pasaporte digital de producto (DPP) se tratará como un documento que se entrega, y que eso resultará ser la forma cara de hacerlo.

Merece la pena explicar el razonamiento, porque determina qué hace y qué no hace el producto.

La apuesta

Debajo hay dos hechos.

El operador económico tiene que mantener la exactitud de los datos durante todo el ciclo de vida del producto. Ese deber no termina en el lanzamiento; dura mientras el producto exista en el mercado, y el pasaporte debe servir a reparadores y recicladores mucho después de la venta.

Y los productos cambian constantemente. Se sustituyen proveedores, se reformulan materiales, se mueven instalaciones, caducan certificaciones. Ninguno de esos hechos se anuncia solo a un sistema de cumplimiento.

Junta las dos cosas y un pasaporte ensamblado una vez no es simplemente incompleto. Se desvía en silencio de la exactitud mientras todos creen que la tarea está terminada. Una afirmación pública incorrecta que nadie sabe que lo es resulta peor que una ausente, más aún dado que los datos inexactos acarrean tanto exposición regulatoria como riesgo de indemnización al consumidor, como se trata en las sanciones del DPP.

Qué se deduce de ahí

Si el registro tiene que mantenerse al día, entonces no puede ser un artefacto separado mantenido al lado de tus datos de producto. Tiene que generarse desde el origen y actualizarse a medida que el origen cambia.

Así que Junction mantiene el registro de producto en origen y lo actualiza a medida que el producto cambia. Presentar el pasaporte pasa a ser un paso dentro de un proceso en vez de un proyecto con un plazo.

Tres consecuencias que aceptamos deliberadamente.

La puesta en marcha da más trabajo que generar un archivo. Conectarse a donde viven realmente los datos de producto y de proveedores es más difícil que exportar una hoja de cálculo una vez. Creemos que ese coste se paga una vez y que la alternativa se paga cada año.

El valor aparece en el año dos. Un registro vivo no es obviamente mejor que un archivo generado el día del lanzamiento. Lo es obviamente la primera vez que cambia un proveedor.

Solo ayuda si el dato de debajo es real. Ningún sistema convierte declaraciones de proveedores sin evidencia en evidencia. El trabajo con proveedores descrito en la checklist de preparación es tuyo, y cualquier proveedor que sugiera lo contrario está vendiendo algo que no aguantará una revisión.

La segunda cosa que hace el código

La otra decisión de diseño que merece nombrarse: unimos autenticidad y pasaporte en un solo código por producto.

El reglamento no lo exige. Exige un soporte que llegue a un registro. Pero un código que cualquiera puede fotografiar y reimprimir no demuestra nada sobre la unidad a la que está adherido, lo que significa que buenos datos de sostenibilidad pueden acabar pegados a un producto que no es tuyo.

La mayoría de los sistemas de pasaporte tratan el escaneo como una forma de llegar a datos. Nosotros lo tratamos como una forma de comprobar que la unidad es auténtica y llegar a sus datos en la misma acción. Resulta llamativo que la arquitectura de referencia CIRPASS-2 no tenga ningún bloque de construcción para la verificación de autenticidad orientada al consumidor, lo que señalamos como observación sobre el alcance de ese modelo y no como afirmación sobre el producto de nadie.

Qué no es esto

No es la afirmación de que todo el mundo necesite la versión viva el primer día. Una empresa con una gama estable y un solo acto delegado por delante puede razonablemente empezar más sencillo.

Es una afirmación sobre dónde cae el coste. El enfoque de archivo es más barato de empezar y más caro de mantener, y el mantenimiento dura toda la vida de cada producto que vendes.

Fuentes

• Comisión Europea, *Digital Product Passport: FAQ*, actualización de enero de 2026, pregunta 3 sobre
• el deber de exactitud de los datos durante el ciclo de vida, pregunta 30 sobre derechos de
• indemnización de los consumidores.
• CIRPASS-2, *D4.1 Reference Architecture*, versión 1.1, 9 de junio de 2026.