What a signed approval contains

Editant Pro turns each reviewer decision into a signed record. This page describes what is in that record, how the signature works, and what it does and does not prove.

The payload

When a reviewer records a decision, Pro first takes a snapshot of the post content and computes its SHA-256 hash. It then builds a canonical JSON document with these fields:

• approval_id, post_id, link_id, reviewer_id: which decision, on which post, through which link, by which captured reviewer.
• decision: approved or changes_requested.
• message_hash: the SHA-256 of the reviewer’s message, so the message is bound without being reproduced.
• snapshot_id and content_hash: which snapshot of the content, and the hash of that content.
• created_at: the moment of the decision, in a fixed UTC format.

Canonical means the fields are always written in the same order and encoding, so the same decision always produces the same bytes. The signature is made over those bytes.

The signature

The site generates an Ed25519 keypair when Pro is activated. The private key stays on the site and is never exported; the public key is published at a REST endpoint on the site, along with any earlier keys that have been rotated out, so old approvals remain verifiable. Anyone holding the public key can check that the payload was signed by that site and has not changed since. There is nothing to share with them except the record and the public key.

The signed payload, the signature and the key identifier are stored alongside the decision. Retention windows never touch them: whatever is purged from comments, reviewer data or snapshots, the decision and its signature stay. Retention windows

The exports

PDF. A certificate per approval: the decision, the reviewer as captured, the time, the content hash, the signature, and a QR code that resolves to the site’s public-key endpoint. When you export several approvals together, each page carries its own signature and verifies on its own; the cover says so, because a single signature over a compilation would prove less.

JSON. The same records as data, for anyone who wants to verify by machine or feed a governance system.

Both come from the audit screen in the admin. Signed approvals and the audit log

What it proves, and what it does not

A signed approval proves that this captured reviewer recorded this decision about this exact content at this time, and that the record has not been altered since. It does not prove the content was correct, and it does not prove the reviewer is who they said they were beyond what identity capture asked for. Those remain matters of process, which is why the record exists: so the process can be shown.