Roles, goals, permissions, and expected behaviour for every consumer of the Audit module.
Permission values are exact from rbac/schemas/role.schema.ts (DEFAULT_ROLES) and
rbac/permissions.constants.ts:54 (audit.read). Critical nuance: the server enforces
onlyJwtAuthGuard on GET /audit-logs (audit.controller.ts:9) — audit.read is
metadata today; the client gates on it anyway (Phase-5 (planned),
docs/IMPLEMENTATION_PLAN.md:241; OQ-5 in 01).
Not a first-class identity today — backend has no auditor persona (only `user
Goal
Verify no unauthorized change occurred; spot-check entries against school records
Expected
Same list/detail UI; must be able to prove integrity ("never modified") — UI communicates immutability (no edit/delete affordances, timestamp authority)
permissions: [] but JwtAuthGuard sets isPlatformAdmin=true when role present (jwt-auth.guard.ts:54) — bypasses seed
Frequency
On-demand support / incident response
Goal
Cross-tenant visibility: did tenant X see tenant Y's data? correlate incidents via correlationId
Restrictions
Platform audit entries (tenantId: null, actorType: platform) are not implemented (AUDITING.md:70-71 vs audit-log.schema.ts:7-11) — cross-tenant audit UI is (planned) (OQ-3)
Expected
Read the tenant's audit log with a tenant-scoped token; per-tenant navigation (planned)
Note: until the Phase-5 permission audit lands (docs/IMPLEMENTATION_PLAN.md:241), the
server allows any authenticated user to read the tenant audit trail; the client hides
the surface unless audit.read is present. Flag to security owner (OQ-5).