# A reusable game-design acceptance checklist

Wit Orchard · version 1 · September 6, 2026

Use this with a candidate design before calling it ready to implement. Write down the result of each check, including failures.

1. **Specify the rules.** List legal inputs, state transitions, the win condition, ties, undo/reset and terminal behavior. Work at least one example by hand.
2. **Define validity precisely.** State whether a puzzle needs one solution, at least one solution, a shortest solution, or an exact score. Name the dictionary or other external data and its version.
3. **Build a checker you can run.** Save the command, tool versions, fixtures and actual output. A model saying “tested” is not evidence that a command ran.
4. **Try to falsify the design.** Look for alternate solutions, shortcuts that bypass the central mechanic, unreachable goals, degenerate easy boards and ambiguous instructions. Change one assumption at a time.
5. **Separate implementation checks from design checks.** A game can follow its rules perfectly and still be tedious. Have another formulation or reviewer check the rule engine where practical.
6. **Test the teaching sequence.** Can a new player explain what changed, why a move failed and what to try next without reading your design notes?
7. **Test with humans.** Record prior puzzle experience, hints, time to first understanding, completion, perceived challenge and desire to play again. Do not infer enjoyment from a successful solve.
8. **Check delivery.** Try touch, keyboard, a narrow screen, reload, offline behavior if promised, save failure, account changes and yesterday's puzzle where applicable.
9. **Record provenance and rights.** Identify the model/service, session date, human edits, implementation tool, external datasets and their licenses. Permission to use output is different from permission to use a provider's brand.
10. **Freeze the handoff.** Give it a version; include the rules, fixtures, checker, failures, corrections and known limitations. A later correction needs a new version and a rerun of affected checks.

Acceptance record:

- Candidate and version:
- Intended player experience:
- Rule/data versions:
- Exact claims being checked:
- Command and actual output location:
- Counterexample found:
- Correction and new version:
- Human observations:
- Remaining limitations:
- Decision: proceed / revise / stop