Skip to main content
The audit trail (/compliance/audit) records who did what, when, to which object, with what parameters. It is append-only: nothing in Blindsight rewrites or removes a row. What makes it evidence rather than a log is the hash chain. Every record’s digest is SHA256(previous_hash | canonical_json(content)), so the records form a single chain in which altering any one record breaks every record after it. The chain head is tracked separately, and /verify walks the chain and reports what it finds.

​
What gets logged

​
Records

The default view is a filterable, paginated table. Click any row for the full event payload, before and after values, and the actor and origin metadata.
Severity is one of the hashed fields, so a record’s severity cannot be edited after the fact without invalidating its digest. Words from other subsystems are normalised on write (warn becomes medium, error becomes high, fatal becomes critical), so the vocabulary above is the complete set you will see.

​
Verifying the chain

GET /api/audit-trail/verify runs the tamper-evidence check and returns {ok, checked, broken_at, ...}. ok is exactly “no issues found”; when it is false, the response always names at least one issue. Two things about it are easy to misread:
The hash chain is global, so it cannot be scoped to one tenant. The verdict reports counts and record identifiers from every workspace on the deployment. The response says so in its scope field rather than letting you assume otherwise.This is why verification has its own permission, compliance.verify, held by admin and compliance-auditor rather than travelling with compliance.access.
Migration 0114 brought the workspace id into the hashed payload and recomputed every existing digest. Without an attestation, hashes that no longer match an older export would be indistinguishable from tampering, and tampering could be passed off as the rehash. The verdict carries a rehash field naming the event, and the pre-rehash digest is retained so it stays checkable rather than merely stored.

​
Applications and parameter schemas

Two related surfaces sit on the same API. Applications register the systems whose activity you are auditing, so records can be attributed to an application and reviewed per app on /compliance/applications. Parameter schemas let you register your own domain-specific knobs (model_version, clinical_protocol, reviewer_id) so the trail captures them as first-class, filterable fields rather than free-form payload. Parameter analytics then charts how a parameter’s values drift across runs, which is the shape of the “consistent practice” question an auditor actually asks. Managing applications and parameter schemas needs compliance.manage.

​
Export, ingest, and SIEM

For real-time delivery, configure the audit webhook and every record is pushed to your SIEM as it is written. See Integrations & webhooks.
Export honours the full filter set, including control_standard and control_id. Filtering to a single control and exporting is the fastest way to answer “show me your evidence for A.8.15”.

​
Reading it requires a license

Audit trail reads are gated on the Compliance license alongside the rest of the product. Reads need compliance.access; writes, imports, applications, and parameter schemas need compliance.manage; chain verification needs compliance.verify.

​
Common workflows

  1. Filter to the delete event type and the date it happened.
  2. Open the row to see who triggered it and the snapshot of the deleted object.
  3. Cross-reference the parent object’s records (scans and healings against that dataset) to assess impact.
  1. Filter to scan-start events over the period you are proving.
  2. Check coverage per dataset in the stats view.
  3. Export to CSV and attach it to the compliance report.
  1. Set control_standard to the framework and control_id to the control.
  2. Confirm the record count looks right in Records.
  3. Export that exact view.
  1. Filter to integration entities and update events.
  2. Cross-check actor and date against your team’s calendar.
  3. Any unexpected actor here is worth escalating.
The audit trail is the workspace’s source of truth for what happened. If /verify reports a broken chain, treat it as an incident: capture the verdict, do not delete or re-import anything, and contact support.