Audit & Forensics
Two distinct trails, deliberately kept apart: business history answers "what happened to this object?", the forensic layer answers "what exactly happened on this request?" -- linked by a correlation ID, never conflated.
Volume, recent activity, breakdown and tamper-evidence proof for the institution's audit trail.
A trail that never changes
The audit trail is insert-only. There is no update, no delete, no bulk action, and there never will be: mutability would destroy the evidentiary value that is the whole point of this trail. The database itself refuses updates and deletes on these tables -- this isn't just a screen that happens to omit the buttons.
- Every row carries the fingerprint of the previous one -- a verifiable chain
- Any tampering after the fact would be detected, not just forbidden
- Coverage shown honestly: 93.68%, not rounded up to 100
Forensic view -- one row per HTTP request: origin, location, session, client, and the exact request and response.
A separate, more confidential forensic layer
The forensic layer answers a different question from business history: what exactly happened on this request. Authentication secrets are hashed and never stored in plain text; an oversized body is visibly truncated. This trail is deliberately entrusted to fewer people than business history, and kept for a shorter time -- a missing row often means it was purged, not that nothing happened.
- One row per request: IP address, location, session, client
- Authentication secrets hashed, never in plain text
- Retention deliberately shorter than business history
Full-text search and facets over business history, always within a bounded time period -- CSV export available.
Search, filter, export -- never rewrite
Full-text search, filters by action, object type, actor and outcome, chronological sort by default -- because an auditor's question is "what happened, in order", and relevance-based sorting would hide the neighbouring events that give an incident its shape. The CSV export deliberately omits each event's payload: it frequently contains students' personal data.
- Full-text search and facets, always within a bounded period
- Chronological sort by default, not relevance-based
- CSV export that deliberately protects personal data
