Help
The audit log
Every decision anybody made, with a name and a timestamp. Here is what lands in it, how to find the entry you want, and the limitation to know before you go looking.
What lands in it
Roughly thirty distinct actions across ten kinds of thing. Every document decision — approved, approved with an override and the reason given, rejected, manually overridden. Every change to what you require, at the organization level and per project. Every subcontractor created, edited or removed, including a bulk import as a single entry. Every project created, edited, archived or deleted, and every assignment and removal on one. Every reminder sent by hand, every upload link issued, every report requested, and every change to who is on your team and what they can do.
The pattern behind that list is worth having: the log records decisions and changes, not traffic. Somebody opening a screen is not an entry. Somebody changing what a screen means is.
There is one entry people are surprised to find, and it is deliberate: exporting the audit log is itself written to the audit log. A record whose whole purpose is showing what happened would be a strange place to allow an untracked read.
Finding the entry you want
The log fills up fast and reverse-chronological order stops helping within a week. Four filters narrow it: the kind of thing (a document, a project, a subcontractor, a requirement set), the specific action, and a date range with a start and an end.
The one that does the most work is filtering by a single record. Pick one document and you get its whole life in order — uploaded, read, flagged, argued about, approved with a named reason — which is the shape you actually want when somebody asks how a certificate ended up accepted. Reconstructing that from a date range is possible and unpleasant.
Every column sorts, including by action and by kind, so you can also read all of one action across a period — every override in a quarter, say, which is a fair question to ask yourself before an auditor asks it.
It records what a value became, not what it was
This is the limitation to know before you rely on the log for a specific question, and the screen says so rather than hiding it. An entry carries the new state. It does not carry the old one.
So if you want to know what your general-liability minimum was in March, the March entry will not tell you — it tells you what it was changed to. What you read instead is the previous change entry, which is what the value became last time, and therefore what it was until this one. The information is there; it is one entry earlier than instinct sends you.
That is worth building a habit around if you change requirements often. A change entry is a boundary between two periods rather than a description of one, and reading a run of them in order is how you get the timeline.
Who can read it, and why that is separate
Reading the log is its own permission, held by fewer roles than document approval. Somebody who reviews certificates all day does not automatically get to read the record of everyone else's decisions, including yours — which roles hold which permission sets out the split.
That separation is the point of the feature rather than an inconvenience. A log everybody can read is a log nobody feels watched by, and a log that only records other people's decisions is not a log.
Getting it out, and what makes it worth anything
The log exports as PDF, Excel or CSV, through the same pipeline as the compliance reports — reports and exports covers the mechanics, including what happens to all of it if you cancel. The export respects whatever filters you have applied, so an auditor asking about one job gets that job rather than everything.
The property that makes any of this worth keeping is that the application cannot change it. Update and delete on that table are revoked from the database role the software connects as, so from the app's side the record is append-only — the security page states the boundary precisely, including what it does and does not cover.
Which is the reason to prefer the log over a folder of generated PDFs. A report describes the moment you asked for it and can be regenerated at any time; the log is the thing that says what you did, and it is the artifact worth having when somebody disputes it. If that is the situation you are preparing for, what an insurance auditor actually asks for is the other half.
The record that says what you did, not just where you ended up.
Every decision, with a name and a timestamp, on a table the application has no permission to edit.
