What belongs in a go/no-go packet besides the test summary

A test summary is necessary and almost never sufficient. It tells the room that someone executed a list. It does not tell the room who can halt a 10% store rollout at 11 p.m., or whether Bahasa Malaysia strings were frozen with the rest of the build.

In the packets we read in Kuala Lumpur, the missing pages are usually mundane. A named person for the halt. A sentence on what happens if crash-free hours drop after the first percentage step. A copy of the store questionnaire that matches the version, not last quarter’s version. A support rota that includes the public holiday sitting in the middle of launch week.

Put the test summary first if you like. After it, add four artefacts: the staged rollout steps with halt authority, the known-limitation list in the language users will read, the support coverage for the first 72 hours, and the rollback that has either been rehearsed or marked untested. If any of those four is a verbal understanding, write it down before the meeting.

Teams sometimes add crash dashboards to compensate for a thin packet. A chart without a halt owner is decoration. The go/no-go room is deciding whether people are prepared to live with the remaining risk, not whether a graph is green.

If you are two days from freeze and the packet is still a test summary plus a chat thread, stop adding checks. Spend the time naming owners and writing the limitation note. That work is less comforting than another test pass and more useful to the people who will take the first tickets.