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 design 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 plant engineers 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 manufacturing customer can verify it without trusting the auditor.
Retention is where legal and security disagree. Security wants everything forever; privacy law for design files wants a reason for every month retained. Our compromise is to retain decisions in full for the audit period required by NIS2 and keep a hashed summary afterwards, so the chain stays verifiable while the personal data does not.
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 design files, start with the policy version. We are happy to compare schemas.