Approving a release

Approving a release is the moment a bundle of work becomes an official, shippable version. It’s a deliberate, authenticated act made against the evidence the release has assembled — not a status someone flips.

Approving against the evidence

A release is approved on the strength of its readiness — the gates it has passed and the blockers it has cleared. Approval isn’t separate from that evidence; it’s the judgment that the bundle is complete and sound. Because the gates are computed from the actual items, tests, and documents, the approver is signing off on a real, verifiable state rather than an assertion.

An authenticated signature

Approving a release applies a 21 CFR Part 11 electronic signature. The approver authenticates with their username and password at the moment of approval, states the meaning of the signature, and records a reason for it. This binds the approval to an identified person, with a trustworthy timestamp and a clear statement of what they’re attesting to — the same signing model used throughout the platform (see Approvals & e-signatures).

What ships is what was approved

Because an approved release is controlled and its items are locked, the version that goes out is exactly the one that was signed off. There’s no gap between “approved” and “shipped” where content could change unnoticed. If a change is genuinely needed after approval, it’s handled through a new version, and the release record shows the full history of versions and their approvals.

A defensible record of what shipped

The result is a complete, signed record for every release: what was in it, the evidence it was ready, who approved it, when, and why. That record is exactly what a submission or an audit asks for — demonstrable proof that what you shipped was reviewed, verified, and authorized. It also feeds the release documents and reports described in the Reports section.