CASO DE ESTUDIO · RELEASE 1.0.1

Publicar un no-go también es ingeniería.

Retail Demand Forecasting & Monitoring recorre un sistema de forecasting completo: contrato temporal, baseline, challenger, intervalos, holdout final, persistencia, API y monitoreo. El resultado final no habilitó el modelo para decisiones operacionales, y esa conclusión se conserva como parte central del proyecto. La release 1.0.1 mejora la entrega y las pruebas sin modificar el resultado congelado de la evaluación.

77,02 %cobertura final observada
85 %guardrail mínimo predefinido
52alertas publicadas
1.680pronósticos evaluados

01 · RETO

Evaluar demanda sin fingir que las ventas cuentan toda la historia.

La fuente contiene facturas históricas de un retailer británico sin tienda física. El objetivo se definió como unidades positivas facturadas por SKU y día: un proxy observable, no demanda irrestricta.

No hay información confiable de inventario, quiebres de stock, promociones, cumplimiento ni ventas perdidas. El problema exigía ordenar el tiempo correctamente, mantener el holdout fuera del ajuste y evitar que una mejora promedio escondiera sesgo o deterioro por SKU.

Dashboard de Retail Forecast Lab mostrando cobertura, WAPE, sesgo y pronósticos observados
Replay histórico de solo lectura. No está conectado a un retailer vivo ni validado para compras o inventario.

02 · PROCESO

Congelar decisiones antes de conocer el resultado final.

El proyecto separa desarrollo, confirmación, calibración de intervalos y holdout. Cada fase conserva manifiestos y hashes para que repetir el software no signifique reabrir evidencia usada para decidir.

  1. 01

    Contrato de datos

    Fuente, cohortes, panel diario y reglas temporales documentadas.

  2. 02

    Baseline fuerte

    Seasonal naive de siete días evaluado en folds rolling-origin.

  3. 03

    Gate de promoción

    Error, sesgo, consistencia y amplitud por SKU deciden el champion.

  4. 04

    Intervalos congelados

    Calibración por horizonte sin usar resultados del holdout final.

  5. 05

    Apertura única

    La ventana final se evalúa una vez mediante contrato y recibo.

  6. 06

    Replay y monitoreo

    API, persistencia y dashboard reconstruyen la evidencia histórica.

SELECCIÓN

Una mejora agregada no bastó

El challenger redujo WAPE 11,94 %, pero alcanzó 14,77 % de sesgo absoluto y solo mejoró 10 de 20 productos.

CHAMPION

El baseline conservó el rol

Seasonal naive permaneció como champion porque el candidato no cumplió todas las reglas predefinidas.

INTEGRIDAD

Contratos con identidad

Panel, cohorte, evidencia previa y árbol de código se verifican antes de abrir la evaluación final.

PRODUCTO

Resultado consultable

FastAPI, PostgreSQL/JSON y un dashboard permiten revisar pronósticos, outcomes y alertas ya sellados.

03 · RESULTADOS

El holdout rechazó los intervalos.

Evaluación final sobre 20 SKU, 14 horizontes y 6 orígenes
MétricaResultadoLectura predeclarada
WAPE1,1565Error agregado alto; bajo el umbral de alerta provisional de 2,00
MAE85,1881Unidades por fila SKU-día
Sesgo normalizado+0,0593Dentro del guardrail de ±0,10
Cobertura empírica77,02 %Falla el mínimo de 85 % y el objetivo nominal de 90 %
Ancho medio192,3692Debe leerse junto con la cobertura insuficiente
Winkler score1.105,4818Penaliza simultáneamente amplitud y fallos de cobertura
Cobertura del holdout por horizonte de pronóstico, por debajo del objetivo nominal
La cobertura insuficiente aparece en la evidencia versionada y no se reutiliza como señal para reajustar esta misma release.

DECISIÓN PUBLICADA

degraded_with_published_alerts · no-go operacional

Se emitieron 52 alertas en los niveles global, horizonte y SKU. El resultado demuestra el proceso de evaluación y monitoreo, no la calidad necesaria para automatizar compras.

04 · INGENIERÍA

La evidencia también tiene arquitectura.

TEMPORALIDAD

Backtesting rolling-origin

Veinte folds no solapados y una ventana final de 84 días separan aprendizaje y evaluación.

PERSISTENCIA

JSON y PostgreSQL

Repositorios intercambiables conservan inserciones atómicas, reconciliación e idempotencia.

CALIDAD

Pruebas de integridad

La release revisada pasa 107 pruebas, lint, builds y smoke tests del stack PostgreSQL.

ENTREGA

Demo contenida

Docker Compose expone solo la API en localhost y carga un snapshot histórico de solo lectura.

05 · LÍMITES

Lo que este resultado no permite afirmar.

EVIDENCIA PÚBLICA

Revisar el no-go completo.

El repositorio conserva los contratos, informes, figuras, pruebas y artefactos necesarios para seguir la decisión desde los datos hasta las alertas finales.