How the audit chain works, and what it proves

A signed approval proves one decision. The audit chain proves the history around it: that the events happened in this order, that none were altered, and that none were removed.

One row per event

Pro writes a row to its audit log for every state change: link.created, comment.created, decision.recorded, suggestion.created, suggestion.accepted, suggestion.rejected, suggestion.withdrawn, invitation.sent, retention.applied, and the AI assistant’s actions. Each row records the event type, the actor (a WordPress user, a reviewer, or the system for scheduled work), a sequence number, the event’s own data, a timestamp in UTC, and a hash.

The chain

The hash is a SHA-256 over the row’s sequence number, event type, actor, data, timestamp, and the hash of the previous row. Because each row includes the one before it, the rows form a chain. Change any field in any row and its hash no longer matches; the next row’s hash, which included the old value, no longer matches either, and so on to the end. Delete a row and the sequence has a gap and the following hash cannot be reproduced.

Verification is a single pass from the first row to the last, recomputing each hash and comparing. Editant runs it from the audit screen with one click and reports either that the chain is intact or the exact sequence number where it breaks. Anyone with an export of the log can run the same computation without Editant, because nothing in it is secret. Signed approvals and the audit log

The gap an internal log cannot close

A chain inside your own database has one weakness: someone with full access could delete the whole log and rebuild a shorter one that is internally consistent. The defence is to put the chain head, the sequence number and hash of the latest row, somewhere the site does not control.

Pro does this two ways. An attestation digest goes by email on a daily, weekly or monthly cadence to the recipients you set, stating the head sequence, the head hash and the number of events in the period. A signed webhook posts each event, or a daily batch, to an endpoint you supply, signed with HMAC-SHA-256 so the receiver can check it came from your site. Either way, an outside record exists of where the chain stood on a given day. A chain that later ends earlier than a published head, or whose hash at that sequence differs, has been rewritten. Attestation digests and webhooks

What is never purged

Retention windows age out comment text, reviewer personal data, content snapshots and suggestion text. They never touch the audit log, the signed decisions or the signing keys. A retention sweep is itself an event in the chain, so even the fact of a purge is recorded. Retention windows

Answering an examiner

“Who approved this page, and when?” Filter the audit log to the post; the decision.recorded rows name the reviewers and times. Export the signed approvals as PDF; each certificate carries the content hash and verifies against the public key. Run the chain verification and show it intact. Produce the attestation digest for the period, whose head matches a row in the log. Four artefacts, none of which required the examiner to trust the person producing them.