Każdy workspace trzyma ślad działań, które zmieniają kto co może. Zapisuje się raz i nigdy nie jest edytowany, a po 90 dniach jest przycinany.

Co jest zapisywane

Role - utworzone, zmienione, usunięte. Zmiana niesie diff: które uprawnienia doszły, które zniknęły i czy zmieniła się nazwa, opis, kolor albo flaga domyślności.
Ludzie - dodani, wraz z rolą, którą otrzymali, usunięci, zmiana roli, zmiana statusu oraz nadanie i cofnięcie uprawnień zawężonych do stron. Wyjście z workspace'u zapisuje się jako usunięcie, ze sprawcą tożsamym z osobą, której dotyczy.
Tokeny - wystawione i unieważnione, w tym tokeny assetów podpisujące media prywatne.
Workspace - zmiana ustawień i regeneracja sekretu wersji roboczych.
Endpointy webhooków - utworzone, zmienione, usunięte, rotacja sekretu i ponowne wysłanie zapisanej dostawy. Zmiana niesie informację, gdzie URL wskazywał wcześniej, które zdarzenia doszły lub zniknęły i czy endpoint został wyłączony. Rotacja niesie okno karencji, w którym poprzedni sekret nadal podpisuje - rotacja bez karencji psuje każdą dostawę, dopóki konsument nie wdroży zmiany. Endpoint wyłączony przez workera po dwudziestu nieudanych dostawach z rzędu też jest zapisywany, jako własna akcja z licznikiem porażek - nigdy jako czyjaś edycja.
Publikacja strony - opublikowanie, zdjęcie z publikacji, odrzucenie szkicu, publikacja layoutu, odrzucenie szkicu layoutu, przeniesienie szkicu developerskiego oraz zmiana etapu redakcyjnego. Publikacja to moment, w którym zmiana staje się widoczna publicznie, więc należy tutaj - choć edycja, która ją wytworzyła, nie należy. Publikacja layoutu jest własną akcją: zmienia to, co strona renderuje, nie czyniąc jej żywą.
Usunięcia - strona wraz z liczbą stron potomnych, które z nią poszły; przejęcie blokady strony od osoby, która ją trzymała; model wraz z liczbą rekordów, które z nim poszły; pojedynczy rekord; masowe usunięcie produktów wraz z liczbą i informacją, czy wybór padł przez identyfikatory, czy przez filtr; formularz wraz z liczbą zgłoszeń, które z nim poszły; oraz pojedyncze zgłoszenie. Wpis o zgłoszeniu nazywa formularz, status zgłoszenia i moment, w którym przyszło - nigdy tego, co wpisał odwiedzający. Dziennik audytu czyta się na innym uprawnieniu niż same zgłoszenia, więc powtórzenie w nim odpowiedzi wydałoby je komuś, kto nie może otworzyć skrzynki.

Każdy wpis nazywa obiekt, moment i sprawcę - osobę albo samą platformę, gdy zadziałała sama, na przykład wyłączając endpoint webhooka po serii nieudanych dostaw.

Każdy wpis mówi, skąd przyszedł zapis. Zmiana zrobiona w panelu nie niesie żadnego źródła. Zmiana zrobiona przez asystenta AI jest tak oznaczona i nazywa narzędzie, którego użył; zmiana przez serwer MCP jest oznaczona jako ta powierzchnia. Akcja jest ta sama w obu przypadkach - publikacja przez asystenta to ten sam wpis opublikowano, który zapisuje człowiek - więc ślad czyta się jako jedną historię, a potem zawęża do zapisów maszynowych, gdy to jest pytanie. Sprawcą nadal jest osoba, której token wykonał zmianę: asystent działa w czyimś imieniu, nigdy we własnym.

Organizacja ma własny dziennik

Organizacja jest właścicielem planu, miejsc i konfiguracji pojedynczego logowania. Te zdarzenia nie należą do żadnego pojedynczego workspace'u, więc trafiają do osobnego śladu z własnym odczytem. Ten rozdział trzyma dziennik workspace'u w ryzach: wpis w nim zawsze nazywa workspace, a zdarzenie organizacji nie ma takiego do nazwania.

Na poziomie organizacji zapisywane jest:

