Top-10 retailer latinoamericano

El sistema de forecasting de inventario del retailer impulsaba las decisiones de compra para más de 4,000 SKUs en 200+ ubicaciones de tiendas. Tres meses después de que el equipo de ML desplegara un nuevo modelo de demanda, la precisión del forecast comenzó un lento descenso inexplicable — del 85% al 71% en seis semanas. Los errores de reabastecimiento costaban un estimado de $800K por trimestre en sobrestock y desabastecimiento. La causa raíz estaba distribuida en tres capas de datos: un cambio en el formato de fecha del sistema ERP corrompió la capa Bronze, un bug de agregación downstream en la capa Silver amplificó el error, y la ingeniería de features de la capa Gold compensó silenciosamente — produciendo inputs de forecast plausibles pero sistemáticamente incorrectos. Ningún equipo veía el panorama completo.

NEXUS™ fue configurado con la arquitectura Medallion completa de tres capas. Se desplegaron detectores de drift estadístico en 47 features de inventario y ventas, estableciendo baselines a partir de 90 días de ejecuciones históricas. El ML Reliability Score (MRS) se calculaba diariamente contra cada grupo de features. En la primera semana de despliegue, la comparación temporal de drift identificó cambios en z-score por encima de 3.2 desviaciones estándar en tres features derivadas de fechas — precisamente el cambio de formato del ERP. SENTINEL™ trazó el grafo de linaje de datos para identificar todos los datasets y modelos downstream que consumían las features corruptas, disparando automáticamente el aislamiento del pipeline y notificando al equipo de ingeniería de datos. Los umbrales de validación del Medallion fueron ajustados: Bronze al 50%, Silver al 75%, Gold al 90%. Cualquier ejecución Gold que fallara el umbral del 90% bloqueaba automáticamente al modelo de forecasting de consumir features actualizadas.

El despliegue completo con integración Iceberg se completó en 16 días. La capacidad de time-travel demostró ser inmediatamente valiosa — el equipo usó el historial de snapshots de Iceberg para reconstruir exactamente qué ejecución del pipeline introdujo por primera vez las features corruptas. El modo merge de Apache Iceberg en el pipeline Silver permitió la reparación automatizada de datos: el equipo corrigió el formato de fecha del ERP, reprodujo las ejecuciones afectadas y fusionó las correcciones sin reprocesamiento completo del dataset.