Forecast Pattern: anticipar antes de ejecutar
Antes de mutar un sistema conviene saber qué pasará después. Eso parece obvio, pero en la práctica muchas operaciones se autorizan con evidencia incompleta: un preflight que confirma prerrequisitos, un dry-run que muestra un plan parcial, o un rehearsal que ensaya el mecanismo sin proyectar el estado final. Llamo Forecast Pattern a la práctica de anticipar estados futuros, consecuencias y riesgos antes de decidir. Es terminología propia de este archivo; no la presento como patrón formal reconocido universalmente.
Cuatro modos que no son lo mismo
Confundir estos modos produce decisiones con expectativas falsas:
| Modo | Pregunta que responde |
|---|---|
| Preflight | ¿Están dadas las condiciones para intentar la operación? |
| Dry run | ¿Qué haría la operación sin mutar todavía? |
| Rehearsal | ¿Puedo ensayar el recorrido con fidelidad suficiente para detectar problemas? |
| Forecast | ¿Qué estados, efectos colaterales y riesgos aparecerán si autorizo esto? |
Un preflight puede fallar porque falta una dependencia. Un dry-run puede mostrar un plan sin revelar cuellos de botella posteriores. Un rehearsal puede validar el flujo sin estimar el volumen de datos afectado. El forecast cierra esa brecha: no sustituye a los otros modos, sino que añade proyección explícita.
Qué aporta el forecast
Un forecast útil combina observación del estado actual con modelos —aunque sean heurísticos— del estado resultante. En automatización de procesos, eso puede incluir:
- conteos y totales esperados tras una importación;
- registros que quedarían huérfanos o duplicados;
- tiempos de procesamiento estimados a partir de muestras;
- dependencias externas que cambiarían de estado;
- excepciones previsibles según reglas de negocio.
La proyección no tiene que ser perfecta. Debe ser suficientemente explícita para que una persona —o un agente con supervisión— pueda decidir si el riesgo es aceptable.
Gate: decidir con evidencia acumulada
El diagrama de este artículo muestra un gate entre la proyección y la ejecución. Ese gate no es un flag más en un script: es el punto donde convergen preflight, rehearsal y forecast. Solo cuando la evidencia acumulada es legible tiene sentido autorizar la mutación.
En flujos agénticos, el gate adquiere especial importancia. Un agente puede generar forecasts rápidamente, pero la autorización de mutación debe referirse a un alcance concreto y a proyecciones revisables, no a una intención difusa.
Relación con Rehearsal Pattern
El Rehearsal Pattern separa observación, ensayo, validación, aprobación, mutación acotada y verificación. El forecast encaja antes de la aprobación final, cuando ya se dispone de evidencia de ensayo pero aún falta evaluar consecuencias.
Rehearsal responde: «¿puedo ejecutar este mecanismo con seguridad procedimental?». Forecast responde: «¿qué estado dejará el sistema si lo hago?». Son complementarios, no redundantes.
Caso concreto: Billing / Invoices
El proyecto Billing / Invoices ilustra por qué el forecast importa en un dominio real. Procesar facturas implica OCR, validación, aprobación y contabilización. Un rehearsal puede verificar que Playwright navega el flujo; un forecast debe estimar cuántas excepciones aparecerán, qué registros quedarán pendientes y qué integraciones downstream recibirán carga.
Sin forecast, es fácil confundir «el script terminó bien» con «el proceso de negocio convergió bien».
Límites
Forecast no garantiza corrección del modelo ni ausencia de sorpresas. Un estado no contemplado, un cambio concurrente o una regla de negocio mal especificada pueden invalidar la proyección. Tampoco sustituye permisos mínimos, rollback planificado ni observabilidad posterior.
Su aportación es más modesta y más valiosa: convertir una mutación opaca en una decisión informada sobre estados futuros, no solo sobre la forma de ejecutar.