Audits

Every workspace keeps a running record of who changed what and when. Whenever anyone creates an app, edits data, runs a pipeline, publishes a version or invites a teammate, an entry is added automatically. You read it through the Audit Analytics app: a ready-made surface over your workspace's audit trail, with pages of tables and charts.

The app is admin-only and system-managed: only admins see it, its configuration is locked, and it cannot be edited. It is also permanent - an admin can open it but cannot archive, restore or delete it, so audit history can never be hidden or removed. It is always live, reading directly from the trail: there is no run to trigger and nothing to refresh, and numbers are current to within a minute or two.

It shows the activity of the apps you can open. Another member's personal space stays private, an admin included: the entries of an app in it - and of an app that has since been permanently deleted - do not appear in any table, chart or total. Entries that belong to no app, such as a member being invited, always appear.

Opening it

• From the apps list. Admins see Audit Analytics alongside the other apps.
• From a "View audits" button. A small clock button sits on a dataset row, a pipeline node, a version in the history, a knowledge-base item, a member, an indicator, a Visualisation configuration, a reporting period, and a single indicator value cell. It opens the app in a new browser tab, pre-filtered to that resource, so you keep the screen you were on.

Two of those deep links matter most in an indicator app. On a cell in the data grid, the button opens Indicator Data Changes filtered to that one cell - that indicator, that breakdown, that period - so you see every value it has held and who set each one. On a reporting period, it shows everything that happened to the period itself: created, renamed, submitted for review, approved, reopened.

What each page shows

• Overview - activity across the workspace: how many actions over time, who did them, how much was driven by AI. It also carries a Deletions and bulk operations table and a Retained originals table, which lists every original file that was kept (a dataset upload, or a document you gave Vera) with its name, app, node, who or what uploaded it and when, and a one-click download of the file exactly as it came in.
• All actions - everything that happened, newest first, one row per event: when, the action, the resource, and who or what did it. Every column filters, so this is where you narrow to a time window, an actor kind, one actor, one app or one kind of action.
• Analytics Data Changes - every change to an analytic app's data. An inline edit shows one row per changed cell (the value before and after); a deleted row shows one row for the whole deletion, with no column and no before/after; an upload or a replace shows one row for the whole write (see Uploads and replaces).
• Indicator Data Changes - every change to an indicator value, one row per changed cell: the indicator, its dimension and reporting period, the value before and after, and who changed it.

Reading a change

Each row answers the same questions:

• Row - which record changed (on a data-change page, the stable id of the row or cell). A data-change page also carries Created, Last updated and the Row ID, so you can sort or filter by any column to follow one record's full history.
• When - the time the change happened.
• Actor - who or what made it. Usually a person; for an AI-made change the person who instructed the AI (see AI accountability); for a change written by a connected system, that integration.
• Actor kind - Person, Vera, External AI, Integration, Support or System. Filter on it to see, for example, everything last night's connected system did.
• AI - set when the change was made by AI rather than directly by a person. An integration is not AI, so a machine write does not set it.

Most rows include a Resource link, which opens the changed resource in its live editor, selected and ready to inspect. A link is inactive when the resource was deleted after the change was recorded: the history stays, but there is nothing live to open.

Uploads and replaces

Most data arrives as a file upload or a replace that writes thousands or millions of rows at once. Recording one entry per row would swamp the trail, so a bulk write is one entry for the whole write, on the Analytics Data Changes page beside the inline edits:

• Row shows the block of rows the write created, for example 1-51200.
• Operation reads replace_rows or append_rows. This is the one to check when following a single row: a replace threw away everything the node held and numbered the new rows from 1 again, so row 4 after a replace is a different row from row 4 before it. An append left the earlier rows as they were.
• Rows written is how many rows the write actually added.
• Changed by and When are the person and time, exactly as for an edit.

The block is a range, not a list: when an upload skips duplicate rows, some ids inside the block are never given to any row, so Rows written can be smaller than the block looks. For the same reason a bulk entry's Resource link opens the node's data unfiltered.

This is what makes the per-row View audits button useful for data that was never edited by hand: on a row that arrived by upload it finds the upload that created it, alongside any later edits, in one list.

Downloading a table

Every table in the app has an Export button, so you can hand the evidence to an auditor or a colleague as a file. Choose CSV or Excel.

The file holds the rows the table shows. Every filter on the table applies, including the ones a View audits link set when it opened the page already narrowed to one resource - open Analytics Data Changes from a node's link, export, and the file holds that node's changes rather than the whole workspace's. The page's parameters and the search apply too. The file carries every column of the table, not only the ones on screen, and its rows come in the table's own default order (newest first on the pages that list changes), however you have sorted the table on screen.

The whole history of a workspace can be more than a spreadsheet holds, about a million rows. Excel is refused for it with a message saying so; download it as CSV instead, or filter the table first.

Every download is recorded, the audit trail's own included: an admin sees who downloaded what, when and how many rows under Data downloads on the System page.

AI accountability

When Vera or a connected AI makes a change on someone's behalf, the trail shows both the AI and the person who instructed it: the AI column marks the change as AI-made, the Actor is the person who asked for it, and the AI model that made it is recorded too. So even when the AI did the work, it is always clear who is accountable. See AI transparency.

Changes made by a connected system

A connected system - an ERP, a warehouse, a nightly job - writes through the Automation API under a credential an administrator issued. Those changes are recorded like any other, with two differences:

• The Actor is the integration itself, by the name it was given when the credential was created, and the Actor kind reads Integration. Nobody was at a keyboard, so no person is shown as having done it. The name survives the credential being revoked or deleted, so history stays readable.
• Who issued the credential is a question about the credential rather than about the change, and it is answered on the Access page's API credentials tab. Any credential event in the trail - created, secret rotated, scopes changed, revoked - links straight there, attributed to the administrator who performed it.

For what a connected system is and how an admin issues its credential, see Credentials.

How history is kept

Audit history is captured on every change and kept in the Audit Analytics app with no time horizon: older history stays readable however old it gets.