How a release is verified and signed

This walks through the regulated release flow: how TRACE ALM aggregates a release candidate’s evidence bundle, what is signed (and what is not), and how the bundle is committed to the Design History File.

End-to-end sequence

Step 1 — Cut the release candidate

A release candidate is a specific commit on main (typically tagged v0.X.Y-rc.N). All the regulated content (regulatory-docs/, changes/, stamped REVIEWED_HASH) is what’s on that commit.

Verify before cutting:

# All requirements should be in `reviewed` state — no drift, no suspect
uv run python -m tools.post_processor.rtm --no-allure --fail-on-suspect

# All requirements with a `verifies` test should have green test results
uv run python -m tools.post_processor.rtm
# Open the RTM and visually scan for any red badges

If anything is unreviewed, suspect-native, or suspect-inherited, do not cut the release. Resolve those items first via the add-requirement or change-baselined-requirement workflows.

Step 2 — Run the release build

The release build workflow (main_branch_builds.yml and similar) builds the installer with release-mode flags, runs the full UT/IT/ST suite, and produces the release evidence bundle:

Artefact	Source
StrictDoc HTML RTM	post-processor render of regulatory-docs/
Allure dashboard	allure generate over the run’s allure-results
Coverage HTML	from Dart test coverage runs
JUnit XML	raw test output
index.json	post-processor’s master list of every regulated UID and its current state
Signed bioflow_pro.exe	the installer built and code-signed
SHA256SUMS	hashes of every shipped binary

The bundle is uploaded as a single CI artefact, retention 30+ days. For long-term storage it’s also pushed to the Design History File system.

Step 3 — Sign the release-record manifest with Signet

This is the formal 21 CFR Part 11 signature step. Signet is the tool that captures it.

The bulk of Signet’s documentation — installation, signer enrollment, the signing UI, signature-manifest format, key management, verification — lives on the Signet site at <SIGNET_DOCS_URL>. For the actual signing UX and Signet specifics, read that site.

For TRACE ALM, the integration points are:

1. The release manager exports the release evidence bundle’s content hash (typically the SHA-256 of a tar of the bundle, but Signet defines the exact canonicalisation)
2. The designated signer (with a Signet-enrolled key) signs the release-record manifest using Signet’s signing UI, capturing:
   • Their identity (per Part 11 §11.10(j))
   • The intended meaning of the signature (per Part 11 §11.50 / §11.70)
   • The bundle’s content hash being signed
   • The timestamp
3. Signet writes the signature manifest to signatures/release-vX.Y.Z.json
4. The manifest is committed to the repo via a normal PR (CODEOWNERS-gated), forming the auditable record

The same pattern applies to formal verification records that aren’t release-bound — see Signet’s site for the full taxonomy.

What auto-stamp doesn’t do (and why Signet is separate)

Auto-stamp’s REVIEWED_HASH records content-level approval at the per-PR level. It is not a 21 CFR Part 11 signature for several reasons:

Property	Auto-stamp REVIEWED_HASH	Signet signature
Captured signer intent?	No (implicit “I approve this PR”)	Yes (explicit signing prompt with stated meaning)
Independent signature manifest?	No (lives inline in the .sdoc file)	Yes (separate manifest with hash chain)
Tied to a regulated approval event?	Per-PR	Per-release / per-verification-event
Survives independent of the underlying tool?	Hashes survive but the chain to the approver requires GitHub’s audit log	Yes (Signet manifests are self-contained)

Both layers are needed: auto-stamp gives FDA the chain of content approvals during development; Signet gives FDA the formal signed approval at release.

Step 4 — Archive the bundle

The release evidence bundle plus the signed manifest are archived to the Design History File:

• Long-term retention beyond GitHub Actions’ artefact retention
• Per-release bundle is immutable
• Verification: any auditor with the bundle, the public key, and Signet can re-verify the signature against the bundle’s hash

The exact archival mechanism (S3, on-prem storage, etc.) is defined in the project’s record-keeping procedure.

Verifying a signed release later

Given a bundle on disk and the signature manifest:

# Documentation for this command lives on the Signet site
signet verify --bundle <path> --manifest signatures/release-v0.1.0.json

A successful verification proves: “this bundle’s content matches the hash that was signed by this signer at this time.” That’s the audit-trail anchor connecting a deployed binary back to the formal release approval.

When this workflow does not apply

• Pre-release internal builds — no Signet signature required; only auto-stamp records
• Hot-fix patches that don’t change requirements — the requirements baseline is unchanged; only the build needs re-signing
• Documentation-only releases (e.g. updating only the customer-facing site) — out of scope for TRACE ALM

For the canonical list of which artefacts require Signet signatures, see the Part 11 signature strategy page.