RUT4 | Devpost

Test Casses Passed

¿Qué hace exactamente? 1) Motor de decisión El backend se encuentra en decision_engine.py y expone una API FastAPI con endpoints como:

GET /health: verifica que el servicio está activo. POST /decide: recibe un pedido y devuelve: decision: ACCEPT o SKIP reason: explicación del resultado binding_constraint: restricción que causó el bloqueo, si aplica latency_ms: tiempo de procesamiento El motor aplica reglas como:

zona bloqueada por la noche, descanso obligatorio, regla de calor, fin de turno imposible, exceso de capacidad del vehículo, no cubrir el reservation wage mínimo. Esto convierte al sistema en una solución explicable y auditable, en lugar de una caja negra.

2) Dashboard en tiempo real El archivo app.py levanta una interfaz con Streamlit. En la pantalla puedes ver:

ciclo actual, decisiones recientes, alertas del sistema, resumen de restricciones activas, bitácora de evidencia por decisión. Esto permite que un usuario o juez revise qué está haciendo el motor sin tener que inspeccionar archivos internos.

3) Simulador de pedidos En src/simulator.py hay un simulador que:

carga una serie de pedidos desde un CSV, los envía al motor HTTP, registra el resultado, guarda un snapshot en events_log.json, genera un log de auditoría en events_log.jsonl. Esto hace que el proyecto se vea como un sistema operativo real: recibe entradas, toma decisiones y deja evidencia.

4) Auditoría y trazabilidad Los logs contienen información útil para demostrar que todo ocurrió en orden:

ciclo, timestamp, decisiones, restricciones, eventos del sistema. Esto ayuda mucho si el proyecto se presenta a jueces o evaluadores, porque deja claro que el sistema no solo responde, sino que deja registro de lo que hizo.