Visión general de la investigación aplicada
De estructuras de origen a estructuras de pasaporte
Any2DPP
Conectar un nuevo sistema de origen a un pasaporte de producto no debería significar escribir código nuevo, y signifique lo que signifique, el resultado tiene que decir qué versión de qué correspondencia produjo qué campo.
Estado: Concepto de investigación · prototipo no publicado
Any2DPP y AnyDPP
Any2DPP mapea y valida. No emite nada.
AnyDPP es responsable de la demostración de extremo a extremo: ingesta, decisión, composición y el pasaporte publicado.
Se encuentran en un único adaptador. Any2DPP valida contra el propio esquema UNTP 0.7.0 de versión fijada de AnyDPP y no contra una copia, y solo puede entregar una ejecución liberada al compositor de AnyDPP cuando el origen de la ejecución es una traza del corredor.
La pregunta de investigación
¿Cómo pueden transformarse estructuras de origen heterogéneas en un modelo de destino compatible con el DPP sin perder la procedencia, el significado ni el vínculo con la evidencia, de una forma que una persona pueda revisar?
- ¿Cómo se convierte este campo de origen en ese campo de destino?
- ¿Qué versión de la correspondencia lo produjo?
- ¿Qué falta, y tiene importancia?
- ¿Qué evidencia respalda cada campo?
El modelo, de forma interactiva
Una exportación de un proveedor en portugués, mapeada a campos de pasaporte. Son la definición y el origen que usan las propias pruebas del módulo. Seleccione una regla para seguir un campo, o cambie de versión de la correspondencia para ver qué cambió.
Estructura de origen
- produto.
nome" café ARÁBICA " - produto.
pais"br" - produto.
data"04/05/2026" - produto.
peso"1.200,50" - observacoes"nada"Ninguna regla lo lee
Reglas de correspondencia
Estructura de destino
- type"DigitalProductPassport"
- credentialSubject.
product. name"Cafe Arabica"Evidencia: supplier-export - credentialSubject.
product. originCountry"BR"Evidencia: supplier-export - credentialSubject.
product. producedOn"2026-05-04" - credentialSubject.
product. mass"1200.50"
Completitud
2 de 2 obligatorios · 3 de 3 opcionales
Todos los campos obligatorios están presentes. La estructura puede validarse contra el esquema y una persona puede liberarla.
Primitivas centrales
Definición de correspondencia
MappingDefinitionUna regla por campo de destino. Datos, no código, validados al cargarse: una transformación desconocida falla al cargar, no en silencio durante la ejecución.
Regla de campo
FieldRuleUna ruta de origen o una constante, una transformación, obligatorio u opcional, la fuente de evidencia que respalda el valor y una etiqueta que una persona puede leer.
Lista cerrada de transformaciones
Transformtrim, upper, lower, title, iso_date, decimal, country_code. Añadir una es un acto deliberado con una prueba; no hay lenguaje de expresiones.
Versión inmutable
draft → published → retiredUna correspondencia publicada nunca puede cambiar. Un cambio es una versión nueva con el mismo nombre, y cada ejecución registra la versión que la produjo.
Diagnóstico por campo
DiagnosticMapeado, constante, ausente o falló la transformación, junto al campo, además de los campos de origen que ninguna regla lee y los recuentos de completitud.
Liberación humana
compose.handoffEl momento en que el resultado deja de ser interno es una decisión de una persona, registrada como acto de autoridad. No lo elige una máquina.
Un escenario, paso a paso
De la exportación de un proveedor a una estructura que podría alimentar un pasaporte.
Paso 1 de 6: Escribir la correspondencia como datos
Reglas para el nombre, el país de origen, la fecha de producción y la masa, cada una con una transformación y, donde importa, la fuente de evidencia.
La correspondencia se aplica a una muestra. La vista previa no escribe nada, así que un borrador puede probarse tantas veces como haga falta.
La versión queda congelada. A partir de aquí, una pregunta como «¿por qué esto produjo aquello?» siempre tiene respuesta.
El origen se incorpora a la cadena como hash, cada regla produce su diagnóstico y el resultado se valida contra el esquema UNTP de versión fijada.
Una persona libera la ejecución. Una ejecución fallida no puede liberarse; una ejecución liberada conserva su liberación aunque la entrega se rechace.
Una ejecución cuyo origen es una traza del corredor va al compositor de AnyDPP. Cualquier otro origen se rechaza con un motivo, no se compone.
Qué existe y qué no
En el repositorio
- app/products/any2dpp/mapping.py: definición, transformaciones cerradas, diagnósticos por campo, completitud, campos de origen no leídos
- service.py: crear, editar borrador, publicar, retirar, vista previa, ejecutar, solicitar liberación, liberar, entregar
- adapters/anydpp.py: el único archivo que llega a AnyDPP, para su esquema de versión fijada y su compositor
- Tablas any2dpp_mappings y any2dpp_runs; 14 rutas autenticadas
- tests/any_family/test_any2dpp.py: motor, inmutabilidad, la puerta de liberación, el adaptador real de AnyDPP (31 pruebas)
Agenda de investigación, no construido
- Introspección del esquema de origen: el origen es un contenido, y nada infiere su forma
- Una representación intermedia canónica entre origen y destino
- Correspondencia de vocabularios y conversión de unidades más allá de las transformaciones nombradas
- Listas y cardinalidad: las rutas son claves con puntos dentro de objetos, por diseño por ahora
- Diferencias entre versiones de correspondencia y migración entre versiones del perfil de destino
- Una pantalla de edición guiada: la vista previa y los diagnósticos existen, el editor de varios pasos no
- Componer un pasaporte a partir de un origen arbitrario: el compositor de AnyDPP lee una traza, por su propio contrato
Qué lo distingue
- AnyDPP
Su pregunta
¿Cómo funciona un pipeline completo de la evidencia al pasaporte?
Por qué esto no es aquello
AnyDPP lee las fuentes para las que tiene extractores. Any2DPP estudia cómo se describe al sistema cualquier estructura de origen como un contrato revisable y versionado.
- AnyTrace
Su pregunta
¿Por dónde ha pasado esta cosa?
Por qué esto no es aquello
Any2DPP vincula los campos mapeados a la evidencia de la traza; no sigue a la cosa en sí.
- AnyVerify
Su pregunta
¿Sostiene la evidencia esta afirmación?
Por qué esto no es aquello
Un campo mapeado es un campo bien formado, no un campo verificado.
Dónde se sitúa en AnyLAI
Any2DPP
- AnyDPPValida contra el esquema UNTP 0.7.0 de versión fijada de AnyDPP y entrega a su compositor las ejecuciones con origen en una traza, a través de un único adaptador.
- AnyTraceUna ejecución enlaza con el caso de traza cuyos datos mapea; los campos quedan vinculados a la evidencia de esa traza.
- Application kernelLas ejecuciones son casos del núcleo; el hash del origen está en la cadena; la liberación es un acto de autoridad.
- COADFEl conocimiento de las reglas como datos, la carga con denegación por defecto y un recorrido determinista sin modelo de lenguaje: los principios de COADF, aplicados, sin declaración de conformidad.
- enlace entre casos a través del núcleo
- uso directo de otro módulo o sistema
- llamada en modo sombra: registrada, nunca ejecutada
Límites y objetivos excluidos
- Nunca emite, firma ni publica un pasaporte.
- No es dueño del estándar del pasaporte; comprueba contra el esquema que fija AnyDPP.
- Solo puede entregar ejecuciones cuyo origen es una traza del corredor.
- Un campo que se mapea sin problemas está bien formado, no es verdadero.
Estado actual
Estado de la investigación
- Concepto de investigación · prototipo no publicado
- No publicado: rutas desactivadas
- Sin uso en producción, sin datos reales
- 31 pruebas en el repositorio
Un módulo prototipo sobre el núcleo compartido: motor de correspondencias, servicio, adaptador, tablas, rutas y pruebas. Desactivado, no publicado, no usado con datos reales de proveedores. La agenda de investigación de arriba es más amplia que lo que existe, y figura como agenda.
Batería de pruebas: python-backend/tests/any_family/test_any2dpp.py
Proyecto de investigación · I+D independiente · No es una oferta comercial
