Three audit conversations
One
A regulator asks: "What did your published policy say on the day of the filing?"
You search git for that day's branch. The branch references a templated build. You find the template, but the layout has been redesigned twice since. The PDFs from that day are in three places, possibly tampered with, definitely unsigned. You spend two weeks building a defensible answer.
Two
Legal asks: "Show me every change to this disclosure between Q3 close and the regulatory submission, with the person who made each change."
You search git log. It's by file, not by content. You correlate commits to the editor's name. There's a redirect from marketing's CMS to legal's wiki and you're not sure which was canonical when. You spend three days reconstructing.
Three
Compliance asks: "Did this runbook get edited after the approval?"
The CMS has no idea. The wiki tracks edits but lost the approval timestamp. You have to dig through email to find the approval thread. The thread references "the version we discussed" — which version? You can guess; you can't prove.
What changes
When the CMS is the audit trail by construction:
- Every change is a fact, with timestamp and actor, recorded once at write time. Not reconstructed from logs.
- Approvals are bound to the version they cover. Edit after approval, the approval goes stale automatically.
- "Render the page as it appeared on March 14th" is a query.
- The audit history can't be edited later. Tamper-evident by design.
- Late corrections preserve the original.
The auditor doesn't have to trust your CMS — they can verify the export offline.
Why we made this the foundation, not a feature
You can't add this to a CMS later. The data model has to be designed for it from the start.
We started here.
See the compliance use case → · Talk to us about a regulated-industry trial →