# Audit Trail Scope

Background and reasoning behind design decisions in splam. This page won't tell you how to do something. See the How-To Guides for that.


# What the audit trail does and doesn't capture

The audit trail (`audit_log.jsonl`) records every Start/Stop/Restart *attempted* through this app: timestamp, user, service, action, reason, and result. Attempts rejected by the app (an unknown service, a missing reason, or an auditor account attempting an action) are recorded too, with a `rejected:` result, so the trail shows what was tried and not only what succeeded. Login and logout attempts are recorded the same way: failed logins carry the username that was submitted, lockouts are recorded once an account has failed too many times, and a session ended by the idle timeout is recorded as a logout with the result `idle timeout`.

The boundary is the app itself, not the machine. Everything that reaches `audit_log.jsonl` passed through a form in this app; everything that didn't, didn't.


*\[Rich HTML output -- view on the documentation site\]*


Of the two blocked paths, configuration changes are the one worth naming twice. Several `SERVICE_INFO` entries call it out explicitly, because it's the gap admins are most likely to assume is covered when it isn't.

Treat it as a record of *this app's* actions, not a general-purpose system audit log. That's what `auditd` and centralized syslog forwarding are for (see the `auditd.service` and `rsyslog.service` entries on the Tasks tab).