When signing is worth turning on
- Use it when customers should be able to verify public release notes for themselves.
- Use it when compliance, legal, or audit teams need proof of published history.
- Skip it for now if you do not need verification and just want a normal changelog workflow.
What signing does in plain English
Each time a published post is created or edited, Chainlog records the exact published revision, links it to the previous signed revision for your workspace, and signs that record with your workspace's active key.
The result is a verifiable history. A reader can check both the content of that revision and where it sits in the sequence of published changes.
What gets signed and what does not
- The full published revision snapshot, including content and key publishing metadata.
- The revision number and signing timestamp.
- The previous chain hash, so each signed revision links to your workspace's prior signed revision.
Draft edits are not signed. Signing only happens when content is published or when an already-published post changes.
What readers can verify
- The signature is valid for the signed payload.
- The signed payload matches the published revision being shown.
- The revision links correctly to the previous chain node.
- The revision history is complete within the exported history bundle.
Human-readable diffs are included for convenience, but the proof is over the full immutable revision snapshot, not just the visible diff.
Verification modes
Off
No signing, no verification page, and no reader-facing verification badge.
Team-visible
Published revisions are signed, but verification is limited to signed-in team members and approved reviewers.
Reader-visible
Published revisions are signed and anyone who can see the entry can open its verification page.
Use visibility settings to decide who can read the proof. You do not need separate auditor keys. Your workspace signs, and readers verify with your workspace's public key.
When to choose team-visible vs reader-visible
| Situation | Recommended mode | Why |
|---|---|---|
| The changelog is public and customers should be able to verify posts themselves. | Reader-visible | Best for transparent public release notes, trust pages, and customer-facing auditability. |
| The changelog is customer-facing, but verification should only be visible to staff or invited users. | Team-visible | Keeps the cryptographic proof available without exposing internal verification details to the public. |
| An external auditor needs access, but they can receive normal read-only workspace access. | Team-visible | Access control stays separate from signing. The tenant signs; the auditor verifies. |
| The team does not need cryptographic proof yet. | Off | Simplest option when verification is not part of the product, compliance, or trust workflow yet. |
Key management and trust model
- Each workspace has its own signing key pair.
- The public key can be shared with auditors and verification tooling.
- Admins can rotate signing keys without breaking older signatures.
- Older revisions remain verifiable against the key version that signed them.
In practice, this gives you proof within the normal Chainlog trust model. If you later want a stronger external trust anchor, you can anchor chain heads outside the app, but that is optional and separate from everyday verification.
How to run it day to day
- Choose whether verification should be off, team-visible, or reader-visible for the workspace.
- Publish posts normally. Chainlog signs each published revision automatically.
- Review recent signed revisions in Dashboard → Signing.
- Rotate keys when your security policy requires it, then let downstream verifiers fetch the new public key.
- Share the verification page or export bundles when a customer, auditor, or compliance team asks for proof.
Where to send people next
Share the reader-facing guide when someone needs to understand what the verification page means or how to validate a post.