> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blindsight.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit trail

> A tamper‑evident log of every action in your workspace. Filter, drill in, export, and pipe to your SIEM.

The Audit Trail is a tamper‑evident log of everything that happens in
the workspace: who did what, when, to which object, with what
parameters. It's accessible from the top nav and from the Compliance
page.

## What gets logged

| Category           | Examples                                                                     |
| ------------------ | ---------------------------------------------------------------------------- |
| **Authentication** | Logins, logouts, failed login attempts.                                      |
| **Users & roles**  | Invitations sent / accepted / revoked, role changes, password resets.        |
| **Projects**       | Create, rename, archive, delete, member changes.                             |
| **Datasets**       | Upload, edit metadata, branch, lineage updates, deletes.                     |
| **Scans**          | Start, cancel, finish, error, retry, parameter snapshot.                     |
| **Healing**        | Trigger, toggle set, output target, completion.                              |
| **Settings**       | Workspace settings, integration credential changes, security policy updates. |
| **Custom rules**   | Create / edit / archive / enable / disable per scope.                        |
| **Reports**        | Report generation requests, downloads, deletes.                              |

Audit events are append‑only; nothing in Blindsight ever rewrites or
removes a row from the trail.

## The Records page

The default view is a filterable, paginated table of events.

| Filter          | Values                                                                               |
| --------------- | ------------------------------------------------------------------------------------ |
| **Actor**       | Any user in the workspace, or `system` for automated runs.                           |
| **Action type** | `create`, `update`, `delete`, `scan_started`, `scan_finished`, `heal`, `login`, etc. |
| **Object type** | `dataset`, `scan`, `project`, `user`, `integration`, etc.                            |
| **Date range**  | Free‑form, with quick presets (today, last 7 days, this month, last quarter).        |
| **Severity**    | `INFO`, `WARN`, `CRITICAL`, useful for filtering down to security‑relevant rows.     |

Click any row to open the **record detail** with the full event
payload, a before / after diff, and metadata about who and where.

## Stats page

The stats view gives you trend analysis at a glance.

* Counts per actor, per action type, per day.
* A heat map of activity by hour and weekday.
* Top actions on the busiest day.
* "Parameter drift" charts (see below).

Useful for spotting spikes (a misconfigured pipeline burning quota)
and gaps (a scheduled scan that quietly stopped firing).

## Parameter analytics

A specialised view for compliance: see how scan parameters drift over
time. Pick an engine, pick a parameter (for example `confidence_floor`
or `sensitivity`), and the chart shows the value distribution across
every run. Auditors care because consistent practice = defensible
practice.

You can also **register custom parameter schemas** so the trail
captures your own domain‑specific knobs (`model_version`,
`clinical_protocol`, `reviewer_id`).

## Exporting and pushing

* **CSV export** of any filtered view, useful for evidence packs.
* **Ingest / import** of external audit events from a SIEM or another
  tool, merged into the unified timeline.
* **Audit webhook** that pushes events to your SIEM in real time
  (see [Integrations](/data-integrity/integrations) for setup).

## Common workflows

<AccordionGroup>
  <Accordion title="Investigate a deletion">
    1. Filter by **Action type = delete** and the date you know it
       happened.
    2. Click the row to see who triggered it and the parameter
       snapshot of the deleted object.
    3. Cross‑reference with the parent object's audit trail (scans
       and healings against that dataset) to assess the impact.
  </Accordion>

  <Accordion title="Prove that scans ran on a cadence">
    1. Filter by **Action type = scan\_started** and the period
       you're proving.
    2. Group by **Dataset** in the stats view to confirm coverage.
    3. CSV‑export and attach to the compliance report.
  </Accordion>

  <Accordion title="Detect credential abuse">
    1. Filter by **Object type = integration** and **Action type = update**.
    2. Cross‑check actor and date with your team's calendar.
    3. Any unexpected actor here is worth escalating.
  </Accordion>
</AccordionGroup>

<Warning>
  The audit trail is the workspace's source of truth for "what
  happened". If you suspect tampering, contact support immediately;
  the trail is append‑only at the application level and replicated
  at the storage level.
</Warning>