Audit & compliance

In one line. What gets recorded where — who did what, what is being consumed, and the whole life story of one document — plus how you version and freeze a project’s configuration so an auditor can trust it. You’ll be able to. Read, filter and export the audit trail at the right scope, pull one document’s complete timeline, read the Usage view without mistaking it for a bill, and snapshot or freeze a project’s configuration. Where this lives. Studio ▸ Governance ▸ Oversight ▸ Audit & Usage, the Audit trail sheet on any document, and Studio ▸ Governance ▸ Versioning (History · Snapshots · Freeze).

One page, two views

Audit & Usage is a single page with two views, and a switcher of two buttons sits directly under the title:

• Audit answers who did what. One row per action, with the actor, the category, the action, a description, and whether it succeeded. This is the compliance record.
• Usage answers what is being consumed. AI requests, tokens, estimated cost, the time people spent reading documents, and your plan counters.

The switcher navigates — the view you are on is part of the address, so you can bookmark or share either one. Filters do not carry across: each view reloads with its own defaults.

Reach for Audit when someone asks a compliance question. (Run traces — what an agent or pipeline actually did, step by step — are a third record, covered in G4 · Observability.)

Coming from older notes? The standalone Activity page is retired; the reading-session numbers it showed are now the People activity section of the Usage view, and old Activity links land there.

The same page at three scopes

The page exists at three levels. Which one you open decides how far it can see.

Scope	Where	What it covers
Project	Studio ▸ Governance ▸ Oversight ▸ Audit & Usage	Everything inside this one project, and nothing outside it
Workspace	Workspace settings ▸ Audit & Usage	Every project in the workspace, plus workspace operations and sign-ins
Platform	Account menu ▸ Admin ▸ Governance ▸ Audit & Usage	Sign-ins, user management and API-key activity across every workspace

Only workspace admins see the workspace entry, and only Platform Admins see the platform one — the menu hides what you cannot open rather than showing a link that fails (G1 · Access & roles).

Three things exist only at project scope: Export CSV, the deletion detail block, and the Open Document Timeline → jump. And the project Audit view deliberately cannot show sign-ins or workspace-wide user management — that is by design, not a gap; ask those questions one level up.

Reading a workspace audit feed is itself an audited act, so the record of who went looking is kept too.

Reading the Audit view

Scope chips

A row of chips above the filters picks which slice of the trail you are reading. At project scope: Project, Document, API. At workspace scope: All activity, Workspace ops, People & sign-ins, API keys. At platform scope: All activity, People & sign-ins, API keys.

Each chip has its own empty-state wording, so an empty table tells you which slice came back empty rather than leaving you guessing.

The filters

Control	What it does
Who	everyone / People / Agents / System / API keys. On People (or everyone) a free-text box appears next to it so you can narrow to one email.
Category	One area of the product — Project, Document, Taxonomy, Sources, Settings, Annotation, Search, Automation, Agent Builder, Security and the rest. At project scope the list is drawn from that project’s own categories, so it can be shorter.
Operation	Access, Create, Update, Delete, Download.
From date / To date	Bound the period. From covers the whole start day, To the whole end day. Leave both blank for everything still held.
Clear	Resets Who, the email, Category, Operation and both dates in one click. It does not reset the scope chip.
Export CSV	Downloads the rows your filters produce. Project scope only — the caps are worth knowing, see Exporting evidence below.

Two behaviours worth knowing. Choosing Agents, System or API keys clears any email you had typed, because a person filter is meaningless for those; and on the API / API keys chip the whole Who control disappears — that chip already pins the actor kind, so there is nothing left to choose. And Access rows — written whenever someone opens a governed screen — are by far the most common, so leaving Operation on all buries the change history. Set it to Create, Update or Delete when you are hunting for changes.

The table

Five columns, newest first: Time, Actor, Category → Action, Description, Result.

The Actor cell carries a small letter badge for the kind of actor — H a person, A an agent, S the system, K an API key. The kind is recorded with the entry itself, so “a person did this” versus “automation did this” is a recorded fact, not a guess. Result is a green OK pill or a red Fail pill; you read it, you cannot filter by it.

Rows arrive 25 at a time. Load more appears below the table with a counter — 25 of 412 — so you always know how much of the matching set is on screen. No button means you are looking at the complete result for those filters. Because activity is still being written while you page, that counter can grow between clicks.

Opening one record

