Every governance action in PolicyCodex appends a row to a log that cannot be edited or deleted. Each row’s hash covers the previous row’s hash, so the whole history forms a chain that breaks visibly if anything is altered. This is the difference between “we have a standards wiki” and “we can prove which approved standard the agent was following on the day that code shipped”.
The audit log in Settings showing a verified hash chain badge and rows for role group, RFC and statement actions
Find it at Settings → Audit.

​
How the chain works

Each entry stores:
Because every hash incorporates its predecessor, changing any historical row invalidates every hash after it. A database trigger blocks UPDATE and DELETE on the table outright, so tampering requires defeating both the trigger and the mathematics.

​
Verification

The green hash chain verified badge is not a claim from the server. The browser downloads every entry and recomputes the whole chain locally with the same function the command-line verifier uses. If verification fails, the badge turns red and names the sequence number where the chain broke. You can run the same check independently against the API — see the REST API.

​
Reading the log

Newest entries appear first.

​
Actions you will see

rfc.proposed, rfc.reviewed, rfc.approved, rfc.enforced, rfc.deprecated, rfc.revision_saved, rfc.duplicated, rfc.archived, rfc.meta_changed
rfc.reviewer_assigned, rfc.approver_assigned
statements.extracted — written whenever extraction runs, whether triggered by approval or manually
domain.created, role_group.member_added, role_group.member_removed, and API key lifecycle events

​
Exporting

Export JSON and Export CSV download the complete log.

JSON

Includes every field, including full hashes. Use this when the export needs to be re-verified — the recomputation needs the complete canonical entries.

CSV

Flattened for spreadsheets and GRC tooling. Convenient for review; not sufficient for independent hash verification.
The same export is available over the API at GET /v1/audit/export, which is how you would wire PolicyCodex into a scheduled evidence collection job.

​
What the trail proves

For a given piece of code, you can reconstruct:
1

Which statement was cited

The violation record names a statement slug.
2

Which RFC revision it came from

The statement records the revision it was extracted from — and revisions are immutable, so that text is exactly what was approved.
3

Who approved that revision

The rfc.approved entry names the approver and the moment.
4

When it started blocking

The rfc.enforced entry names who promoted it and when — so you can tell whether a given merge predated enforcement.
5

That none of it was edited afterwards

The hash chain verifies.