mcts-cpu-validate docs¶
mcts-cpu-validate is a 15x15 self-play and MCTS experiment project built around a simplified Go-like ruleset. It does not try to be a full Go referee. The project is designed around a training loop that can run for a long time, save enough data to inspect later, recover after interruption, and replay saved games.
If you want the shortest plain-English version, it is this:
the program plays many games against itself, records what happened, and uses those records to train the model again. If training stops in the middle, it should be able to continue from a saved state.
If you are new to the repository, start with three facts:
- This is not a standard Go engine.
- Rust and Python have different responsibilities and should not duplicate rules logic.
- Run outputs must live under
data/runs/<run_id>/so training, recovery, and analysis all point to the same source data.
What this docs site is for¶
This docs site explains the project. It does not replace specs/.
- If you want to understand why the repository is split the way it is, how a run directory works, or how self-play feeds training, start here.
- If you need implementation constraints, read
specs/.
Suggested reading order¶
- Read “Project overview” for the project boundary.
- Read “Training loop” for the Rust/Python/data flow.
- Read “Running and configuration” when you are preparing to use the project.
If the terminology is new to you, keep these short definitions in mind:
self-play: the program plays against itself to generate training dataMCTS: a search method that looks ahead before choosing a movecheckpoint: a saved training state used for recoveryrun_id: the identifier that groups one run's output files togetherbitboard: a compact way to store board state efficiently
Relationship to the root documents¶
The root documents stay authoritative. The docs site reuses them with symlinks where possible instead of copying them. That keeps configuration notes, operating steps, and the main README from splitting into multiple versions.