The audit log
Alongside a sealed record’s own hash chain, the audit log is the contemporaneous story of everything that happened to a case — who touched it, when, and what changed.
What it is
Every privileged action against a case — creating a survey, every field-level change to it while still a draft, finalising, revising, withdrawing, a key minted or revoked, a permission grant — lands here as its own entry, with the entity it affected, the actor, and the timestamp. This is broader than the sealed evidence chain itself: it captures the edit history underneath a case, including drafting activity that never became part of the sealed record at all, giving you a fuller picture than the finalized record alone.
How to do it
- Open Evidence or Jobs, find the case you’re investigating, and use its own timeline link through to Settings → Audit log — or search the log directly by entity, entity ID, or the actor’s email.
- Filter by action type to isolate, for example, every finalise, revision or withdrawal against a specific property.
- Where an entry relates to a survey or work order, click through to open that record directly and cross-check it against what the log says happened.
- Cross-reference a suspicious gap or an unexpected actor against the case’s own stage rail (see The case lifecycle end to end) to understand the sequence of events, not just the isolated entries.
How it integrates
Each entry carries its own hash plus the previous entry’s, so the sequence itself is spot-checked for a broken link — the same tamper-evidence property a single sealed record demonstrates, applied to the log describing it. This is not the same claim as the sealed record’s own hash chain (see What “sealed” and “tamper-evident” mean) — it’s a second, independent trail: one proves the evidence itself hasn’t been altered, the other proves the story of who did what to get there hasn’t been either. Some entries record system as the actor for automated actions like the nightly integrity sweep, rather than a person.
Common problems
- I can’t see the audit log at all. It needs audit-module view access — switched on for coordinators and viewers by default, off for finance and field roles.
- An entry for an automated action has no named person. That’s expected —
systemis the actor for platform-triggered actions like the nightly integrity sweep, not a display fault. - I need to prove nothing was touched during a specific window. Search by date and entity — a clean stretch with no relevant entries is itself the evidence; there’s no separate “nothing happened” flag to look for.