A record of who did what to whose data
When someone asks why a member's record changed, or your data protection officer asks who exported the roll last March, the answer should take a minute. That only works if logging was written as each action was built, not added afterwards.
Written as it happens
Approvals, suspensions, role changes, profile edits, exports, payment approvals, moderation, publication. Each module writes its own entries as the mutation is performed. Bolting this on later means touching every controller twice and missing some, which is why it was a rule from the first module rather than a phase at the end.
Read-only, deliberately
There is no edit and no delete in the interface. A log somebody can tidy up is not evidence of anything, and the moment it becomes editable it stops answering the question it exists for.
Filterable when it matters
By actor, action type, affected record and date range. That is the shape of the question people actually ask — "what happened to this member in June", "what did this administrator do" — rather than a wall to scroll.
Audit log — questions
If yours is not here, ask on a call. We answer specifics.
How long are entries kept?
For the life of the deployment by default. It is your database, so a retention policy is yours to set.
Are member actions logged too?
The log's purpose is administrative accountability — actions taken on someone else's data. A member editing their own profile is not the same category of event.
Can we export the log?
Yes, which is usually what a data protection audit actually wants.
See audit log against your own setup
Bring the awkward case — the exception your constitution requires, the thing your current system cannot do. That is the useful half of a demo.