Skip to main content

Audit trail

Every administrative change your staff makes is recorded in one place: who did it, to whom, and what the value was before and after. It exists to answer "who changed this, and when" after the fact. It is not a version history and there is nothing to roll back.

Navigation paths:

  • Server Admin โ†’ Audit trail
  • Organization โ†’ Audit trail โ€” the same screen across every server in the organization
  • Server Admin โ†’ Players โ†’ Open player โ†’ Audit trail โ€” one player's slice

Access requirementsโ€‹

  • admin.audit.view โ€” the server-wide page and the player's own audit spoke
  • org.audit.view โ€” the organization-wide view

Both are labelled View Audit Log.

This is a power right and nobody has it yet

It is in no default group, and there is no backfill command. Somebody holding it sees entries from every area, regardless of which area rights they have otherwise โ€” an entry about a balance change is visible to them even without any economy right. Treat it as a right for server owners rather than for ordinary staff, and grant it deliberately.

What an entry containsโ€‹

  • When it happened
  • What happened โ€” the action, as a readable title, plus the area it belongs to
  • Who did it. This is always the real acting person. If they were impersonating a player at the time, the entry records the impersonation separately and the row says acting as that player, so impersonation can never be used to hide behind somebody else's name.
  • Whom it affected, where an action has a subject. A player who was deleted since still appears, marked as deleted.
  • Where the action came from โ€” the web panel, Discord, the API, the AI Companion, an AI app connected over MCP (via MCP, see Connect AI apps), or the system itself. A Companion or MCP change is always recorded under the real person behind it. Entries written before this was recorded leave it empty.
  • What changed โ€” an expandable list of fields with their before and after values. Changes that would not have changed anything are dropped rather than recorded as noise.

Two things are held back on purpose. Secrets are never stored: a token or key is masked, and only compared well enough to notice that it changed. Third-party text is not copied in: when staff edits a ticket message, the entry says the content changed, not what a player had written.

The areasโ€‹

An entry belongs to one of: Players, Economy, Content, World, Server, Access, Communication, Logs, Organization. These mirror the categories the access rights use, so the filter on this page lines up with the way rights are grouped in Access control.

The area chips only offer areas that actually occur in what you are looking at.

Filteringโ€‹

  • Area โ€” one or more of the areas above
  • Player โ€” search for a player, then choose whether you mean them as the one affected or as the actor
  • Free text โ€” matches actor name, affected player and the action
  • Date range โ€” in your server's timezone

The organization-wide view adds a server filter and shows which server each entry came from while you are not filtered to one.

On a player's own audit spoke, the affected/actor toggle only appears when there are entries on both sides.

Retentionโ€‹

Entries are kept for 12 months by default. The period is a per-server setting and can be set anywhere from 1 to 120 months. Changing it is itself recorded in the trail.

A nightly job deletes what has aged out. Actions that belong to no single server are kept on the 12-month default.

What is not in hereโ€‹

This trail records what staff did through the admin surfaces. It does not record:

  • What players did. Purchases, casino play and shop use are not administrative actions; they live in the order history and the ledger.
  • What happened in the game. Kills, connects and chat come from the game logs and live in the Log Explorer.
  • What your game server complains about. Configuration errors out of the RPT log are a different feature with a similar name โ€” see Server diagnostics.
  • Discord anomalies. Problems the system detects on your Discord guild are their own thing, not administrative actions.

One phrase elsewhere in the manual can mislead: the feature list describes scoped log exports as having a "full audit trail". Those approvals genuinely are recorded here, under the Logs area. It is this trail, not a second one.