Observación de antecedentes incompletos

1. Objetivo

Establecer el procedimiento que sigue la organización cuando detecta que el expediente de admisión de un solicitante presenta antecedentes incompletos: registrar el estado, comunicar al solicitante con claridad qué debe aportar y en qué plazo, y hacer seguimiento hasta resolución.

2. Alcance

Cubre desde que Admisión detecta la incompletitud hasta que el expediente vuelve a estar completo o se cierra por abandono o rechazo.

No cubre:

• La revisión inicial de admisibilidad documental, que es materia de [[wiki/entities/dispensai/protocolos/ADM-002]].
• La validación de identidad, que es materia de [[wiki/entities/dispensai/protocolos/ADM-003]].
• El rechazo fundado cuando la organización decide no admitir, que es materia de [[wiki/entities/dispensai/protocolos/ADM-008]].
• El seguimiento de casos observados una vez cerrada la ventana de subsanación, que es materia de [[wiki/entities/dispensai/protocolos/ATN-006]].

3. Definiciones

Antecedente incompleto. Un documento o dato que el protocolo de admisión exige y que está ausente, ilegible, vencido o inconsistente con otros documentos del expediente.

Caso observado. Un expediente en el que se detectó al menos un antecedente incompleto y cuya resolución está pendiente de acción del solicitante.

Plazo de subsanación. El período máximo que la organización otorga al solicitante para aportar el antecedente faltante. Su duración es definida por la organización en su reglamento interno.

Abandono. La situación en que el solicitante no subsana dentro del plazo sin dar aviso. El expediente puede cerrarse por esta causal sin constituir un rechazo fundado.

4. Roles y responsables

Rol	Responsabilidad
Admisión	Detectar la incompletitud, registrar el estado, comunicar al solicitante y hacer seguimiento
Solicitante	Aportar el antecedente faltante dentro del plazo
Admin	Ejecutar el cambio de estado en el sistema y registrar el motivo de la observación
Comité de revisión interna	Resolver los casos en que la incompletitud no puede subsanarse y debe derivar a rechazo

5. Disparador de inicio

Admisión revisa el expediente de un solicitante y detecta que uno o más antecedentes exigidos están ausentes, ilegibles, vencidos o inconsistentes.

6. Requisitos previos

• El expediente existe en el sistema con approval_status en pending o pending_interview.
• Admisión tiene identificado con precisión qué antecedente falta y por qué.
• La organización tiene definido un plazo de subsanación en su reglamento interno.

7. Entradas

• Expediente del solicitante con al menos un antecedente incompleto.
• Descripción del antecedente faltante y del motivo de la incompletitud.
• Plazo de subsanación vigente según el reglamento interno.

8. Procedimiento paso a paso

1. Identificación de la incompletitud. Admisión revisa el expediente en /admin/usuarios/{id} y determina con precisión qué antecedente falta, por qué y qué debe aportar el solicitante para subsanarlo.
2. Registro del estado de observación. Admin cambia approval_status a pending_interview en el sistema, que es el valor disponible más cercano al estado observado. El sistema registra el cambio de estado con el evento user_status_changed.
3. Registro del motivo. Admisión documenta qué antecedente falta y el plazo otorgado. Este registro es hoy un paso humano: el sistema no tiene campo específico para el motivo de la observación ni para el plazo. Ver brecha B1 en §17.
4. Comunicación al solicitante. Admisión notifica al solicitante qué debe aportar y en qué plazo. El canal puede ser email directo, mensaje en la plataforma u otro medio habilitado por la organización. Ver brecha B2 en §17.
5. Seguimiento. Admisión verifica periódicamente si el solicitante aportó el antecedente.
6. Resolución. Una vez subsanado el antecedente, el expediente vuelve al flujo de admisión normal según [[wiki/entities/dispensai/protocolos/ADM-002]] y [[wiki/entities/dispensai/protocolos/ADM-009]]. Si el plazo vence sin subsanación, el caso puede cerrarse por abandono o derivarse a rechazo según [[wiki/entities/dispensai/protocolos/ADM-008]].

9. Puntos de control

#	Control	Qué impide
C1	El approval_status del expediente es pending_interview mientras no se subsane	Que el expediente avance sin los antecedentes completos
C2	El cambio de estado genera evento user_status_changed	Que no quede rastro del momento en que se detectó la incompletitud
C3	Comunicación documentada al solicitante con descripción del antecedente faltante	Que el solicitante no sepa qué debe subsanar
C4	Plazo de subsanación definido y comunicado	Que el caso quede paralizado indefinidamente

10. Criterios de decisión

Caso subsanado: el solicitante aportó el antecedente faltante y Admisión lo valida como conforme. El expediente vuelve al flujo de revisión.

Caso abandonado: el plazo venció sin respuesta ni acción del solicitante. El expediente puede cerrarse sin que constituya un rechazo fundado, siempre que conste la comunicación previa.

Deriva a rechazo: la incompletitud no puede subsanarse (el antecedente no existe, es falsificado o resulta incompatible con los requisitos de la organización). Se aplica [[wiki/entities/dispensai/protocolos/ADM-008]].

11. Excepciones y escalamiento

• El solicitante alega no haber recibido la comunicación. Admisión acredita la fecha y el canal de comunicación. Si hay duda, se reitera con acuse de recibo.
• El antecedente faltante depende de un tercero. La organización puede conceder una prórroga documentada.
• El caso es recurrente. Si el mismo solicitante presenta reiteradamente expedientes incompletos, el Comité de revisión interna evalúa si corresponde rechazar la solicitud por incapacidad de cumplir los requisitos.

