GOLDGUARD
Inteligencia para joyería. En tiempo real.
Un sistema de seguridad de IA + hardware + visión por computadora que convierte las superficies de exhibición de joyería en zonas pesadas de forma continua, de modo que una pieza que sale de una bandeja se convierte en un evento y no en un hallazgo a la hora del cierre.
GoldGuard es una plataforma de inteligencia de inventario físico y prevención de pérdidas en tiempo real para joyerías. Cuatro zonas con celdas de carga bajo una superficie de exhibición alimentan un ADC delta-sigma de 24 bits y un controlador ESP32-S3; el backend ejecuta una cascada de filtros DSP, una máquina de estados de estabilidad, un clasificador de eventos y un motor de correlación entre zonas que reconoce transferencias internas sin pérdida. Los resultados se transmiten por WebSocket a un panel de control en React con roles, enlaces compartidos y un informe matutino.
Un subsistema de visión paralelo añade seguimiento de personas y manos mediante cámara, manteniendo la celda de carga como fuente autoritativa: una asociación incorrecta se degrada a AMBIGUOUS, nunca a una falsa alerta de robo. El repositorio se autoaudita en cuanto a su propio estado: la plataforma de software es funcional y está cubierta por una suite automatizada, la simulación está verificada, el firmware compila para ESP32-S3 y la validación física está explícitamente a la espera del hardware.
Visión general
El propio oro es el escudo. GoldGuard convierte cada gramo de una vitrina en datos: pesado de forma continua, clasificado en eventos de negocio, correlacionado entre zonas y entregado a la tienda en tiempo real.
Problema
La pérdida de joyería se descubre a la hora del cierre, cuando el recuento no cuadra y nadie puede decir qué bandeja, qué hora ni qué mano. Las cámaras lo graban todo y no explican nada. Una báscula bajo una sola bandeja te dice un peso, no un evento.
“Una pieza que sale de una bandeja se convierte en un evento —ITEM_REMOVED, ITEM_ADDED, INTERNAL_TRANSFER, TRAY_REMOVED, TAMPER_EVENT— en lugar de un hallazgo a la hora del cierre.”
Sistema
La capa 1 son los transductores: cuatro celdas de carga de galga extensiométrica de punto único con capacidad de 5 kg por zona, un sensor de temperatura TMP117 y un acelerómetro LIS2DW12 para vibración y manipulación. La capa 2 es el firmware de borde del ESP32-S3, que muestrea a 10–80 Hz por canal con DSP en el dispositivo y una máquina de estados de estabilidad. La capa 3 es un backend de arquitectura limpia —dominio, aplicación, infraestructura, API— con Express, un hub ws y PostgreSQL detrás de un contrato de repositorio con respaldo en memoria.
La canalización de peso es una cascada de rechazo de valores atípicos → mediana móvil → EMA → media móvil, seguida de compensación de deriva, un motor estadístico de estabilidad y un clasificador de eventos. Un motor de correlación entre zonas empareja ΣΔW ≈ 0 entre zonas dentro de una ventana de 1,5 s para reconocer una pieza movida de una bandeja a otra como una transferencia interna, no como una pérdida.
Arquitectura
- CELDAS DE CARGA ×45 kg / zone
- ADC ADS1234 DE 24 BITSganancia 128
- FIRMWARE ESP32-S3DSP · FSM · cola sin conexión
- INGESTA STORE-AND-FORWARDguarda de secuencia
- MOTOR DE PESOfiltros · deriva · estabilidad · clasificador
- CORRELACIÓN ENTRE ZONASΣΔW ≈ 0 en 1,5 s
- FUSIÓN DE VISIÓNidentidad portada por la mano · celdas autoritativas
- POSTGRESQL27 tablas · migraciones
- HUB WEBSOCKETprotegido por token
- PANEL · ESCRITORIO · PORTALReact · Tauri · Cloudflare
Superficie del repositorio
- 01backend — API Express, hub ws, motores, migraciones, 36 archivos de test
- 02frontend/goldguard-dashboard — React 19 + Vite, más de 23 vistas, árabe / hebreo / inglés
- 03apps/marketing — exportación estática de Next.js, historia de producto en three.js guiada por scroll, 5 idiomas
- 04apps/desktop — shell Tauri 2 con flujos de publicación para Windows y macOS
- 05apps/twin-studio + simulator/goldguard-twin — gemelo digital visual y headless
- 06services/goldguard-vision + goldguard-vision-runtime — dominio de visión en TS puro y runtime ONNX
- 07services/goldguard-vision/ml — entrenamiento en PyTorch, evaluación y exportación a ONNX
- 08firmware/goldguard-controller — C++ con ESP-IDF para ESP32-S3
- 09hardware/cad/fusion360 — scripts paramétricos de Fusion 360; geometría exportada a la web
IA y visión
La arquitectura de visión parte de una restricción medida, no de una lista de deseos: en grabaciones de tienda a 3840×2160, un anillo sobre la bandeja tiene una huella mediana de 28 px y, tras el redimensionado a 800 px del detector, queda en 5,8 px frente a un ancla mínima de 32 px. La inferencia sobre el fotograma completo encontró 0 anillos donde 32 mosaicos nativos encontraron 7. Por eso el diseño ejecuta dos flujos —personas y manos sobre un fotograma reducido a 10 Hz, y censo de bandejas sobre mosaicos a resolución nativa condicionado a la presencia de manos— y permite que una pieza herede la identidad de la mano que la transportó.
“La identidad individual y continua de ~50 anillos estáticos, en contacto y casi idénticos es una degeneración del problema, no un límite de calidad del modelo. Sigue la mano; deja que la pieza herede la identidad de quien la porta.”
Diseño
El propio oro es el escudo.
Dos caras de oro enfrentadas forman un escudo con un lingote sobre una plataforma de pesaje en su corazón oscuro. Solo geometría recta, legible desde una valla publicitaria hasta un favicon de 16 px. El cian de sensor se reserva para la medición en vivo dentro del panel de control y se mantiene deliberadamente fuera de la marca.
- —GOLD en #F5F7FA, GUARD en el degradado dorado
- —Inter ExtraBold, espaciado de letras 2,5
- —Corte compacto para 16–31 px, corte mono para grabado
Desafíos
- 01Un primer ajuste de filtros cancelaba los cambios de peso reales como valores atípicos: una extracción de 8 g producía 0 eventos. Corregido el 2026-08-23; la misma extracción ahora genera exactamente un ITEM_REMOVED con Δ −8,05 g.
- 02La v1.0.0-rc estaba en verde 67/67 mientras la ruta de PostgreSQL estaba rota: los tests en verde que nunca tocan la ruta de producción no demuestran nada sobre ella. La suite con Postgres real ahora forma parte de la CI.
- 03El producto se dividió brevemente en dos árboles con 44 archivos en conflicto y seis conflictos semánticos que una herramienta de merge no señalaría. Un plan de merge escrito y una auditoría de arquitectura preceden a la fusión.
- 04Nunca se ha conectado una celda de carga. Cada cifra de masa, ruido y latencia del repositorio está etiquetada como objetivo de diseño, no como medición.
Resultados
El cliente recibe un portal de progreso permanente y sin túneles en Cloudflare Workers —porcentaje, el plan de cinco semanas, lo completado y lo que viene después—, mientras que las mediciones en vivo y la consola operativa nunca llegan a él.