Most audit logs record what happened. Very few can answer why it was allowed. When an auditor or an incident lead asks why a particular person could read case files on a particular Tuesday, a log of events is a starting point for an investigation, not an answer.
An access event is only useful with four things attached: the identity that made the request, the device and context it came from, the policy version that evaluated it, and the approval chain if there was one. The Audit Vault stores all four with every decision the Evidence Engine makes. The policy version is the part most systems skip, and it is the part that turns a log into an explanation.
Storing the policy version means the log can be replayed. When a policy change is proposed, the Evidence Engine runs the last ninety days of decisions against the new version and reports what would have changed. A rule that would have blocked three hundred legitimate requests from associates is caught in review instead of on Monday morning.
Immutability is a property you prove, not declare. Our log is append-only, hash-chained, and anchored daily to an external timestamp. An auditor can verify that a record from March has not been altered without trusting us, and a legal customer can verify it without trusting the auditor.
Retention is where security and legal pull in opposite directions: one wants everything forever, the other wants a reason for every month that case files are kept. We settled on keeping full decisions for the GDPR audit period and a hashed summary afterwards, so the chain stays verifiable while the personal data does not linger.
The practical test we apply to every new feature is simple. Pick a random decision from last quarter and ask: can a new employee explain why it was allowed in under two minutes, using only the log? If not, the log is missing a field, and we add it.
If you are designing an audit log for case files, start with the policy version. We are happy to compare schemas.