Skip to main content

Audit logs

The change history is an account-level audit log of every meaningful action against every resource on SimplAI. Account admins use it to answer "who did what to which resource, and when?"

Where it lives​

The change history is available at the account level for account admins. It surfaces actions across all projects in the account.

Table columns​

  • Date and time — when the action happened.
  • Project name — which project the resource belongs to.
  • Resource type — Agent, Tool (covers both task mode and Conversation mode; legacy AI Chains appear here), Voice Agent, Model connection, Dataset, Dataset file, KB, KB file, Data source, Integration, Service Provider, Evaluation suite, Settings, MCP, A2A.
  • Resource name — the human-readable name.
  • Action — what happened (see below).
  • Changed by — the email of the user who performed the action.

Actions captured​

  • Basic CRUD for every resource type, plus archival / restore actions.
  • New draft (Agent, Tool, Voice Agent).
  • New version (Agent, Tool, Voice Agent).
  • Version state change — to latest or published.
  • Import / export version or app.
  • Enable / disable integration.
  • Model new key selected for inference (enable / disable for the model itself is covered under CRUD).
  • Source setup create / disable (Data source → connections).
  • Dataset sync setup create / disable (Data source → connections).
  • KB sync setup create / edit / disable (KB → Dataset sync in KB settings).
  • Each new account added for an integration.

Filters​

Filter the change history by:

  • Project
  • Application type
  • Action
  • Changed by (user)
  • Date range — default is the last week.

These filters cover the common forensic patterns — "what did user X change last week", "what happened to project Y after the deploy", "which Datasets were deleted last month".

Side-by-side JSON diff​

Clicking an audit entry opens the entry's detail view. For changes that modify configuration, the detail view shows a side-by-side JSON diff of the resource configuration (Old vs New).

Diff highlighting​

A legend at the top explains the highlighting rules and shows the count of lines modified.

  • Added lines (only in New): highlighted green in the New JSON. A blank placeholder line is left in the Old JSON to preserve vertical alignment.
  • Modified lines (in both, value changed): highlighted yellow in both Old and New.
  • Removed lines (only in Old): highlighted red in the Old JSON. A blank placeholder line is left in the New JSON, also highlighted red to preserve alignment.

This makes it easy to read what actually changed between versions, especially across deeply nested configurations.

Reducing noise from draft edits​

Without grouping, draft edits to an Application can flood the audit log — every small change becomes a separate row.

To prevent this, draft edit events for Applications (Agent / Tool) are grouped using a 10-minute rolling window:

  • When a Draft Edit event occurs for an application, the system starts a 10-minute wait window.
  • If, within that window, the next event is another Draft Edit for the same application by the same user, the events are grouped and the window restarts from the latest event.
  • When no further qualifying Draft Edit occurs within 10 minutes — or the next event is different (different app, different user, different event type) — the system writes a single audit log entry representing the grouped activity.

Grouping applies only to Draft Edit events and is scoped to (application, user).

Download​

The change history is downloadable as CSV. The download has the same columns as the on-screen table, plus two additional columns for before and after JSON, so the full diff is available for offline review.

Architecture note​

Audit logging is event-driven. Functional services emit change events to a Kafka topic; the Tracer service consumes the topic, persists the events, and serves the filter API behind the change history UI. This means audit events can lag the action by a few seconds in extreme cases but are durable across service restarts and pod replacements.