A green build has a time boundary
A release may wait while another deployment, an approval decision or an environment dependency is resolved. During that wait, a newer candidate can be approved or the target state can change. Treat earlier build evidence as evidence about that candidate at that point in the workflow; do not silently interpret it as current permission to deploy.
Give the candidate a stable identity
Record the artifact identifier, source revision and relevant configuration references without logging secrets. Separate the identity of a build from the identity of a deployment attempt. If approval referred to one artifact, rebuilding a different artifact later requires an explicit policy rather than an assumption that the branch name makes them equivalent.
Define what makes a release obsolete
A newer candidate does not automatically invalidate every older one. A migration, dependency change or staged rollout may require a particular sequence. Document the conditions for supersession: which candidate is approved, whether skipped changes are required and whether the replacement remains compatible with the current target. Use a named owner for exceptions.
Check again at admission
Before a waiting run acquires permission to change the target, confirm its identity, approval and applicable prerequisites. Check the current deployment state where the workflow requires it. If the assumptions no longer hold, pause or retire the candidate through the agreed mechanism instead of letting it proceed because it reached the front of a queue.
Distinguish retirement from interruption
Retiring a waiting candidate should leave an understandable record of why it will not deploy. Interrupting an active deployment can require assessment of partial changes and recovery. Keep these paths distinct in operating instructions. Never imply that marking a job cancelled reverses a completed database or infrastructure operation.