Trazabilidad de extremo a extremo

COADF P-4 se publica íntegro. Al recibir un documento se crea un identificador que viaja con cada paso de procesamiento, cada evaluación de confianza, cada decisión humana y la salida publicada. La traza es de solo inserción, una consulta reconstruye la cadena y la cadena se exporta como JSON para alguien que no construyó el sistema. El esquema publicado de la traza de auditoría nombra los campos: trace_id, timestamp, event_type, actor, input, output, decision, source_hash e immutable.

Dos propiedades la sostienen. Continuidad: cada paso lleva la misma identidad, a través de cada frontera que cruza. Persistencia: el registro de cada paso sobrevive, y nadie puede editarlo después para que la respuesta parezca mejor.

La pregunta que responde P-4 llega tarde y desde fuera. Meses después de la publicación alguien pregunta de dónde salió un valor, qué lo leyó y quién lo miró. La respuesta tiene que poder reconstruirla una persona que no construyó el sistema, a partir de registros que nadie pudo reescribir entretanto.

Una traza distribuida no es una traza de auditoría de negocio

Es la distinción que más implementaciones difuminan, porque las herramientas se parecen: ambas tienen un identificador, ambas cruzan servicios, ambas muestran pasos en secuencia. Responden a preguntas distintas y prometen cosas distintas.

La especificación W3C Trace Context define la cabecera traceparent, y los SDK de OpenTelemetry propagan tracecontext y baggage por defecto. Esa identidad es por ejecución. En OpenTelemetry, una traza que no se muestrea no se exporta, y el procesador de filtrado del Collector descarta la telemetría que cumple una condición. Ambos son comportamientos correctos para el diagnóstico y descalificantes para la evidencia.

Las dos se correlacionan: se registra el trace_id de auditoría en cada span como atributo, y el identificador de la traza distribuida en los logs. Ninguna debe convertirse en la otra. Una sola transacción de negocio abarca habitualmente varias trazas distribuidas: una petición de recepción, una tarea de procesamiento asíncrona, una decisión tomada días después, la salida.

La correlación copia el identificador de auditoría en la telemetría, y la telemetría cruza otras fronteras: exportadores, proveedores, reglas de acceso y plazos de conservación que suelen ser más laxos que los del almacén de auditoría. Hay que clasificar el identificador antes de que salga: una referencia opaca, nunca datos personales ni un secreto. Donde el identificador de auditoría tenga significado propio, la correlación se hace mediante una referencia separada y no sensible.

Crear una sola vez, en la recepción

El identificador se crea donde entra la transacción y en ningún otro sitio. Todo componente posterior lo exige y ninguno lo genera. Un identificador ausente es un error, nunca un motivo para crear uno nuevo, y un valor por defecto en un modelo de mensaje es la forma más común de romper esa regla sin que nadie lo note.

Transportarlo de forma explícita a través de cada frontera

• Dentro del proceso: un argumento de función o el contexto de la petición.
• Entre servicios: un campo del contrato de la petición o del mensaje, donde un esquema puede exigirlo.
• En el trabajo programado: un argumento de la tarea.
• En reposo: una columna en cada fila almacenada.

Las bibliotecas de propagación transportan por su cuenta el contexto de ejecución. La identidad de auditoría forma parte del contrato propio y pertenece a la carga útil.

Persistir, solo inserción

Hay varias realizaciones válidas, y se combinan:

• Persistencia de solo inserción. El repositorio ofrece añadir y leer, y nada más.
• Privilegios de base de datos. El rol de la aplicación tiene INSERT y SELECT sobre la traza, y no UPDATE, DELETE ni TRUNCATE.
• Triggers que rechazan reescrituras, como defensa en profundidad para las sesiones que sí tienen derechos más amplios, con un trigger a nivel de sentencia para TRUNCATE, porque en PostgreSQL TRUNCATE no dispara los triggers ON DELETE.
• Un modelo de eventos inmutable, en el que una corrección es un evento nuevo que sustituye a uno anterior.
• Una convención de sustitución. El valor vigente de un atributo es su última entrada; el historial son todas.

El event sourcing es una manera de obtener un historial de solo inserción, y no la única; véase la nota técnica.

Escribir la entrada con el cambio

La entrada de auditoría se registra en la misma transacción de base de datos que el cambio de estado que describe, o mediante un outbox transaccional, de modo que ninguno de los dos pueda existir sin el otro.

Hacer idempotentes los reintentos

La hora del paso se fija cuando el paso se ejecuta, y en un reintento se reenvía la misma entrada. Las entradas llevan una clave única natural para que una escritura repetida se absorba en lugar de duplicarse. En PostgreSQL, ON CONFLICT DO NOTHING omite una fila que entra en conflicto con una restricción o un índice únicos en lugar de lanzar un error, y justo por eso no puede ser toda la respuesta: un conflicto no siempre es un reintento. La misma clave con otro contenido es un segundo escritor o un error. Hay que comparar la entrada almacenada antes de llamar reintento a la escritura, y fallar de forma visible cuando difiere.

Reconstruir con una consulta, exportar como JSON

Si la reconstrucción necesita a alguien que conozca el sistema, P-4 no se cumple. Se ordena por marca de tiempo, y se dice lo que ese orden no resuelve: las entradas con la misma marca de tiempo no quedan ordenadas por ninguno de los campos publicados.

Lo que un trigger no da

Los privilegios y los triggers son controles dentro de la propia frontera de confianza de la base de datos. En PostgreSQL, un superusuario omite todas las comprobaciones de permisos, y el propietario de la tabla puede desactivar sus triggers. Una tabla de solo inserción es, por tanto, un control fuerte frente a la aplicación y uno débil frente a sus administradores. Hacer detectable la manipulación por parte de personas internas con privilegios necesita un control fuera de la base de datos, y es una propiedad distinta de la persistencia de solo inserción. Ninguna de las dos es, por sí sola, una afirmación jurídica sobre la evidencia.

• Event sourcing. El almacén de eventos es el historial y el estado se deriva de él. Propiedades de auditoría sólidas, y un compromiso de arquitectura grande.
• Captura de cambios de datos. Cambios de filas leídos del log de la base de datos. Útil para la replicación; registra qué cambió, no quién decidió ni por qué, así que no sustituye las entradas de auditoría de negocio.
• Almacenamiento de objetos de escritura única para las cadenas exportadas, donde la conservación tiene que durar más que la base de datos.
• Almacenes de tipo libro mayor o que hacen detectable la manipulación, donde la manipulación por personas internas forma parte del modelo de amenazas.

• El patrón no decide qué pasos son relevantes para una regulación concreta o un producto concreto.
• La persistencia de solo inserción no equivale a detectabilidad de manipulaciones, y ninguna de las dos es una conclusión jurídica sobre la evidencia.
• No define plazos de conservación.
• Depende de que cada componente respete el contrato. Un componente que no lo hace lo detecta la prueba de reconstrucción; no lo impide.