Mapa maestro del ecosistema DPP / circular¶
Arte Taxco · 25 Julio 2026 · Punto de entrada único — empieza aquí
Para qué existe: el ecosistema se volvió amplio (mercado de ofertas, escrow, KPIs, roles de actor, multi-industria). Este documento es el índice y la secuencia: qué existe, qué está construido, qué es roadmap, y en qué orden se construye. Ancla todo en los tres mecanismos del marco académico del grupo, para que el software y la narrativa de fondos hablen el mismo idioma.
Los tres mecanismos (el marco que ordena todo)¶
Del manuscrito institucional (economía de costos de transacción + asimetría de información) — tres mecanismos, tres proposiciones. Todo lo que construimos sirve a uno de ellos:
| # | Mecanismo / Proposición | Traducción a software | KPI que lo mide |
|---|---|---|---|
| P1 | Transparencia con verificación proporcional a lo que está en juego | Fee de verificación escalonado por valor; recertificación física con linaje | KPI 1 (costo de verificación) + KPI 4 (integridad de linaje) |
| P2 | Reestructuración de costos de transacción (capturar una vez, vender en muchos canales; los costos migran a la gobernanza) | Neon como fuente de verdad; publicación multicanal | Evidencia multicanal (ya operativa) |
| P3 | Estabilización de mercados circulares (requisitos varían por tipo de modelo circular) | Ecosistema multi-actor: reventa, reparación, remanufactura, reciclaje | KPI 2 (re-verificaciones) + KPI 3 (piezas reabiertas) |
El paper JCP complementa con la capa de gobernanza de datos + capacidades dinámicas mediadas por IA (por qué el dato no genera valor circular solo).
Estado por nivel de madurez¶
| Nivel | Qué hay |
|---|---|
| Operativo en producción | Pipeline captura→IA→multicanal (Shopify+MELI, decremento de stock); >4,000 productos en Neon; certificados con QR; EventoInventario EPCIS 2.0; primera venta real con Stripe |
| Construido, no automatizado | Liberación del pago al vendedor en escrow (SPEI manual; reembolso sí automático) |
| Diseñado y verificado en código | Cadena de escrow completa; pantalla de operador /admin-erp/escrow; instrumento de 4 KPIs /admin-erp/kpis-circular |
| Roadmap (diseño documentado) | Ecosistema circular multi-actor (roles, historial circular completo, listado proactivo, APIs) |
Índice de documentos¶
| Documento | Qué cubre |
|---|---|
VISION.md |
La tesis: el DPP es el foso, el multicanal el gancho |
ARQUITECTURA-CIRCULARES.md |
Actores A/B/C, flujos de taller y circular, roadmap |
ARQUITECTURA-CIRCULAR-MERCADO-OFERTAS.md |
Modelo económico del mercado de ofertas (fee, escrow) + anclaje literatura/regulación (diseño) |
ARQUITECTURA-DPP-OFERTAS-ESTADO-REAL.md |
Estado REAL (as-built) de la página del DPP + mercado de ofertas: qué está completo/stub/documentado-no-construido, con file:line. Empieza aquí para "¿cómo funciona HOY?" |
ARQUITECTURA-DPP-CADENA-PROPIEDAD.md |
DISEÑO (no construido) de la cadena de propiedad + ciclo de vida: propietario #1 automático, actualizar registro (regalo), eventos declarados vs verificados, explicador ESPR. Feed para el chat de interoperabilidad + copy propuesto de la carta/página |
HANDOFF-INTEROPERABILIDAD-DPP.md |
Traspaso al chat de interoperabilidad: qué diseñar (export XML+PDF con diccionario, VC/JSON-LD, EPCIS emisor) + 9 dudas concretas a resolver. Las respuestas se integran en la nota de cadena de propiedad |
DECISIONES-INTEROPERABILIDAD-DPP.md |
Decisiones recomendadas del arquitecto a las 9 dudas del handoff (6 no-regret + Q4/Q9 gatean fondos) + priorización en tiers. Punto de partida para el chat de interop |
docs/20260727-DPP-textil-propuesta-implementacion-ICEDE.docx |
Propuesta de política de DPP textil para el director de tesis (ICEDE/USC), sesgo de economía circular transformadora, amarrada a convocatorias |
ARQUITECTURA-CIRCULAR-ECOSISTEMA-MULTIACTOR.md |
Visión ampliada (roles, historial R, listado proactivo, APIs) — roadmap |
FIXES.md → FEAT-CIRCULAR-002 |
Auditoría de la cadena de escrow + pantalla de operador + KPIs |
docs/20260725-ANEXO-DPP-politicas-fundraising.docx |
Anexo de políticas + evidencia (entregable de fondos) |
docs/20260725-CONTEXTO-TECNICO-para-fondos-europeos.docx |
Nota de contexto para el chat de fondos + guía anti-sobreafirmación |
Secuencia de construcción del ecosistema multi-actor¶
Orden por dependencia (cada paso habilita el siguiente). Todo aditivo al schema;
nunca migrate dev.
- Paso A — Fundación: modelo de eventos R + historial circular visible. ✅ HECHO (25 Jul 2026).
Tipos
EventoTipoR añadidos (REMANUFACTURADO/RECICLADO/MANTENIMIENTO;REPARADO/FUNDIDOya existían); historial anonimizado en la página del producto (lib/circular/historial.ts); write-pathadmin.circular.registrarActividadCircular -
UI
/admin-erp/actividad. Faltadb pushpara escribir los 3 tipos nuevos. VerFIXES.md→ FEAT-CIRCULAR-003. -
Paso B — Roles de actor circular con mínimo privilegio. ✅ HECHO (25 Jul). B1: registro de actores (
ActorCircular+/admin-erp/actores). B2: superficie del actor/actor(login OTP +lib/circular/actor-scope.tsde mínimo privilegio -
registrar actividad) + ubicación del actor. Sirve a P1 y P3.
-
Paso C — Listado proactivo. ✅ HECHO (25 Jul). Venta directa ("cómpralo ya"): el dueño fija precio en
/portal(Mis piezas); el comprador compra en la página del certificado → mismo escrow.comprarAhora portalFijarPrecioVenta+Certificate.precioVentaDirectaMXN. El público que vende piezas sin certificado usa el flujo Ruta A (crearSolicitud). Sirve a P3.
⏸ Prioridad estratégica (funds-first, 25 Jul 2026): lo que dicta la prioridad son los fondos europeos disponibles y sus requisitos. El Paso D (distribución multi-marketplace-circular real y escalable) se pospone hasta tener fondos. Se prioriza el Frente 2 — datos abiertos (modelo de atributos → acceso por campo → portabilidad PDF/XML → Verifiable Credentials / estándares ESPR), que es lo que mapea a los criterios de fondos (interoperabilidad, datos abiertos, alineación regulatoria). La priorización fina de mañana la dictan los requisitos concretos de los fondos objetivo (input del chat de fondos europeos).
-
Paso D — Interconexión por APIs. ⏸ Pospuesto hasta financiamiento (ver arriba). Publicar piezas circulares en marketplaces de segunda mano (sus APIs) y exponer las nuestras para que los actores integren sus flujos. Sirve a P2 y P3.
-
Frente 2 — Datos abiertos. ✅ Tier 0 + Tier 1 en producción (27 Jul 2026).
- Tier 0 (cimiento):
AtributoDPP(atributo-registro con estatus epistémico + provenance;clase= acceso por campo) +RegistroPropietario(cadena §2) +lib/dpp/{atributos,propietarios}.ts. - Propiedad end-to-end: propietario #1 automático al vender (Shopify+MELI) + visible en el DPP + backfill (50) + copy de la carta verdadero (§7).
-
Tier 1 (export portable): emisor EPCIS 2.0 (JSON-LD) + XML autodescriptivo (diccionario embebido) + PDF con XML embebido (ZUGFeRD-style) + dos proyecciones (pública redactada / dueño completa por OTP).
lib/dpp/export.ts+GET /api/dpp/{folio}?f=xml|epcis|pdf[&sesion=]. VerFIXES.md→ FEAT-DPP-DATOS-001. Pendiente: PDF/A-3 estricto (gateado a fondos), XSD hospedado + diccionario generado, y el GATE (actualizar manuscrito/página: ya "emite" EPCIS, no solo "serializable"). -
Transversal — Consistencia de proposiciones. ✅ HECHO (25 Jul). Etiquetas de KPIs alineadas a las 4 proposiciones (JIEM P1–P3 + JCP P4).
-
Transversal — Portabilidad del DPP / plataforma abierta (POR PLANEAR con D). Cada DPP debe poder descargarse en PDF y XML para que el usuario porte sus datos a cualquier otro sistema (Data Act UE 2023/2854 + argumento de plataforma abierta e interoperable, clave para fondos europeos). Base existente:
lib/epcis.tsya mapea los eventos a GS1 EPCIS 2.0 (hoy serializa, no emite documento); el patrón de PDF vive en/api/print/*. Ojo (anti-sobreafirmación): hoy el sistema se describe como "alineado con EPCIS 2.0 y serializable a él, no emite documentos" — construir el export lo convierte en emisor real de EPCIS 2.0, y ese cambio debe reflejarse en el manuscrito y la página de evidencia.
Interoperabilidad semántica (no solo sintáctica): el XML debe ser
autodescriptivo para que otro sistema interprete el contenido sin adivinar —
esquema (XSD) + diccionario de campos embebido o enlazado, anclado en
docs/DICCIONARIO-CAMPOS-SISTEMAS.md, y vocabularios controlados (GS1 CBV ya se
usa). Alineación futura: adoptar los estándares, modelos y marcos de datos
internacionales que defina el acto delegado del ESPR por categoría (textil
primero, ~2027); diseñar el export para poder mapear a ellos cuando se publiquen,
no reinventar un esquema propio.
Dos ejes de estándares (ortogonales):
1. Horizontal — procesos circulares (igual para todo producto): eventos de
ciclo de vida (reparar/revender/reciclar). Ya con GS1 EPCIS 2.0 / CBV.
2. Vertical — atributos por tipo de producto (distinto por grupo prioritario):
joyería (ley/peso/piedra), textil (composición de fibra/origen), electrónica
(componentes/salud de batería). Cada categoría tendrá su propio estándar,
definido por su acto delegado.
Los estándares serán progresivos, incrementales y evolutivos → el export debe
ser modular y versionado: datos internos → mapeador por categoría → estándar
destino. Así se adopta cada estándar al publicarse sin rehacer lo demás; el
productType/categoría de la pieza selecciona el perfil de atributos aplicable.
- Transversal — Atributos con estatus epistémico + acceso por campo (POR PLANEAR). Del paper JIEM: hay atributos credence (no verificables ni con el uso: ley, origen, autoría) y otros que se verifican con eventos (reparación revela condición; reciclaje mide la ley; reventa re-confirma). Sugerencias de diseño:
- Atributo-como-registro, no columna:
{clave, valor, unidad, estatus (declarado|verificado|medido), emisor(rol), fecha, víaEvento→EventoInventario, confianza}. Resuelve de un golpe credence-vs-verificado (P1), provenance para interoperar, y acceso por campo. Es la pieza madre. - Acceso por CLASE de campo (identidad/personal, specs-técnicas, composición-
material, comercial/precio, condición/historial): matriz rol × clase,
declarativa, auditable, evolutiva. Evoluciona
lib/circular/actor-scope.tsde scoping por objeto a política. - El estatus avanza con el eje horizontal: el evento que confirma un credence lo pasa a verificado/medido y lo enlaza — une procesos ↔ atributos.
- Formato destino: Verifiable Credentials + JSON-LD/DID (cada atributo = claim firmada por su emisor; verificable sin confiar en la plataforma; hacia dónde va CIRPASS / EU data spaces). El registro-por-atributo mapea 1:1 a VC.
- Una sola política gobierna UI (B2), export (PDF/XML) y APIs. El export lleva el estatus epistémico por atributo, no solo el valor.
Arte Taxco · Mapa maestro del ecosistema DPP · 25 Julio 2026