Audit log

The audit log is the platform's immutable record of administrative actions. It exists so any decision, change, or access can be traced back to a specific actor and moment in time.

Where to find it

Go to /settings/audit (from the account menu → Audit log).

This page is visible to workspace owners (and platform superadmins, for support cases). Other roles cannot see the log.

What's on the Audit log screen

Page title "Audit log" + a Superadmin view badge top-right when viewed by a platform operator.
Description depends on role:
- For owners: "Events for this workspace. Showing the 50 most recent."
- For superadmins: "Platform-wide events across every workspace. Showing the 50 most recent."
Filters bar with four controls:
- Action dropdown — defaults to "All actions"; pick a specific event type to narrow.
- Actor email input.
- Workspace slug input (optional, superadmin only).
- Apply button.
Event table with columns:
- WHEN — date/time
- ACTOR — display name + email below
- ACTION — event-type tag (e.g. build.start, source.upload)
- TARGET — category (e.g. BUILD_JOB, SOURCE) + ID
- WORKSPACE — name + project context
- DETAIL — free-form context line (e.g. "total_ms=13053 · phase_count=12", "filename=cpg_orders_e2e.csv · size_bytes=619", "worker_job_id=6470")
Export controls (CSV / NDJSON, scroll for the button).

What's logged

The audit log captures structural and security-relevant actions, not every individual read or every reasoning run. Specifically, you'll find events for:

Authentication — auth.login, auth.logout, auth.google.callback, auth.forbidden (denied access attempts)
Workspace & members — workspace.update, workspace.member.invite, workspace.member.remove, role changes
Projects — project.delete, project.update
API keys — api_key.create, api_key.revoke
Skills — skill.upload, skill.fork, skill.patch_prompt
Trackers — create / update / archive / run-now
Ontology — mutations to atoms, accept / defer / reject of candidates, promotion requests
Foresight settings — updates to trusted/excluded domains, bookmark URLs
Boards — create, share, archive
Ingestion / pipeline — build.start, build.complete, source.upload with file metadata
Plan jobs — start / completion telemetry for long-running reasoning jobs

Calibration note. The audit log does not record every reasoning run or every source read. If you need full read-level audit (for example, regulatory compliance requiring "every query against table X is logged"), talk to your admin — this is a separate capability and not enabled by default.

What each event contains

Every event has:

Timestamp (UTC)
Actor — the user (email) or the API key that took the action
Workspace and project scope
Action — the event name (e.g. project.delete)
Target — the type and ID of what was acted on (e.g. project ID, member email)
Metadata — context for the action (e.g. previous vs new value)
Hashed IP — IP addresses are sha256-truncated before storage; raw IPs are never persisted
User-Agent — the browser or API client that made the request

Filtering

You can filter the log by:

Action (e.g. show only project.delete events)
Actor (e.g. show only events from a specific email)
Date range

Results are paginated (50 per page).

You can export the filtered log as CSV or NDJSON for offline analysis or for handing to your security team. The export is capped at 50,000 rows per request — narrow your filter if you need more.

What's NOT logged (today)

Every individual question asked in Reasoning (those are in the reasoning run history, but not the audit log).
Every read against a source's data (the agent's SQL queries against DuckDB / BigQuery).
File downloads from GCS.
Real-time tracker runs (the run history is on the tracker's detail page, but not in the audit log).

Pre-publishing note for the team: if the docs are going to a regulated customer, calibrate this list with engineering. Don't promise "every read is logged" — it's not.

Retention

Status: gap. There is no automatic retention/cleanup policy on the audit log in the platform today. Events accumulate indefinitely. If you need a deletion or archival policy (for example, "delete events older than 7 years"), that's an operational task for your admin/DBA. Surface this to engineering before publishing the public docs.

Tips

Skim the log weekly if you're an owner. You'll spot unusual patterns (a user creating five API keys in a day, repeated auth.forbidden from one actor) before they matter.
Export before any role change that revokes Owner — once you're not Owner anymore, you can't read the log.
Pair audit events with reasoning runs. When investigating a decision, cross-reference the audit log (administrative trail) with the reasoning run history (the actual question and answer).