Audit log coverage

Wisteria’s audit log is the canonical record of changes in your workspace. This page details what it captures and what it doesn’t — so you can decide whether it meets your compliance requirements.

For the user-facing audit log viewer, see Audit log.

What’s captured

Every consequential change. A change is “consequential” if a regulator, auditor, or compliance officer would ever ask “who did that, when?”

Content changes

course.create / .update / .publish / .archive
module.create / .update / .publish / .archive / .delete
module.ready_for_review_at toggle
Flashcard create / update / delete
Quiz question create / update / delete

Approval flow

module.submit_for_approval
module.approve / .reject (with reviewer + comment)
approval.query / approval.query_reply
module.resubmit_after_rejection
Workflow definition changes

User & access

user.create / .deactivate / .delete
user.role_change (with before/after roles)
user.department_change
assignment.create / .delete

Workspace settings

company.update (any field change)
department.create / .update / .delete
tag.create / .update / .delete
notification_settings.update
certificate_template.update
ai_training_profile.update

Integrations

integration.connect / .disconnect / .reverify
integration.scan_triggered
ai_suggestion.create / .dismiss / .mark_not_training
ai_suggestion.generate_course

Learner activity (audit-level)

quiz.attempt (pass/fail + score)
quiz.pass (final completion)
course.complete
certificate.issue

What’s NOT captured

Read events. Viewing a course, listing the user roster, opening a flashcard — these don’t create audit entries. The audit log is changes, not access.
Authentication events. Sign-in, sign-out, password resets. These are tracked separately by Supabase Auth and visible to Wisteria support but not in the workspace’s audit log viewer.
Drafts. Edits to a draft module that’s never been submitted don’t generate detailed entries; the audit log captures the eventual submit, not every intermediate save.
Browser-side actions that don’t hit the database (e.g. expanding/collapsing a section, scrolling).

If you need any of these tracked at audit-log level, talk to support. Some are technically possible but currently off by default for noise reasons.

Entry structure

Every audit entry has:

Field	Purpose
`id`	Unique entry ID
`created_at`	Timestamp (UTC)
`actor_id`	The user who triggered the action
`actor_email`	Snapshot of their email at the time
`actor_name`	Snapshot of their name at the time
`action`	The dotted-namespace action (e.g. `module.publish`)
`resource_type`	What was changed (course, module, user, etc.)
`resource_id`	The ID of the resource
`resource_name`	Snapshot of the name at the time of action
`meta`	Optional JSON blob with action-specific details
`company_id`	The workspace this entry belongs to

The resource_name snapshot is important: if a module is later renamed or deleted, the audit entry still shows the historical name. You won’t see “renamed away” UUIDs without context.

Retention

Audit log entries are retained indefinitely by default. Wisteria doesn’t auto-delete history.

If your organisation requires a retention limit (e.g. delete after 7 years), contact support@getwisteria.com. We can set up a retention rule for your workspace.

Deleting an audit entry directly isn’t supported via the UI — it’s deliberately hard to do. If you need an entry redacted for legitimate reasons (GDPR right-to-erasure on the actor field, for example), contact support; we have a documented redaction procedure.

Tamper resistance

Audit log writes happen via Wisteria’s service role. The audit_logs table is:

RLS-protected on reads — only super_admin + auditor can SELECT
Write-only from app code — application code can INSERT but not UPDATE or DELETE
Indexed for efficient filtering

The combination means a normal app user can’t tamper with the log. A determined attacker with database-level access could; we depend on Wisteria’s infrastructure-side controls (IAM, audit logging of database access, etc.) to prevent that.

For genuinely high-stakes compliance, talk to us about WORM (write-once-read-many) export to S3 Glacier or similar archival storage. We can set up an export pipeline.

Exporting

The audit log viewer supports Excel export of up to 2,000 filtered entries. For larger exports:

Up to 10,000 entries — contact support; we’ll generate a one-time CSV.
Bulk historical export (e.g. for legal hold) — contact support; we can dump the full audit log for your workspace in JSON or CSV.

What if the audit log has a gap

Two scenarios:

Action you took isn’t visible in the log. Most likely the action wasn’t in the audit-action vocabulary. Tell us; we’ll add it. Some routes ship without audit calls and get backfilled.
Action shows wrong actor. Should never happen. If it does, file a security report — could indicate a session-handling bug.

Per-customer compliance attestations

For SOC 2 Type II, ISO 27001, HIPAA, or similar attestations Wisteria is working toward, the audit log’s evidence trail is part of the compliance package. Customers under those frameworks can request:

A read of the audit log policy (Postgres-level)
A sample audit entry walkthrough
A demonstration of an attempted tamper that fails

Email security@getwisteria.com for the full audit attestation kit.