# Audits (/docs/administration/audit-trail) 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 [#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 [#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](#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 [#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](#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 [#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 [#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](./index.mdx#usage). ## AI accountability [#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](../infrastructure/ai-transparency.mdx). ## Changes made by a connected system [#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](../integrations/api/credentials.mdx). ## How history is kept [#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.