Cada workspace guarda un rastro de las acciones que cambian quién puede hacer qué. Se escribe una vez, nunca se edita, y se poda a los 90 días.

Qué se registra

Roles: creados, modificados, borrados. Una modificación lleva un diff: qué permisos se añadieron, cuáles se quitaron, y si cambiaron nombre, descripción, color o la marca de predeterminado.
Personas: añadidas, con el rol que recibieron, retiradas, cambio de rol, cambio de estado, y permisos limitados a páginas concedidos o revocados. Cuando alguien sale de un workspace por su cuenta se registra como una retirada, con esa persona como su propio autor.
Tokens: creados y revocados, incluidos los tokens de recurso que firman medios privados.
El workspace: ajustes modificados y regeneración del secreto de borradores.
Endpoints de webhook: creados, modificados, borrados, secreto rotado y una entrega guardada reenviada. Una modificación lleva a dónde apuntaba la URL antes, qué eventos se añadieron o se quitaron y si el endpoint se desactivó. Una rotación lleva la ventana de gracia en la que el secreto anterior sigue firmando: sin gracia, toda entrega falla hasta que el consumidor despliega de nuevo. Un endpoint que el worker de entrega desactiva tras veinte entregas fallidas consecutivas también se registra, como su propia acción con el contador de fallos: nunca como la edición de alguien.
Publicación de una página: publicada, despublicada, un borrador descartado, un diseño publicado, un borrador de diseño descartado, un borrador de desarrollo promovido, y un cambio de etapa editorial. La publicación es el momento en que un cambio se hace visible al público, así que pertenece aquí aunque la edición que lo produjo no pertenezca. Una publicación de diseño es una acción propia: cambia lo que la página muestra sin ponerla en línea.
Borrados: una página, y cuántas páginas hijas se fueron con ella; un bloqueo de página tomado a quien lo tenía; un modelo, y cuántos registros se fueron con él; un registro suelto; un borrado masivo de productos, con el número y si la selección se hizo por identificadores o por un filtro; un formulario, y cuántos envíos se fueron con él; y un envío suelto. Una entrada de envío nombra el formulario, su estado y cuándo llegó: nunca lo que escribió el visitante. El registro de auditoría se lee con un permiso distinto del de los envíos, así que repetir ahí las respuestas se las entregaría a alguien que no puede abrir la bandeja.

Cada entrada nombra el objeto, el momento y quién actuó: una persona, o la propia plataforma cuando actuó por su cuenta, por ejemplo un endpoint de webhook desactivado por fallos repetidos.

Cada entrada dice de dónde vino la escritura. Un cambio hecho en la administración no lleva origen alguno. Un cambio hecho por el asistente de IA se marca como tal y nombra la herramienta que usó; un cambio hecho a través del servidor MCP se marca como esa superficie. La acción es la misma en ambos casos -una publicación del asistente es la misma entrada publicada que escribe una persona-, así que el rastro se lee como una sola historia y luego se estrecha a las escrituras de máquina cuando esa es la pregunta. El autor sigue siendo la persona cuyo token ejecutó el cambio: el asistente actúa en nombre de alguien, nunca en el suyo.

La organización lleva su propio registro

Una organización es la propietaria del plan, de los asientos y de la configuración de inicio de sesión único. Esos eventos no pertenecen a ningún workspace en concreto, así que se escriben en un rastro aparte, con su propio permiso de lectura. Esa separación es lo que mantiene honesto al registro del workspace: una entrada ahí siempre nombra un workspace, y un evento de organización no tiene ninguno que nombrar.

Se registra en la organización:

La organización misma: creada, renombrada, borrada, ajustes modificados. Un renombrado lleva si se movió el nombre, el slug o ambos; un cambio de ajustes lleva el nuevo rol por defecto de los miembros y si los miembros pueden crear workspaces propios.
La propiedad: transferida, nombrando a quien la entregó y a quien la recibió.
Los asientos: alguien invitado, con el rol de organización que se le ofreció; una invitación cancelada; una invitación aceptada; un miembro retirado; el rol de organización de un miembro cambiado. Son las entradas sobre las que gira una disputa por un asiento, y el asiento es la unidad en la que se cuenta el plan.
Los workspaces: movidos a la organización o fuera de ella, nombrando ambos lados del movimiento.
Inicio de sesión único: un dominio añadido, verificado o retirado, la conexión configurada, una conexión de prueba con su resultado, y la obligatoriedad activada o desactivada. Esa decide quién puede seguir entrando con contraseña, así que se registra como una acción propia y no como un cambio de ajustes más.

El rol de organización -propietario, administrador o miembro- es otra cosa que el rol de workspace que concede permisos dentro de un workspace. Un cambio en uno nunca se registra como un cambio en el otro, y los dos rastros no mezclan sus vocabularios.

Una acción que no cambió nada no escribe nada. Guardar el formulario de ajustes sin tocar un campo, o poner a un miembro el rol que ya tiene, no deja entrada: un rastro relleno de no-eventos es un rastro que nadie lee.

Qué no está, y por qué

Las ediciones de contenido no están en el registro de auditoría. Ni guardados de página, ni retoques de bloque, ni subidas de medios.

La publicación y el borrado son las dos excepciones, y ambas están en la lista de arriba. La línea no va entre «contenido» y «acceso», sino entre recuperable y no. Una edición de borrador es reversible y privada, así que queda fuera. El momento en que el contenido se hace público se registra, y también el momento en que deja de existir: un borrado es la única operación de contenido que nada más puede responder después, porque aquello por lo que alguien preguntaría ya no está.

Es una línea deliberada, no un descuido. Esos eventos son de alto volumen -una tarde ajetreada produce cientos- y mezclarlos enterraría las quince entradas que importan bajo miles que no. El registro de auditoría responde a «¿quién cambió los accesos?»; para «¿quién cambió esta página?» está el historial de versiones, que registra cada guardado con su autor.

La regla detrás de la lista: cubre lo que afecta a la confianza, la autenticación y la facturación, y aquello sobre lo que un atacante querría borrar sus huellas.

Quién puede leerlo

El registro del workspace exige el permiso de gestionar roles. Es intencionado: el registro es en gran parte un historial de cambios de permisos, así que quienes pueden conceder acceso son quienes ven quién lo concedió.

El registro de la organización exige gestionar la organización: ser su propietario o tener su rol de administrador. El permiso del workspace no llega hasta ahí. Alguien que puede gestionar roles dentro de un workspace no tiene derecho al historial de quién fue invitado a la organización que está por encima, y tener ese permiso en todos los workspaces que la organización posee sigue sin abrirlo.

Noventa días

Las entradas más antiguas las poda un trabajo programado, que barre los dos rastros en la misma pasada. Si tus obligaciones de conservación son mayores, exporta lo que necesites de forma periódica en lugar de descubrir el hueco durante una auditoría.

Una entrada sobrevive a su sujeto a propósito: borrar una organización se registra, y ese registro no se borra con ella. Caduca con todo lo demás cuando pasan los noventa días.

Siguientes pasos

Miembros y roles: los permisos cuyos cambios aterrizan aquí.
Tokens de API: creación y revocación, ambas registradas.
Webhooks: los endpoints cuyos cambios se registran aquí.
Inicio de sesión único: dominios, configuración y obligatoriedad, todo registrado en la organización.
Historial de versiones: el rastro de contenido que este registro deja fuera a propósito.