> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gu1.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Contexto y standby

> event.data compartido, refresco al reanudar, límites del standby y patrones KYC — en el motor de automatizaciones gu1 con disparadores y acciones.

## Contexto compartido (`event.data`)

Todos los pasos de una misma ejecución comparten un único objeto de **contexto**. El motor fusiona:

* **Objetos anidados** alineados con filas de BD: `entity`, `transaction`, `investigation`, `kyc`, `alert` (y a veces `alerts[]`).
* **IDs planos** por compatibilidad: `entityId`, `investigationId`, `alertId`, `kycValidationId`, etc.
* **Metadatos de regla** si el trigger es `rule_triggered`: `rule.id`, `rule.name`, `rule.score`, etc.
* **Enriquecimiento y riesgo:** `enrichment`, `riskMatrix`, scores actualizados en `entity` y campos planos.
* **Standby:** con ejecución en pausa, `executionId` y `callbackToken` para enlaces de continuar/cancelar.

Las **condiciones** posteriores ven lo que ya modificaron las **acciones** anteriores en la misma corrida.

## Refresco al reanudar standby

Al **reanudar** tras standby, el motor fusiona el snapshot guardado con un **payload** opcional, ejecuta **`refreshContextForResume`** (vuelve a cargar entidad, transacción, investigación y KYC desde BD) y **preserva** rutas importantes escritas antes (scores, IDs, etc.).

Si el usuario **completó el KYC en el proveedor** mientras el flujo esperaba, los pasos siguientes pueden ver el KYC **actualizado** sin un disparo nuevo: sigue siendo la **misma** ejecución.

## KYC: dos patrones

| Patrón                                    | Qué ocurre                                                                                                                                            |
| ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **A — Misma ejecución (standby)**         | p. ej. `create_kyc_validation` → espera → el usuario hace clic en **Continuar** vía `continueUrl`. Al reanudar se refresca el contexto desde BD.      |
| **B — Nueva automatización al resultado** | Al emitirse `kyc_approved`, `kyc_rejected` o `kyc_validation_finished`, **otras** automatizaciones con esos triggers inician una **nueva** ejecución. |

Se pueden combinar ambos: un flujo con standby para el envío del link y políticas separadas disparadas al resultado final.

## Cuándo el standby sí pausa

Hace falta:

1. Configurar **`waitAfterStep`** (o equivalente en grafo), y
2. Que la corrida pase por **`runAutomationById`** y exista fila en **`automation_executions`** (`executionId`, `callbackToken`).

Caminos típicos: **`POST /automations/:id/run`** (con **`manual_execution`**), **reglas**, **scheduler** (`scheduled`), **flujo de creación de entidad**, etc.

Caminos **solo reactivos** (`alert_created`, `investigation_*`, muchos eventos KYC) usan **`processEvent`** sin ejecución durable: la **espera no pausa**; el flujo termina de una.

## Continuar, cancelar y URLs en plantillas

Con `executionId` y `callbackToken`, las plantillas pueden exponer **`continueUrl`** y **`cancelUrl`**.

Referencia API: [Continuar ejecución](/es/api-reference/automations/continue-execution), [Cancelar ejecución](/es/api-reference/automations/cancel-execution), [Ejecuciones en espera](/es/api-reference/automations/waiting-executions), [Contexto de ejecución](/es/api-reference/automations/execution-context).

## Ejecuciones programadas

Las automatizaciones `scheduled` suelen recibir un contexto de **entidad** acotado. Un reinicio del proceso puede saltar ventanas: tratá como limitación operativa salvo que el despliegue documente recuperación.

***

**Mantenimiento:** el comportamiento de standby está en `automation-engine` y rutas relacionadas.