Imagine Build A passes a Studio checkpoint test. A creator then changes the route and produces Build B. The test result for A does not become a test result for B, even if the filenames look alike. An immutable Build ID and SHA-256 hash make the two artifacts distinguishable. This example describes the verification method, not a claim that a particular public game passed Studio testing.
What the hash proves—and what it does not
When you download a Build, the recorded hash lets you check that the file matches the stored artifact. A report should name the Build it tested; a restore should select a known snapshot, not a mutable filename. If the file changes, its hash changes and earlier runtime evidence stays historical. The hash cannot prove the game is fun, secure, licensed, multiplayer-ready, or approved for Roblox publication. Those need their own checks and rights review.
A practical verification sequence
Save Build A and its hash. Open A in Studio and record the test against A. After editing, download Build B and compare hashes. Retest B, attach the new report to B, and retain A as the recovery point.
Take this with you
- Always retain the previous usable Build.
- Runtime evidence belongs to its current Build and cannot be carried forward.
- Write unknown as unknown—never paint it passed.