Activity Monitoring

Sovrium records every meaningful action across the application — record create/update/delete, authentication events, and administrative operations — into a system-wide activity log. The log is queryable through an authenticated API with filtering and pagination, giving operators and auditors a single place to answer "who did what, when".

This is the operator-facing read surface over the platform's canonical audit-log event store. Each entry is immutable and outlives the rows it references where required for compliance (an account.deletion.purged event survives the erasure of the user who triggered it — see GDPR & Privacy).

What Gets Tracked

Each entry carries the action, the affected table and record id (when applicable), a timestamp, and the acting user (id, name, email). The actor reference is FK-linked with ON DELETE SET NULL so an audit entry remains a valid compliance record even after the actor's account is erased.

Querying the Activity Log

The activity API is admin-gated. Unauthenticated requests return 401; non-admin sessions return 403.

GET /api/activity?page=1&pageSize=20&table=orders&action=update

{
  "activities": [
    {
      "id": "act_123",
      "action": "update",
      "tableName": "orders",
      "recordId": 456,
      "createdAt": "2025-01-15T10:30:00Z",
      "user": { "id": "1", "name": "Alice", "email": "alice@example.com" }
    }
  ],
  "pagination": { "total": 150, "page": 1, "pageSize": 20, "totalPages": 8 }
}

Query Parameters

Retention

Activity entries are retained according to the platform retention policy. Soft-deleted source rows themselves age out per the ECO_RETENTION_PURGE_DAYS horizon (see Ecoconception), but audit entries required for compliance — notably erasure records — are preserved independently of the rows they describe.

Compliance Use

The same shape returned to admins is returned to auditors, so SOC2 / GDPR review documentation reflects exactly what operators see. Combined with the immutable canonical event store, the activity log provides the "audit trail of erasure" required when honoring a right-to-be-forgotten request: the deletion is itself logged, with the actor reference null-ified once the account is purged.

Related Pages

• Record History — field-level before/after diffs per record.
• Soft Delete — recoverable deletes and the deleted_at tombstone.
• Admin Dashboard — operator read API over the rest of the platform.
• GDPR & Privacy — erasure records and the audit trail of deletion.
• User Management — the admin actions that produce activity entries.