Most regulated release processes have three hard gates: Ready for DEV, Ready for VAL, and Ready for PROD.
The names are familiar. What actually gates each one — and what happens when a release fails to pass — is where most teams get it wrong.
This guide walks through what each gate means, what must be true before a release can promote, and how the gate model prevents the failure mode every QA team has lived through: a release that reaches production with unresolved documentation.
What a stage gate is
A stage gate is a defined point in the release lifecycle where the release cannot proceed until specific conditions are met.
The two words matter separately:
- Stage — the release moves through ordered states. DEV is a stage. VAL is a stage. PROD is a stage.
- Gate — the transition between two stages requires verification. Not a sign-off that "looks reasonable." Verification that defined criteria are met.
A stage gate is not a milestone. A milestone is a reporting point. A gate blocks progression.
The distinction matters because most broken release processes have milestones, not gates. Teams say "we're ready for VAL" the same way they say "we're 80% done" — as a status update, not as a verified condition.
A proper gate is a query: is every document due by this gate approved? If the answer is no, promotion fails. Not delays. Fails.
The three gates in context
The classic regulated release lifecycle has three gates, each associated with a different environment.
| Gate | Transition | Environment | Purpose |
|---|---|---|---|
| Ready for DEV | Planning → In Progress | Development | All pre-development documentation is approved |
| Ready for VAL | DEV Deployed → VAL Deployed | Validation | Development verification evidence is signed |
| Ready for PROD | VAL Deployed → PROD Deployed | Production | Validation is complete; release is authorised |
Each gate has:
- A responsible signer (Release Manager for DEV readiness, QA Approver for VAL and PROD readiness)
- A set of documents due by that gate
- A document gate check performed before promotion is allowed
- An audit record of who signed, when, and with what meaning
Let's walk through each one.
Ready for DEV gate
When it fires: After the release is created and started, before any development work is treated as "in flight" for the release.
Who signs: Release Manager.
What must be true:
- Every document marked "Required by DEV" in the matrix is Approved.
- Every conditional document due by DEV has an applicability decision recorded — needed or not needed — with a justification and electronic signature.
- Documents decided "Not needed" are recorded as Not Required and count as complete.
Typical documents due at this gate:
- Change request
- User and functional requirements specification
- GxP assessment
- Risk assessment
- Regulatory assessment
- Impact assessment
- Validation plan
What blocks the gate:
- Any required document still in Draft, In Review, or Reviewed status
- Any conditional document without an applicability decision
- Any document whose file changed after submission (fingerprint mismatch)
What happens if you fail: The release stays in In Progress. Nothing else advances. The Release Manager cannot sign the gate because the system refuses the signature until the document gate check passes.
This is the point most teams resist. They want the gate to be a judgment call. It isn't. It's a query.
Common failure mode: Conditional documents that never received a decision. This is the single largest source of DEV-gate delay in regulated teams. Not rejections. Not missing approvals. Undecided conditionals.
Ready for VAL gate
When it fires: After DEV deployment is recorded, before validation work begins in earnest.
Who signs: QA Approver.
What must be true:
- All documents due by the VAL gate are Approved.
- Every conditional document due by VAL has an applicability decision.
- The QA Approver signing the gate is a different person from the Release Manager who recorded the DEV deployment.
Typical documents due at this gate:
- Configuration baseline
- System design specification (SDS)
- Test plan
- Code review checklist
- Unit testing evidence
- Qualification plan (IQ/OQ/PQ)
- Network environment design
- Traceability matrices
- Installation Qualification (IQ)
- Operational Qualification (OQ)
What blocks the gate:
- Any VAL-gate document not approved
- Any unsigned conditional decision
- Same person attempting both DEV deployment and VAL gate approval
A note on SDS, IQ, and OQ: These are not DEV-entry blockers in most matrices. They must be approved by the Ready for VAL gate — which gives the team time to draft them while development proceeds. But they cannot be pushed past VAL. This is a common matrix design point: not everything needs to be ready on day one.
Ready for PROD gate
When it fires: After validation deployment is recorded, before production deployment is authorised.
Who signs: QA Approver.
What must be true:
- All documents due by the PROD gate are Approved.
- Any remaining conditional documents have applicability decisions.
- The QA Approver signing the gate is a different person from the Release Manager who recorded the VAL deployment.
Typical documents due at this gate:
- Qualification/validation/test summary reports
- Environment release notices
- Product release notes
- User manual
- Administrator guide
What blocks the gate:
- Any PROD-gate document not approved
- Same person attempting both VAL deployment and PROD gate approval
The release status progression
The gates are part of a nine-stage lifecycle.
- Planning — checklist and assignments reviewed; documents cannot yet be submitted.
- In Progress — Release Manager starts the release; authors can submit.
- Ready for DEV — DEV gate check passes; Release Manager signs.
- DEV Deployed — Release Manager records the manual DEV deployment reference and evidence.
- Ready for VAL — VAL gate check passes; QA Approver signs (must differ from DEV recorder).
- VAL Deployed — Release Manager records the manual VAL deployment reference and evidence.
- Ready for PROD — PROD gate check passes; QA Approver signs (must differ from VAL recorder).
- PROD Deployed — Release Manager records the manual PROD deployment reference and evidence.
- Released — QA Approver signs final production verification and release authorisation (must differ from PROD recorder).
Notice three things:
- Deployments are recorded manually. The platform does not perform deployments. It records the reference and evidence for each one.
- Gate approvals are always signed by a QA Approver, never the same person who recorded the deployment.
- Every transition is audit-trailed.
Why the gates matter
Three reasons.
1. They prevent uncontrolled promotion
Without gates, a release tends to drift forward. Development finishes; someone says "we're basically ready for validation"; validation begins before documentation is signed. By the time the audit happens, the timeline shows validation work preceded the documentation that was supposed to authorise it.
Gates prevent this. The transition is blocked until conditions are met.
2. They create an audit-defensible record
When an auditor asks "what evidence exists that the SDS was approved before validation began?", the answer is: the SDS approval timestamp, the VAL gate signature timestamp, and the ordering between them. All in the audit trail. All append-only.
3. They separate concerns
The person who deploys is not the person who approves the deployment. The person who writes a document is not the person who reviews it. The person who reviews is not the person who approves it.
This is not bureaucracy. It is the basic structure that makes quality records credible.
What happens when a release fails a gate
Three possible outcomes.
- The release stays where it is. Nothing advances. The document gate check refuses the promotion. The Release Manager or QA Approver can see exactly which items are outstanding.
- The release returns to documentation work. A release in a promotion stage can be returned to In Progress with a reason. The reason is audit-trailed. This happens when the gate check reveals that more work is needed than expected — a missing document, an unsigned decision, a rejected submission.
- The release is cancelled. If the release will not proceed, it can be cancelled. Cancellation is also audit-trailed.
Notice what is not an option: unblocking the release without meeting the conditions. There is no override. The gate is the gate.
The bottom line
A stage gate is not a milestone. It is a verified condition that blocks or permits a transition.
The three-gate model — DEV, VAL, PROD — works because it maps to how regulated organisations already think about risk: development risk, validation risk, and production risk. Each gate is a checkpoint on that risk ladder.
If your release process has milestones but not gates, the model above is what changes.