Una revisión que recuerda hallazgos necesita distinguir corrección, supresión y desplazamiento del problema

Cerrar no es sinónimo de resolver. Una interfaz de revisión puede mostrar un comentario como resuelto por muchas razones. El código cambió y eliminó la causa; una persona decidió aceptar el riesgo; el detector estaba equivocado; el problema se movió a otro archivo; o simplemente una nueva revisión ya no lo encontró. Si todos esos casos terminan en el mismo estado visual, el historial pierde valor. La mejora de GitHub al registrar razones de resolución apunta en la dirección correcta. Para cualquier agente revisor, la semántica de la transición importa tanto como el estado final porque define qué aprendemos de ese episodio.

La supresión humana debe sobrevivir a la siguiente ejecución. Cuando una persona responde que un hallazgo debe permanecer abierto o que un riesgo se acepta temporalmente, esa decisión necesita persistencia y alcance. Si el agente vuelve a evaluar desde cero, puede reabrir lo descartado o cerrar lo que el usuario pidió conservar. Ambos comportamientos erosionan confianza. Conviene representar excepciones como objetos con autor, motivo, fecha, expiración y contexto. Una excepción puede valer para un archivo, una regla, una versión o una ventana de tiempo. La memoria correcta no recuerda solo texto; recuerda decisiones de gobernanza que modifican cómo interpretar futuras evidencias.

El desplazamiento es el caso más traicionero. Un defecto puede desaparecer de la línea original porque una función fue movida, copiada o reescrita, mientras la condición peligrosa persiste en otro lugar. Un revisor superficial concluye que la alerta se resolvió porque el diff ya no coincide. Para evitarlo, el sistema necesita asociar el hallazgo a una propiedad o comportamiento además de a coordenadas. En código puede usar símbolos, dataflow y pruebas; en documentos puede usar claims y fuentes; en campañas, activos y restricciones. La identidad del problema debe resistir cierto grado de transformación del artefacto.

Los hallazgos tardíos necesitan una categoría propia. Una revisión posterior puede encontrar algo que ya existía desde antes. Etiquetarlo como “nuevo” culpa al cambio equivocado y distorsiona métricas de calidad. GitHub separa problemas previamente omitidos, un patrón que puede trasladarse a otros dominios. Un agente de compliance puede detectar hoy una condición presente desde hace meses. El registro debería distinguir fecha probable de introducción de fecha de detección. Esa diferencia permite mejorar el detector sin confundir su aprendizaje con un deterioro reciente del sistema y evita que el equipo persiga causas inexistentes en el último cambio.

El historial es una fuente de evaluación. Cuando cada transición tiene causa, el ledger permite evaluar al revisor. Podemos medir cuántos hallazgos terminaron como incorrectos, cuántos fueron aceptados sin cambio, cuántos reaparecieron y cuántos fixes generaron regresiones. También podemos comparar versiones del agente sobre casos históricos. Esa información es más valiosa que un benchmark estático porque refleja el contexto real de la organización. Un revisor que aprende de sus propios estados puede ajustar umbrales por tipo de riesgo y reconocer reglas que sistemáticamente producen ruido sin eliminar la evidencia necesaria para auditar su evolución.

Aplicación en Goatify. Goatify debería representar cada observación crítica como un objeto versionado con estado y razón: open, fixed, acceptedrisk, incorrect, moved, expired o superseded, por ejemplo. La interfaz puede simplificar esas categorías para el usuario, pero el runtime necesita conservarlas. Así un agente de revisión de contenido, automatizaciones o campañas puede continuar entre ejecuciones sin repetir conversaciones. También permite construir un reporte honesto: no solo cuántos problemas desaparecieron, sino cómo. Esa transparencia evita el incentivo de “mejorar” un dashboard silenciando alertas y convierte la memoria de revisión en una herramienta de gobierno.