A dramatic go/no-go usually means the real decisions happened too late.
If the final meeting is the first time the team asks whether audience counts reconcile, whether consent was tested, whether rollback exists or who is monitoring production, the problem is not the meeting. The control system failed earlier.
I want readiness to be observable.
“QA is good” is not enough. I want to know which scenarios passed, which risks were accepted, which version was tested and whether the production candidate is the same thing stakeholders approved.
The meeting should answer one question.
Given the evidence in front of us, are we comfortable putting this into production? If the answer depends on discovering new facts in the meeting, the launch is not ready for a decision.
This also changes escalation. A stakeholder can accept a known risk. They cannot meaningfully accept an unknown state.
The practical rule.
Define the proof before the build is finished. Then use go/no-go to review that proof, not invent it. The closer a team gets to launch, the fewer surprises the process should create.