Background on why some ConvergeQA audit reports display a "signature regenerated" banner.
Every ConvergeQA audit report is signed with an HMAC-SHA256 signature computed over its content hashes, report ID, and timestamp. The key used to compute those signatures is an environment variable called AUDIT_SIGNING_KEY.
Prior to April 17, 2026, that key was not persisted across deploys of the application. Each time Elastic Beanstalk restarted the server — whether for a code deploy, a configuration change, or an instance replacement — a new in-memory key was generated, silently invalidating every signature issued under the previous key. The underlying review content (panel transcripts, input/output hashes, history records) was never affected; only the HMAC over that content became unverifiable.
On April 17, 2026, AUDIT_SIGNING_KEY was moved to a persistent Elastic Beanstalk environment property. All audit reports issued after that date are signed with a stable key and remain verifiable across deploys and restarts.
For reports issued before April 17, 2026, the original signature can no longer be recomputed because the key that produced it is gone. To restore verifiability of historical reports without re-running the underlying reviews (which would create new report IDs and break external references), ConvergeQA provides an admin-only re-sign operation.
Re-signing recomputes the HMAC over the existing, unchanged signed payload — the same input_sha256, output_sha256, report_id, and original iso_timestamp — using the current persistent signing key. A signature_regenerated_at timestamp is recorded on the row, and the verify page displays a banner disclosing the regeneration.
In other words: the content you are verifying is byte-identical to what was reviewed. The signature shown is a fresh HMAC over the same fields, produced under the key that is now stable.
The following are unchanged by a signature regeneration:
· The report's report_id (so existing links — YouTube descriptions, outlines, ministry-facing references — continue to work).
· The input and output SHA-256 content hashes.
· The original review timestamp, model panel, findings, and transcript.
· The verification URL at /verify/<report_id>.
The only field that changes is the HMAC signature itself, plus the new signature_regenerated_at disclosure timestamp.
Because ConvergeQA's verification page is meant to be a trust layer, a silent backfill would undermine the premise: "this signature was valid the whole time." It wasn't. Displaying the regeneration event explicitly — with both the original and regenerated timestamps visible — keeps the verify page honest about what a third party is actually looking at.