Una auditoría no es un problema de búsqueda. La dificultad del auditor rara vez está en encontrar un documento: está en saber cuál era la población, si el registro se movió mientras lo leía, y en poder demostrar después qué examinó.

KF está construido para que esas tres preguntas tengan respuesta.

La vista de auditoría

/audit?id= reúne en una sola página lo que, de otro modo, un auditor tendría que conocer KF lo bastante bien como para ir a componer a mano.

Procedencia. Qué base de datos es esta, cuántos ítems, aristas y revisiones contiene, cuándo se escribió por última vez y cuál es la revisión de la configuración. Anótelo en el plan de auditoría. Cualquier edición de la biblioteca de requisitos durante el periodo auditado es en sí misma un hallazgo, y esto es lo que permite comprobarlo.

El registro, cuadrado. Requisitos, filas, encabezados y lo acumulado por debajo — con la aritmética comprobada y mostrada como una insignia. Véase el registro de cumplimiento.

Cambios recientes, y la nota de que añadiendo &since=AAAA-MM-DD se convierte en un informe de deriva respecto a la reunión de apertura.

Hallazgos ya registrados, contados por grado: mayor, menor, observación.

Una lectura estable

La base de datos está viva. Puede que alguien esté escribiendo en ella mientras se desarrolla la auditoría, lo que significa que la misma pregunta hecha dos veces puede dar honestamente dos respuestas distintas.

Toda lectura puede fijarse a un instante — as_of en la API y en el endpoint MCP, y una fecha en la interfaz web. Fíjela a la reunión de apertura y dos preguntas idénticas separadas por horas coincidirán. Cuando una página muestra historia y no el presente, lo advierte en un banner que no se puede descartar: un auditor que no se da cuenta de que está leyendo el registro del mes pasado está peor que uno que no puede leerlo.

Demostrar qué se examinó

KF mantiene un diario de solo-anexado de quién leyó qué, cuándo, por qué ruta, con qué argumentos y cuánto se devolvió.

Dos decisiones sobre ese diario merecen conocerse:

Se escribe al lado de la base de datos, no como una tabla dentro de ella. La superficie MCP es de solo lectura por diseño, y una herramienta de lectura que escribiera calladamente una fila en el almacén de la propia organización rompería esa promesa.

Registra cobertura, no contenido — lo suficiente para reconstruir qué se examinó, y deliberadamente no las respuestas. Registrarlas crearía una segunda copia de los registros del auditado en un lugar con menos protección que el original.

GET /api/audit-trail lo devuelve.

Toda exportación lleva su procedencia

El expediente de un auditor tiene que seguir teniendo sentido meses después, para alguien que no estuvo allí. Toda exportación — el registro en CSV o Excel, cualquier listado en CSV, el AMFE en ambos — lleva una cabecera que nombra la base de datos, la compilación, el filtro que la produjo y la hora en que se tomó.

La guía viaja con el producto

Un auditor externo llega con acceso de lectura y sin conocimiento de KF. Enviarle un PDF por correo tiene la forma equivocada: la guía tiene que estar donde él ya está.

Por eso se sirve desde dentro de la instancia en ejecución, en /info/audit, junto a la evidencia — además de una lista de comprobación del encargo en

/info/audit-checklist que cubre acceso, procedencia, criterios, confidencialidad y los compromisos de método que hay que cerrar antes de la reunión de apertura.

Revisiones

Se conserva cada revisión de cada ítem, con el autor, la hora y lo que el autor dijo que cambiaba. Cualquier revisión puede leerse por separado, y diff muestra una frente a la anterior — que es lo que hace que el mensaje de versión sea comprobable y no solamente esté presente.