admin_audit_log
This table stores the immutable, append-only audit trail for super-admin actions performed through DirtView’s internal admin systems. It is one of the highest-trust tables in the platform.
Purpose
The purpose of this table is to preserve a tamper-resistant record of all high-privilege platform actions taken by super-admins, including tenant lifecycle changes, feature-flag changes, impersonation, and other cross-tenant operations.
What this table does
- Records privileged platform actions by super-admins
- Captures who did what, when, and to which target
- Stores optional before/after state for sensitive changes
- Supports operational forensics, trust, and compliance readiness
Why this table is defined
Super-admins have cross-tenant authority and access to the most sensitive operational controls in the platform. A normal tenant-scoped audit trail is not sufficient. These actions must be captured separately in a service-role-protected log.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id | uuid | Yes | Primary key for audit row | aaudit_001 |
super_admin_id | uuid | Yes | Super-admin who performed the action | sadmin_001 |
super_admin_name | text | Yes | Denormalized admin name at write time | Alice Johnson |
action | text | Yes | Machine-readable action code | admin.tenant_suspended |
description | text | Yes | Human-readable description | Alice suspended tenant BuildRight GC |
target_tenant_id | uuid | No | Tenant affected by the action | tenant_002 |
target_user_id | uuid | No | User affected by the action | user_456 |
before_state | jsonb | No | Optional state before the action | {"status":"active"} |
after_state | jsonb | No | Optional state after the action | {"status":"suspended"} |
ip_address | text | No | Origin IP address | 203.0.113.10 |
created_at | timestamptz | Yes | When the action occurred | 2026-04-11 16:00:00+00 |
Relationships
- super_admin_id → super_admins.id
- target_tenant_id → tenants.id
- target_user_id references the affected platform user where applicable
How it is used
- Written whenever a super-admin performs a platform-level action
- Used for forensic review, support, and internal accountability
- Queried only through internal admin systems or trusted operational tooling
- Can support external archive/backups for maximum tamper resistance
Access and security
- This table must be immutable and append-only
- No UPDATE or DELETE path should exist
- Service-role only access is strongly recommended
- High-trust backups or append-only archival storage are recommended
- This table should never be exposed via public client APIs
Immutable here means once a row is inserted, it cannot be edited or removed.
Example scenarios
Scenario 1: Tenant suspension
A super-admin suspends a tenant and the state change is recorded permanently.
Scenario 2: Feature flag override
A super-admin enables a beta feature for one tenant, and the action is logged here.
Scenario 3: User impersonation
An internal support session begins and the impersonation event is captured in this log.
Notes and assumptions
- This is the platform-level counterpart to tenant-scoped
audit_log - Human-readable descriptions should be generated when the event is written
- Keep this table small in schema shape but strong in integrity guarantees