"Which cut did we actually approve?" is not a workflow question - it is an audit question, and by the time someone asks it (a client dispute, a re-brief, a compliance review), reconstructing the answer from email threads and Slack history is a lost cause. An audit trail is the record you build during review instead: every version with a timestamp, every comment with an author, every resolved thread, every approval with a name on it. Here is what that record should contain, how to build it round by round, and - honestly - what it cannot prove.
What the record contains
| Event | Recorded as | What it proves |
|---|---|---|
| New cut uploaded | Version with timestamp in the version stack | What existed, and when it changed |
| Feedback given | Comment with author, timestamp, and timecode | Who said what, where in the cut |
| Note addressed | Thread resolved (with resolver) | The note was handled, not ignored |
| Decision made | Approval action on a named version | The actual decision - which cut, which person, which date |
| Link visited | View count on the review link | The material was seen (counts, not per-viewer watch analytics) |
That last row has an honesty line worth holding: view counts tell you the link was opened, not who watched what for how long - per-viewer watch analytics is a different (and more invasive) product than most teams need, and claiming it when you only have counts is exactly the kind of overclaim that destroys an audit trail's credibility.
Why teams need it
Three situations pay for the record, in ascending order of pain:
- The dispute - "we never approved that version" ends the moment you open the version stack: there is the approval, with the name and the date.
- The re-brief - six months later, a new stakeholder asks why the opening changed. The resolved threads replay the reasoning without a single meeting.
- The compliance context - regulated teams need to show who signed off on what, when. The audit trail is the video-side answer to what document approval workflows already do; the regulated-industries specifics are in video review for regulated industries.
The creator-economy version is the same mechanism with money attached: approval recorded before the ad spend flows - the UGC approval loop runs on exactly this record.
Building it round by round
The audit trail is a byproduct of two habits, not a documentation chore:
- One round = one version + one consolidated note set + one named approver. Upload the round's cut as a version (the stack builds itself - versioning, complete guide), consolidate the notes into one set (how to consolidate client notes), and have the actual decision-maker mark approval on that version.
- Approvals happen on the link, not in email. An approval buried in an inbox is an audit trail with a hole in it - the version-level approval action is the record; review link vs email attachment is the argument for why. If stakeholders insist on replying by email, the round is not closed until the approval is recorded where the versions live.
The honest limits
Three things an audit trail is not:
- Not a contract. It evidences workflow decisions; it does not replace the approval clause in your agreement - clause 3 in the contract-clauses guide defines approval in terms the record can satisfy.
- Not automatically permanent. Platform records have retention realities. If longevity matters, export the record (comments, statuses, versions list) at the milestone and file it with the project archive - the archive step belongs in the offboarding checklist.
- Not tamper-evident by default. A status can be changed again later; what you keep is the history the platform shows, not an immutable ledger. Teams with hard immutability requirements should say so during tool selection and get the answer in writing - the same rule as SSO and residency questions (enterprise requirements).
FAQ
Does an email approval count as approval?
Legally it can evidence consent - but as an audit record it is weak: untied to a specific version, easy to lose, and hard to reconstruct later. Best practice treats email as a trigger: the round closes when the approval is recorded on the version itself.
Can clients see the audit trail?
The shared parts - versions, comments, threads, statuses - are visible to the people on the review; that shared visibility is half its value, because it settles questions while the project is still live. Internal analytics like view counts are typically for the team, and full historical exports are the team's to make.
How long should we keep review records?
At minimum, through the project's warranty or dispute window; for regulated work, whatever the compliance regime requires. The practical habit: export the record at delivery and archive it with the project so retention does not depend on the tool.
What is the difference between an audit trail and an audit log?
An audit trail is the reconstructable story of decisions (versions, approvals, resolutions); an audit log is the system-level event record underneath it. Teams choosing tools for compliance usually need both questions answered - trail for the workflow story, log for the security story.
Who counts as the approver when two people comment?
Whoever holds the approval role - which is why naming the approver per round matters. Comments are input; the approval action is the decision, and it should carry exactly one accountable name per round. The approval workflow guide covers setting that up.