Arquitectura

Darwin es tres productos coordinados sobre un protocolo unificado: Captia (captura), Tracium (trazabilidad), Fidenta (digital product passport). Son apps whitelabel sobre la misma infraestructura compartida.

Flujo de alto nivel

   Captura (Captia)   →   Trazabilidad (Tracium)   →   Pasaporte (Fidenta)
        ↓                       ↓                            ↓
   operadores de         supply-chain admins        consumidores + retailers
   campo capturan        estandarizan +             + auditores ven el DPP
   eventos               anclan on-chain            vía QR
   on/offline + IoT

Para el desglose visual completo de inputs → plataforma → outputs, ver el diagrama de arquitectura de la plataforma.

Los tres productos

Captia (`traceability-pwa`)

La capa de captura. PWA mobile + conectores ERP / IoT / CSV.

Cierra el wedge: digitaliza el taller, el campo, la cooperativa donde no existe sistema hoy. Offline-first; el operador captura el evento desde el celular sin conectividad, la PWA lo encola con UUIDs idempotentes generados por el cliente, y los envía cuando vuelve la red.

Captia también ingiere data de los sistemas que el cliente ya corre (SAP, Oracle, Microsoft Dynamics, ERPs custom, IoT MQTT brokers, archivos CSV / Excel / EPCIS 2.0). El principio es sin rip-and-replace: Darwin convive con los sistemas existentes, no se monta encima.

Tracium (`tenant-portal`)

La capa de trazabilidad. Estandariza eventos de Captia + ingestion, los valida contra el process map del tenant, ancla los eventos críticos on-chain, y auto-genera bundles regulatorios por framework.

Surface para admin de operaciones + compliance officer. A partir de 2026-05 es read-only vía API REST + GraphQL; las write-ops para acciones admin se shippan Q2-Q3 2026.

Fidenta (`passport-viewer` + `passport-dashboard`)

La capa de identidad digital. Acuña un Digital Product Passport por producto, accesible vía QR. Vistas por stakeholder:

Consumidor — storytelling, certificaciones, huella ambiental.
Retailer — datos de compliance, evidencia del proveedor.
Auditor — prueba on-chain, IPFS CIDs, metadata raw.
Brand — analytics, métricas de scan, geolocalización de consumo.

El viewer es whitelabel por brand.json, multilingüe (es / en / pt-BR), y sirve SSR para first paint rápido.

El protocolo compartido

Debajo de los tres productos, Darwin corre un solo protocolo — 13 smart contracts deployeados una vez por chain, más el Passport registry, más los servicios off-chain que orquestan todo.

On-chain

Chain actual (sandbox + early-production): Geth self-hosted, chainID 1337. Sin costo per-tx; controlado por el platform.
Chain options (futuro, decisión gateada por necesidades del primer paying customer): Polygon PoS (L1 production-class), Own OP-Stack L2, o RaaS (Conduit / Caldera / Gelato). Decision framework en COST_ESTIMATION_MODEL.md §7.
13 contracts: 7 identidad (DIDs, organizaciones, permisos) + 4 process (NFT inventory, trace events, process map) + 2 templates per-instance.
Ver On-chain vs off-chain para qué va on-chain vs qué se queda en la base de datos operativa.

Off-chain (managed)

Postgres (TypeORM) — DB operativa
IPFS Kubo — storage content-addressed para evidencia de eventos (fotos, certificados, documentos raw)
Nginx + config-registry — distribución de config por tenant
MinIO — object storage
Redis — caches + queues
stack de monitoreo (Prometheus / Grafana / Loki)

Hosteado en AWS EC2 (2-tier: core + apps) — los clientes no corren nodos blockchain. La plataforma sí.

AI Insights

Capa sobre los eventos:

Detección de anomalías (rules engine determinístico, en producción): rupturas de cadena de frío, ghost lots, gaps de custodia, expiración de certificados, timing inusual.
Compliance agéntico (roadmap Q3 2026): Q&A en lenguaje natural contra frameworks regulatorios. “¿El lote LOT-8901 se puede exportar a US?”

Cinco categorías de anomalías shipean hoy; once más en el roadmap. Ver overview de AI Insights en el sitio principal.

Modelo multi-tenant

Un solo entorno hostea múltiples tenants. Aislación de tenant:

On-chain: cada tenant tiene su propio contrato Tenant.sol + sub-árbol de config-registry por tenant.
Off-chain: scoping de tenantId en la capa de DB; control de acceso row-level vía JWT scopeado por tenant + API keys.

Ver Tenants e identidad para el modelo de datos.

Whitelabel por default

Cada front-end lee brand.json en runtime. Nuevos tenants eligen su brand al provisioning. La marca Darwin Evolution es el primer cliente whitelabel; sirve como demo branding que ves hoy en darwinevolution.io.