12. Registros generados

Registro	Contenido
Evento user_status_changed	Estado anterior, estado nuevo (pending_interview), responsable, fecha
Registro del motivo	Hoy es un registro humano externo al sistema (correo, nota, acta)
Comunicación al solicitante	app/actions/interviews.ts:262 — sendInterviewPendingEmail cuando la transición viene del flujo de entrevista. Si el estado se cambia directo desde users.ts, no hay notificación automática.

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Latencia de comunicación	Fecha de comunicación al solicitante − fecha de detección de incompletitud	≤ 1 día hábil	Registro humano
Tasa de subsanación en plazo	Casos subsanados dentro del plazo ÷ total de casos observados	Seguimiento, sin meta	Expediente
Tasa de abandono	Casos cerrados por abandono ÷ total de casos observados	Seguimiento, sin meta	Expediente

14. Riesgos y controles

Riesgo	Control	Tipo
Caso paralizado sin comunicación	Plazo de subsanación definido y registro de comunicación (C3, C4)	Preventivo
Avance del expediente sin subsanar	Estado pending_interview mientras no se resuelva (C1)	Preventivo
No poder acreditar cuándo se detectó la incompletitud	Evento user_status_changed con fecha (C2)	Detectivo
Comunicación sin registro verificable	Uso de canal con acuse de recibo o registro interno	Preventivo

15. Normativa y referencias

Norma	Referencia	Qué cubre en este protocolo
Ley 20.500	Incorporación de asociados	La organización establece requisitos de ingreso y puede pedir su completitud
Ley 21.719	Art. 13	La subsanación puede implicar aporte de datos adicionales; base de licitud contractual
ISO 9001:2015	§8.2	Los requisitos del servicio se revisan antes de aceptar y deben estar completos
ISO 9001:2015	§8.5.1	La provisión del servicio es controlada; un expediente incompleto no avanza

El cumplimiento de estas normas no está certificado por ninguna autoridad. Este protocolo declara qué controles ejecuta la organización, no que un tercero los haya auditado.

16. Anexos y formularios vinculados

• Admisibilidad documental ([[wiki/entities/dispensai/protocolos/ADM-002]])
• Validación de identidad ([[wiki/entities/dispensai/protocolos/ADM-003]])
• Rechazo fundado ([[wiki/entities/dispensai/protocolos/ADM-008]])
• Seguimiento de casos observados ([[wiki/entities/dispensai/protocolos/ATN-006]])

17. Implementación en el sistema

El protocolo tiene implementación parcial. El sistema registra el cambio de estado y permite al administrador ver el expediente. Lo que no hace es modelar el motivo de la observación, el plazo ni la notificación al solicitante.

Elemento del protocolo	Dónde vive
Estado pending_interview (paso 2)	profiles.approval_status — CHECK IN ('pending', 'pending_interview', 'approved', 'rejected'), supabase/migrations/20240101000000_baseline_schema.sql:44
Cambio de estado (paso 2)	app/actions/users.ts — función central de actualización de estado; usa createClient() con sesión admin
Evento de cambio de estado (C2)	app/actions/users.ts — logISOSystemEvent("user_status_changed", ...) con old_status, new_status, source
Vista del expediente (paso 1)	app/admin/usuarios/[id]/page.tsx — panel de administración del expediente

Brechas conocidas:

1. No existe estado observed ni campo para el motivo de la observación. El valor pending_interview es el que más se acerca, pero no distingue entre “a la espera de entrevista” y “expediente con antecedentes incompletos”. No existe un campo observation_reason ni missing_documents en profiles. El motivo de la observación se registra hoy en medios externos al sistema (correo, nota, acta); no hay rastro en el expediente digital.
2. La notificación para pending_interview existe solo vía el flujo de creación de entrevista. La función sendInterviewPendingEmail se importa en app/actions/interviews.ts:10 y se llama en interviews.ts:262 cuando la transición a pending_interview ocurre por creación de una entrevista. Si Admin cambia el estado directamente desde app/actions/users.ts sin crear una entrevista, no existe notificación automática al solicitante. El canal de comunicación queda a cargo del operador en ese caso.
3. El plazo de subsanación no está modelado en el sistema. No existe columna observation_due_at ni mecanismo de alerta por vencimiento. El seguimiento depende enteramente de la atención de Admisión.
4. El evento user_status_changed es best-effort. El bloque de registro ISO está dentro de try/catch; si falla, el cambio de estado ya ocurrió y no queda el rastro del evento. El control C2 depende de que el registro no falle.

Lo que ejecuta la organización fuera del sistema: la identificación de qué antecedente falta y el contacto con el solicitante son pasos humanos. No son defectos del software; son pasos que este protocolo reconoce como tales y que deben quedar documentados por otros medios mientras la brecha B1 y B2 estén abiertas.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-28	Versión inicial. Redactada desde la corrida de evidencia 2026-08-28-ADM-resto. Cuatro brechas declaradas.	Admisión
1.1	2026-08-29	Brecha B2 corregida: sendInterviewPendingEmail sí existe (app/actions/interviews.ts:262) y se llama cuando la transición a pending_interview pasa por el flujo de entrevista. La brecha real es que el cambio directo de estado desde users.ts no dispara la notificación. CHECK de approval_status confirmado en 20240101000000_baseline_schema.sql:44. Protocolo ascendido a Vigente.	Admisión