Quality begins with the learning objective
Checks are not generic “data hygiene.” They are derived from the task: which signals must join on tick, which contracts must pass, which assets must load in the named runtime. A program without an objective cannot have a meaningful accept gate.
Automated validation
File integrity, schema conformance, temporal alignment, and manifest completeness run first. Failures return for correction. We do not report 100% pass rates as a brand claim; mixed statuses are expected while a pack is in review.
Runtime and behavioral verification
Executable worlds are launched, state is read, contracts are evaluated, and reset is attempted when the runtime supports it. Automation finds schema drift and broken chains. It does not certify that a human would enjoy the controls.
Human review
Playability, specification honesty, and stuck-state checks remain human. Review notes attach to the QA report for the version under acceptance.
Asset QA
Geometry, scale, materials, and engine load are checked for the tier in scope. Missing colliders on an Object-tier prop are not treated as a Simulation-Ready failure.
License and provenance checks
Release is blocked when the license manifest is incomplete or a third-party item has no recorded authorization. See Licensing & Provenance.
Versioning and acceptance
Accepted deliveries are versioned. Corrections ship as a new version with a changelog. Silent overwrite of a customer-accepted snapshot is not the process.
Example QA summary
Illustrative QA summary for a sample evaluation world. Not a customer report.
- Build
- PASS
- Asset loading
- PASS
- State schema
- PASS
- Temporal alignment
- PASS
- Reset determinism
- PASS
- Action replay
- PASS
- Behavioral contracts
- 18 / 18
- License manifest
- COMPLETE
- Human playability review
- PASS