Audit log

kesarAI keeps a structured audit trail of moderation actions, member events, AI usage, and a real-time mirror of Discord's own audit log. This page is the source of truth for the transparency claims in the privacy policy— what gets stored, where, for how long, and what doesn't.

Every event the bot can log is declared in one place — a log taxonomy registry — which the bot, the audit database, the setup UIs, and this very page all derive from. The category lists below are generated from that registry at build time, so what you read here is exactly what the running bot writes.

Six subjects

Every logged event resolves to one of six subjects — the delivery routing layer that decides which channel an event ends up in. Subjects sit on top of the categories below: a busy guild can split its noise into up to six dedicated channels (mod, members, messages, server, AI, tickets) instead of one firehose channel.

Existing servers keep working with zero config changes — every legacy category (moderation, members, ai, modai, translate, and the native audit categories) already maps to one of these six subjects, so events keep landing in whatever channel they land in today. Opting into the full split is a one-time setup step (see below).

Two kinds of category

Logging is split into two families. Each category is independently enabled per guild — if a category is off, nothing from it is written and nothing is mirrored.

Bot categories

These are events the bot itself produces. Each routes to its own log channel, and each row is stored in audit.db with a case number you can look up via /logs case.

Discord audit categories

These mirror Discord's native audit log into your server as styled embeds — channel edits, role changes, message deletes, and so on. They are presentational by default (no database writes on the Discord-mirror side) and grouped into the categories below so you can enable only the ones you care about.

Severity

Every event carries a severity, stored alongside the row so you can filter the dashboard by how much something matters rather than scrolling a flat feed. The four levels, softest to hardest:

• low — Routine activity — joins, AI calls, role tweaks.
• medium — Worth a glance — kicks, mutes, message edits, channel deletes.
• high — Notable — quarantines, lockdowns, antinuke triggers.
• critical — Act now — bans and member bans.

Setup — Simple and Advanced

Run /logs setup to open the unified configuration panel. It has two modes, toggled by a button:

• Simple— one channel for every bot log category, plus one mirror channel for Discord audit events and a single multi-select for which audit categories to mirror. The fast path most servers want.
• Advanced— per-category routing. Pick a category, point it at its own channel, repeat. Routing scales to any number of categories, so you can send moderation to #mod-log, AI usage to #ai-log, and Discord audit events somewhere quieter.

The current configuration — which categories are on and where each one routes — is visible at any time in /logs status.

Apply recommended split — a one-click button in the setup panel creates six dedicated channels (#mod-log, #member-log, #message-log, #server-log, #ai-log, #ticket-log) under a mod-only category and binds each subject to its channel in one step, instead of routing categories by hand.

Where it goes

Bot-category events are written to a SQLite database (audit.db) on the bot's hosting infrastructure. Each guild's entries are keyed by guild ID and isolated from every other guild.

When a moderator configures a mirror channel, the same events are posted to Discord as styled embeds in real time. The Discord mirror is presentational only — the embeds carry less detail than the database row, and the native Discord-audit categories (channels, roles, messages, members, invites, voice, threads, server, emojis, webhooks) write nothing to the database at all. Deleted/edited message content and images only ever appear in the mirror embed, not in the dashboard's log viewer or in an export.

Dashboard viewer — each row in the web log viewer renders its detail pane based on what kind of event it is: moderator actions show duration and extra context inline (already formatted, e.g. 5m, never a raw timestamp), member events show account age and invite attribution, AI usage shows the triggering input. Any event without a dedicated view falls back to a labeled field list rather than a raw JSON dump.

Retention

Audit logs are retained indefinitely by default. Server administrators can set a per-guild retention period using:

/logs retention days:90

A daily background task removes entries older than the configured number of days. Setting retention to zero (or omitting the value) disables automatic purging for that guild. The current setting is visible in the /logs status view.

Tip. 90 days is a sensible default for most communities — long enough to investigate ban appeals, short enough to keep the audit table small. Pick a number you can defend in a privacy conversation with your members.

Exports

Server administrators can export their guild's audit data via /logs export in three formats:

• CSV— for spreadsheets and quick filtering.
• JSON— for downstream tooling and pipelines.
• TXT— a human-readable log, one event per line.

Exports always cover only the requesting guild. There is no cross-guild query surface for moderators — the operator does not expose one.

What's not logged

Plenty of things never touch audit.db. For clarity:

• Message content is not stored. AI commands read messages on demand for the request and discard them afterwards; moderation rows store metadata (target, channel, reason) and, where a rule needs it, only the first 200 characters of a trigger phrase.
• Direct messages the bot sends or receives are outside the guild and outside the audit trail.
• Activity in servers you don't share with the Bot is never visible to it. The bot only sees the guilds it is in.
• Credentials— the bot's Discord token, Gemini key, and database paths are never written to any audit entry.