Audit Log
The audit log records who did what, and when — sign-ins, role changes, content changes, scoring, deletions. You find it under Admin → Logs.
The four categories
The Category filter selects which kind of entries you see:
| Category | Contents |
|---|---|
| Audit | Security-relevant events: sign-ins, account lockouts, role changes, creating/editing/deleting content and users, scoring. This is the category for traceability and data-protection requests. |
| Application | Business processes of the application (e.g. state changes of a run). |
| Error | Error conditions — relevant to operations. |
| Access | Requests to the application (HTTP level). |
Filtering and searching
| Filter | Use |
|---|---|
| Search | Free text across event, actor and affected object |
| Category | see above |
| From / To | Narrow the time range |
Apply activates the filters, Reset clears them. Show details on an entry expands the changed fields and its integrity hash.
Export
Export as CSV downloads the currently filtered view as a file — suitable for analysis, audits or a data-protection request.
Tamper evidence
Every audit entry carries a cryptographic checksum (HMAC) that includes the previous entry. This forms a chain: if an entry is altered or removed afterwards, the checksums of all following entries no longer match — the tampering shows up.
An entry's checksum is visible via Show details. The chain itself is verified server-side by the operator of the instance; that is an operations task, not a UI feature (see Operations).
Retention
Audit entries are kept for 365 days, application and error logs for 90 days. The operator of the instance can adjust both periods.
Personal data stays readable — deliberately
When a user account is deleted and anonymized after the 30-day window, its audit entries remain; they can then no longer be attributed to a person. That is intentional: the traceability of security-relevant events must outlive the deletion.