Click anywhere on a row — the whole row is the target — and a side panel titled Audit record opens with everything recorded: Time, Actor and its kind, Scope, Category, Sub-category, Action, Operation, Document, Label, Description, Result with any failure message, Location, Device, and a Record id. Quote the Record id when you raise a query about a specific entry. Close with the Close button, by clicking the dimmed background, or with Esc.

Older records simply omit Location and Device — those were captured from a certain point onwards, and anything from before shows no row at all rather than a blank.

Deletion records. At project scope, clicking a Delete row that names a document adds a block showing who deleted it and the role they held at the time, when, how (the kind of deletion and what triggered it), the reason and its category, the location, whether a metadata snapshot was kept, and whether the document is still restorable. If no detailed record was captured, the panel says so plainly instead of inventing one.

Open Document Timeline → sits at the bottom of the panel on project-scope rows that name a document, and jumps straight into that document’s own life story.

One document’s Audit trail

“What exactly happened to this document?” is a click. Open the Audit trail side sheet from a document row’s ⋮ menu, or from the clock icon in the document header while you are reading it.

It brings everything that ever happened to that one document into a single timeline, grouped into phases in lifecycle order — Ingestion, Automated processing, Human review, Output, Error — with events reading oldest-first inside each phase, so the trail reads as a narrative. Each entry shows the time, who or what did it, and a one-line summary; click an entry to expand its detail, and where a value changed you get a before/after pair marked − and +.

Control	What it does
Phase pills	All, then one pill per phase that actually has events, each with its count. A short pill row means a short story, not a broken filter.
Actor toggles	Human, Agent, System, API key — all on by default. Switching one off hides that kind of actor and changes the visible count, not the total.
Sources	Shows how many events came from each system of record and flags any that could not be reached. A diagnostic view; most people never need it.
Export CSV	Downloads the loaded timeline. Disabled while loading and when there are no events.
Refresh	Re-reads the trail.

The header counts what you are looking at against the total — 37 of 120 events — and shows the span the trail covers.

Check for the partial banner before you rely on it as evidence. If one of the underlying systems could not be reached, a banner reads “Timeline may be partial — source unavailable: …”. When everything answered, the footer instead says All sources healthy. One sick source never blanks the whole trail, but it does tell you.

Exporting evidence

Export CSV on the project Audit view downloads exactly the rows your current filters produce, named after the scope and today’s date, so a reviewer gets the same evidence the screen shows.

Know the limits before you promise anybody a file:

• Export CSV exists only on the project Audit view. The workspace and platform Audit views have no export. If a reviewer needs workspace-wide evidence, the honest answer today is a screen capture or one export per project.
• The audit export is capped at 10,000 rows. If your filters match more, the file ends with a line saying it was truncated and telling you to narrow the filters.
• The document-timeline export is capped at 500 events, and likewise ends with a note saying how many of the total were exported.

Some screens link straight into the audit already filtered — from a document to everything that happened to it, for example. Arrive that way and the filters are set for you.

The Usage view

Usage is activity observability, not billing. Every cost figure on it is labelled an estimate, derived from tokens and model price; the authoritative spend ledger sits with the Managed Gateway and is surfaced through Billing meters. Never hand a Usage cost tile to finance as an invoice.

At project scope a Period dropdown at top right chooses Last 7 / 30 / 90 days, defaulting to 30:

• AI usage — four tiles for the period: Requests (with a passed/failed split), Agents (how many were active in the period), Tokens (in/out), and Cost (est.) with average latency underneath. Below them, a Requests per day bar chart (drawn when the period has more than one day of data), and a By agent table — Agent, Requests, Failed, Tokens, Cost (est.), Avg latency, Last run — where clicking a row opens that agent so you can inspect its runs.
• People activity — two tables, By document and By user, measuring reading sessions: how much time people actually spent with documents open, and how many annotations they made. Empty until people start opening documents, and the empty state says exactly that.
• Plan counters — live project totals for Documents, Pages and Annotations. These are running totals, not period figures, so changing Period does not move them.

At workspace scope there is no Period picker; each section states its own window inline. You get People & adoption (active people, reading sessions, reading time, annotations), AI & automation (agent queries, AI cost, failed runs, average answer time), a one-line Content summary, a By project breakdown, and the Billing meters embedded at the foot — pick a date range, Search, and read counts and costs per project. Those meters are the billing authority; the tiles above them are not. If you kept an old Usage Details or metering bookmark, it lands here.