Sama organizacja - utworzona, przemianowana, usunięta, zmiana ustawień. Przemianowanie niesie informację, czy ruszyła nazwa, slug, czy oba; zmiana ustawień - nową rolę domyślną dla członków i to, czy członkowie mogą sami zakładać workspace'y.
Własność - przekazana, z imieniem tego, kto oddał, i tego, kto przejął.
Miejsca - zaproszenie kogoś, wraz z rolą w organizacji, którą mu zaproponowano; anulowanie zaproszenia; przyjęcie zaproszenia; usunięcie członka; zmiana roli członka w organizacji. To wpisy, na których opiera się spór o miejsce - a miejsce jest jednostką, w której liczy się plan.
Workspace'y - przeniesione do organizacji albo z niej, z nazwaniem obu stron przeniesienia.
Pojedyncze logowanie - domena dodana, zweryfikowana albo usunięta, konfiguracja połączenia, testowe połączenie wraz z wynikiem oraz włączenie i wyłączenie wymuszenia. Wymuszenie decyduje, kto nadal może zalogować się hasłem, więc zapisuje się jako własna akcja, a nie jako kolejna zmiana ustawień.

Rola w organizacji - właściciel, administrator, członek - to inna rzecz niż rola w workspace, która nadaje uprawnienia wewnątrz workspace'u. Zmiana jednej nigdy nie zapisuje się jako zmiana drugiej, a oba dzienniki nie mieszają swoich słowników.

Akcja, która nic nie zmieniła, nic nie zapisuje. Zapis formularza ustawień bez ruszenia pola albo ustawienie członkowi roli, którą już ma, nie zostawia wpisu: ślad zapchany niezdarzeniami to ślad, którego nikt nie czyta.

Czego nie ma i dlaczego

Edycji treści w dzienniku audytu nie ma. Żadnych zapisów stron, poprawek bloków ani uploadów mediów.

Publikacja i usunięcie to dwa wyjątki i oba stoją na liście powyżej. Granica nie biegnie między „treścią" a „dostępem", ale między odwracalnym a nie. Edycja szkicu jest odwracalna i prywatna, więc zostaje poza. Moment, w którym treść staje się publiczna, jest zapisywany - podobnie jak moment, w którym przestaje istnieć: usunięcie to jedyna operacja na treści, na którą potem nic innego nie odpowie, bo rzeczy, o którą ktokolwiek by zapytał, już nie ma.

To świadoma granica, nie przeoczenie. Te zdarzenia są wysokowolumenowe - jedno pracowite popołudnie daje ich setki - a wmieszanie ich pogrzebałoby piętnaście wpisów, które mają znaczenie, pod tysiącem, które go nie mają. Dziennik audytu odpowiada na „kto zmienił dostęp"; na „kto zmienił tę stronę" odpowiada historia wersji, która zapisuje każdy zapis wraz z autorem.

Reguła stojąca za tą listą: obejmuje to, co dotyka zaufania, uwierzytelnienia i rozliczeń, oraz to, po czym atakujący chciałby zatrzeć ślady.

Kto może go czytać

Dziennik workspace'u wymaga uprawnienia do zarządzania rolami. To celowe - dziennik jest w dużej mierze zapisem zmian uprawnień, więc ci, którzy mogą nadawać dostęp, są tymi, którzy widzą, kto go nadał.

Dziennik organizacji wymaga zarządzania organizacją: bycia jej właścicielem albo posiadania roli administratora organizacji. Uprawnienie z workspace'u tam nie sięga. Ktoś, kto zarządza rolami w workspace, nie ma prawa do zapisu, kogo zaproszono do organizacji stojącej nad nim - i posiadanie tego uprawnienia w każdym workspace należącym do organizacji nadal go nie otwiera.

Dziewięćdziesiąt dni

Wpisy starsze niż dziewięćdziesiąt dni usuwa zaplanowany job, który w jednym przebiegu zamiata oba ślady. Jeśli Twoje obowiązki retencyjne są dłuższe, eksportuj to, czego potrzebujesz, cyklicznie - zamiast odkryć lukę w trakcie audytu.

Jeden wpis celowo przeżywa swój obiekt: usunięcie organizacji jest zapisywane, a ten zapis nie jest usuwany razem z nią. Wygasa wraz z resztą, gdy minie dziewięćdziesiąt dni.

Następne kroki

Członkowie i role - uprawnienia, których zmiany tu lądują.
Tokeny API - wystawienie i unieważnienie, oba zapisywane.
Webhooki - endpointy, których zmiany tu lądują.
Pojedyncze logowanie - domeny, konfiguracja i wymuszenie, wszystko zapisywane na poziomie organizacji.
Historia wersji - ślad treści, który ten dziennik celowo pomija.