> ## 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 e standby

> event.data compartilhado, refresh ao retomar, limites do standby e padrões KYC. Consulte o esquema do request, códigos de resposta e autenticação.

## Contexto compartilhado (`event.data`)

Todos os passos de uma mesma execução compartilham um único objeto de **contexto**. O motor mescla:

* **Objetos aninhados** alinhados às linhas do BD: `entity`, `transaction`, `investigation`, `kyc`, `alert` (e às vezes `alerts[]`).
* **IDs planos** por compatibilidade: `entityId`, `investigationId`, `alertId`, `kycValidationId`, etc.
* **Metadados da regra** quando o gatilho é `rule_triggered`: `rule.id`, `rule.name`, `rule.score`, etc.
* **Enriquecimento e risco:** `enrichment`, `riskMatrix`, scores atualizados em `entity` e campos planos.
* **Standby:** com execução pausada, `executionId` e `callbackToken` para links de continuar/cancelar.

**Condições** posteriores veem o que **ações** anteriores já alteraram na mesma execução.

## Refresh ao retomar standby

Ao **retomar** após standby, o motor mescla o snapshot salvo com **payload** opcional, executa **`refreshContextForResume`** (recarrega entidade, transação, investigação e KYC do BD) e **preserva** caminhos importantes escritos antes (scores, IDs, etc.).

Se o usuário **concluiu o KYC no provedor** enquanto o fluxo aguardava, os passos seguintes podem ver o KYC **atualizado** sem novo disparo: ainda é a **mesma** execução.

## KYC: dois padrões

| Padrão                              | O que acontece                                                                                                                                 |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **A — Mesma execução (standby)**    | ex.: `create_kyc_validation` → espera → usuário clica em **Continuar** via `continueUrl`. Ao retomar, o contexto é atualizado a partir do BD.  |
| **B — Nova automação no resultado** | Ao emitir `kyc_approved`, `kyc_rejected` ou `kyc_validation_finished`, **outras** automações com esses gatilhos iniciam uma **nova** execução. |

Ambos podem ser combinados: fluxo com standby para envio do link e políticas separadas disparadas no resultado final.

## Quando o standby realmente pausa

É necessário:

1. Configurar **`waitAfterStep`** (ou equivalente no grafo), e
2. Que a execução passe por **`runAutomationById`** e exista linha em **`automation_executions`** (`executionId`, `callbackToken`).

Caminhos típicos: **`POST /automations/:id/run`** (com **`manual_execution`**), **regras**, **scheduler** (`scheduled`), **fluxo de criação de entidade**, etc.

Caminhos **somente reativos** (`alert_created`, `investigation_*`, muitos eventos KYC) usam **`processEvent`** sem execução durável: a **espera não pausa**; o fluxo termina de uma vez.

## Continuar, cancelar e URLs em templates

Com `executionId` e `callbackToken`, os templates podem expor **`continueUrl`** e **`cancelUrl`**.

Referência da API: [Continuar execução](/pt/api-reference/automations/continue-execution), [Cancelar execução](/pt/api-reference/automations/cancel-execution), [Execuções em espera](/pt/api-reference/automations/waiting-executions), [Contexto da execução](/pt/api-reference/automations/execution-context).

## Execuções agendadas

Automações `scheduled` costumam receber contexto de **entidade** restrito. Reinício de processo pode pular janelas: trate como limitação operacional salvo recuperação documentada no deploy.

***

**Manutenção:** comportamento de standby em `automation-engine` e rotas relacionadas.