At platform scope you get a cross-workspace leaderboard — Workspace, Queries, AI cost, Failed runs, Sessions, Active people, Documents — and the same Billing meters with a workspace picker.

Zero is a real answer. Every block on this page loads and fails independently. A failure says “Couldn’t load…” — usually with a Retry, though the plan counters only report the failure — and only that block is affected; the rest of the page still renders. So when a section says no activity in this period, that is a genuine zero, not a broken query.

What is not recorded

One gap matters more than any other, and it is better said out loud than discovered during an audit:

Reads made with an API key are not recorded in the audit trail. When an outside system fetches documents or data using a project API key, no audit row is written for that read. Actions taken with a key that change something do leave rows, under the API / API keys chip with a K badge.

So: an empty API-key feed does not prove nobody read your data from outside — it proves nobody changed anything.

If you need to know which keys could be reading, the key list is at Studio ▸ Governance ▸ Access ▸ APIs (G1 · Access & roles).

One smaller note for completeness: two narrower audits live elsewhere and catch people looking for “the audit page” — Studio ▸ Experience ▸ Search ▸ Audit records what people searched for, and Studio ▸ Experience ▸ Chat ▸ Audit records conversations. Neither is part of Audit & Usage.

Versioning: History, Snapshots, Freeze

Studio ▸ Governance ▸ Versioning — three menu entries governing your project’s configuration (not its documents).

Entry	What it does
History	Every change to the configuration — what changed, when, and by whom. Select an entry to see exactly what differed, roll back to it, or record a new checkpoint with a message.
Snapshots	Export the whole configuration to a portable file — Export Compact (all modules, optimised for transfer) or Export Full (adds extended metadata and audit artifacts) — and restore one by dropping a file back on the Import zone.
Freeze	Lock the project’s configuration, and lift the lock again. Unfreezing asks you to confirm. Every freeze and unfreeze is recorded here.

The freeze concept. Freezing a project locks its configuration. While it is frozen, History and Snapshots gate their destructive actions — Commit is disabled, and the Import zone refuses drops — so nobody can quietly rewrite a configuration you have blessed for production. Unfreeze when you genuinely need to change something, then freeze again.

Snapshots are files you keep, not a server-side history. The Snapshots page lists Recent exports (this session) — a convenience log of what this browser tab has downloaded, cleared when the session ends. There is no stored library of past snapshots to restore from: restoring means having kept the exported file and dropping it back on the Import zone. Store the file somewhere durable, and commit before you import — a restore cannot be undone.

Tip. A good rhythm: record a checkpoint at each meaningful configuration milestone, export before a risky change, and freeze once a solution is stable and shipping.

Publishing what you froze

Publishing is no longer part of Governance. A project reaches other people through the Hub: open Hubs ▸ Solutions (the Hubs chip sits on the top bar next to Exit Studio) and publish from there. The whole packaging and installing story — signing, versions, installing into another project — is V4 · Hubs & distribution, with an end-to-end walkthrough in UC · Package & ship a solution.

Recap

• Audit & Usage is one page with two views: Audit = who did what, Usage = what is being consumed. The switcher under the title is part of the address.
• The page exists at project, workspace and platform scope. Export CSV, deletion detail and the document-timeline jump are project-scope only.
• Filter the Audit view with scope chips, then Who / Category / Operation / dates. The table is Time · Actor (H / A / S / K) · Category → Action · Description · Result. Click any row for the full record and its Record id.
• The per-document Audit trail sheet groups the whole life of one document into phases, oldest-first inside each phase, and flags a partial trail rather than hiding it.
• Exports are capped — 10,000 audit rows, 500 timeline events — and the file tells you when it truncated.
• Usage is observability, not billing: every cost is an estimate, and the Billing meters at the foot of the workspace and platform Usage views are the authority.
• Reads made with an API key leave no audit row. Say it before an auditor finds it.
• Versioning = History, Snapshots, Freeze. Publishing happens in Hubs ▸ Solutions.

Where to go next

• V4 · Hubs & distribution — where a published solution goes: the Hub, signing, and installing into another project.
• UC · Package & ship a solution — the end-to-end packaging walkthrough.
• G1 · Access & roles — the roles and API keys whose actions this trail records.
• G4 · Observability — run traces: what the machine did, alongside what the people did.