> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Revisión de cuatro ojos: aprobación maker/checker > Didit exige que un segundo responsable apruebe o rechace cada resolución de un blueprint; el resultado queda pendiente hasta que otro revisor lo valide. La revisión a 4 ojos añade una segunda aprobación independiente antes de que una resolución surta efecto. Es un control estándar de segregación de funciones para las investigaciones de mayor riesgo. *** ## Configuración En el blueprint del creador (maker), asigna un **checker blueprint** en **4-eyes review**. Configurar este campo es lo que activa la revisión a 4 ojos en el blueprint del creador; no existe un interruptor aparte. ## Cómo funciona 1. Un analista del blueprint del creador resuelve un caso como de costumbre (falso positivo o amenaza válida, además de una nota si es obligatoria). 2. En lugar de cerrarse, el caso permanece en estado **Open**, la resolución propuesta queda en espera y el caso pasa a la cola del **checker blueprint's**. La cronología del caso registra `Submitted for approval`. 3. Un verificador revisa la pestaña Resumen del caso, donde un banner de doble control muestra las acciones **Aprobar** y **Rechazar**. 4. **Aprobar** aplica la resolución en espera: el caso pasa a **Resolved** con la resolución y la nota originales, atribuidas al analista que la envió. La cronología registra `Approval granted` y luego `Resolved`. 5. **Rechazar** descarta la resolución en espera y devuelve el caso al **maker blueprint**. La cronología registra `Approval rejected` y se notifica al creador. > [!WARNING] > > El analista que envió la resolución no puede aprobarla ni rechazarla, algo que se impone del lado del servidor. Intentarlo devuelve un 403. (Aprobar o rechazar un caso sin ninguna resolución pendiente de aprobación devuelve un 409). ## Designar al verificador El analista que resuelve puede designar al miembro que debe aprobar la resolución mediante el campo `checker` de la [API de resolución de casos](https://docs.didit.me/es/management-api/cases/resolve.md). A partir de ese momento, solo ese miembro puede aprobarla o rechazarla; cualquier otra persona, incluida una clave de API, recibe un 403. El campo `checker` del caso muestra al miembro designado hasta que la resolución se aprueba, se rechaza o se devuelve para una nueva revisión. Si no se designa un verificador, la resolución espera en la cola del blueprint del verificador como se describe arriba. El verificador designado debe tener acceso a los casos de la aplicación y no puede ser el analista que envió la resolución. ## Cuando cambia la evidencia Cambiar una respuesta de la checklist, o añadir o eliminar una verificación o transacción vinculada, descarta la decisión pendiente y devuelve el caso a su política de revisión original. La cronología de actividad registra que se requiere una nueva decisión de revisión y conserva la propuesta anterior en el evento de auditoría. El revisor debe examinar la evidencia actualizada y enviar una nueva decisión antes de que un segundo responsable pueda aprobarla. Repetir la misma respuesta de la checklist no cancela una revisión pendiente. La aprobación también compara la evidencia de origen vinculada con lo que se envió a revisión. Un cambio en el estado de una verificación, un campo corregido de un documento, un cambio en la evidencia de una transacción o una fuente no disponible bloquean la aprobación con `409`. Perder el acceso a la evidencia de la red global vinculada a través de un Fraud Check también exige una nueva revisión. Usa **Rechazar** para devolver el caso a su creador, revisar la evidencia actualizada y enviar una nueva decisión. Abrir el registro de origen o añadir una nota interna al caso no bloquea por sí solo una revisión sin cambios. Si no se puede verificar la evidencia enviada, se requiere una nueva revisión antes de la aprobación. ## Notas * Los requisitos de revisión se guardan al abrir el caso. Pasar a la cola del verificador no sustituye esos requisitos por cambios posteriores en la política. * Un caso solo puede tener una resolución preparada a la vez; solicitar más información (**En espera del usuario**) está bloqueado mientras haya una resolución pendiente de aprobación. * La revisión a 4 ojos se combina con las [notas de resolución obligatorias](https://docs.didit.me/es/console/case-management/blueprints.md#configuración-general): activa ambas en tus blueprints de mayor riesgo para exigir tanto una justificación documentada como un segundo revisor. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.