设想 Build A 通过了 Studio 的检查点测试，随后修改路线并生成 Build B。A 的测试结果不会自动成为 B 的测试结果，即使文件名很像。不可变的 Build ID 和 SHA-256 哈希可以区分两个产物。这里说明的是验证方法，不是宣称某个公开游戏已通过 Studio 测试。
哈希能证明什么、不能证明什么
下载 Build 时，可以用记录的哈希检查文件是否与存储的产物一致。测试报告应写明测试的是哪个 Build；恢复操作应选择明确的历史快照，而非可变文件名。文件改变，哈希也改变，旧运行证据只能保留为历史。哈希不能证明游戏好玩、安全、素材有授权、多人可用，或已获准在 Roblox 发布；这些需要独立验证。
实际核对顺序
保存 Build A 及其哈希；在 Studio 打开 A 并记录测试；编辑后下载 Build B，对比哈希；重新测试 B，把新报告关联到 B；保留 A 作为恢复点。
带走这一点
- 始终保留上一份可用 Build。
- 运行证据必须绑定当前 Build，不可沿用。
- 把未知状态写为未知，而不是把它涂成通过。