end000/Checkers-WSPForge-Russian-v2

Checkers WSPForge Russian v2

A sparse ReLU network for Russian draughts on an 8×8 board, with its architecture and numerical weights programmed directly. No gradient descent, backpropagation, optimizer, PPO, RL, pretrained game model, or automated parameter fitting was used.

What improved: in a frozen held-out comparison against py-draughts SimpleEngine D3, v2 scored 34.96% versus 25.39% for v1, a 9.57 percentage point gain. An architecture-matched route-readout ablation supports a contribution from the added neural component.

What did not: this is not a tournament-strength engine. It still loses most games to D3–D5. D4/D5 gains are not established after multiple-comparison adjustment. A smaller second D3 cohort had a positive difference but was not individually significant. Direct v2-versus-v1 games were approximately even. See the full tables and uncertainty below.

This is a custom NumPy/SciPy game policy, not a language model or a Transformers checkpoint. Inference uses fixed affine/ReLU layers. No GPU is required.

Download and play

Download this public repository with the Hugging Face CLI or its Files tab. For example:

python -m pip install huggingface_hub
hf download end000/Checkers-WSPForge-Russian-v2 --local-dir Checkers-WSPForge-Russian-v2
cd Checkers-WSPForge-Russian-v2
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
python agent.py --human white

Use --human black for the other side, --one-move for a single decision, or omit --human for a demonstration against random play. Tested on Linux with Python 3.14.4 and the pinned dependencies. No automatic remote-code loader or external inference API is used.

from draughts import RussianBoard
from agent import Agent

board = RussianBoard()
player = Agent(model_dir=".", seed=42)
move = player.choose(board)
board.push(move)

Original method and project attribution

Weight-Space Programming and the original Go experiment are credited to Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab, MIT CSAIL. WSPForge does not claim authorship of the original method or affiliation with its authors.

This is an independent WSPForge experiment: an LLM-assisted research agent designed circuits and generated their weights in Python, inspected games, and revised hypotheses. Development-game feedback influenced the programming process. No training does not mean no feedback or no model selection. No MIT Go weights or trained game-network weights were copied.

The game, architecture and opponents differ from the published Go experiment; their numerical results are not directly comparable.

Architecture and exact size

Property	Value
Architecture	128 → 384 → 6288 → 1527 → 114 → 4 → 1
Non-input neurons	8,318
Nonzero matrix weights	117,704
Nonzero biases	7,447
Total nonzero scalar parameters	125,151
Dense-equivalent slots including zeros	12,248,376
Sparse arrays including indices	1,008,200 bytes
NPZ file	1,015,770 bytes
Weight SHA-256	e996352b06d795395c227c08438c5ae831bdd0cc3cf7bb177ee8f613a53f5286

The sparse counts include the explicitly programmed nonzero matrix entries and biases. The dense-equivalent count includes all zero slots; this is not a learned 12-million-parameter dense model. Float32 weights, sparse indices and shapes are saved in weights.npz; model.json records the architecture and checksum.

Input: four binary planes of 32 dark squares — own men, own kings, opposing men, opposing kings. Squares are ordered b8,d8,f8,h8,...,a1,c1,e1,g1; for black the board is rotated 180 degrees. Output: one scalar score per legal afterstate. These scores are not calibrated win probabilities.

Legal moves are generated externally and each candidate move is applied once to form its afterstate. The network scores that batch; argmax chooses the move, with seeded uniform tie-breaking. The selector does not generate opponent responses, call a classical evaluator, run minimax/alpha-beta, or perform game rollouts.

How the weights were created

The released model combines:

1. An integer-scaled version of v1's material, position and immediate-capture-safety circuit.
2. A directly programmed static safe promotion-route circuit.

The route circuit encodes 1,254 fixed forward diagonal paths for 56 possible man/source combinations. For each source, it detects a path of empty cells to the promotion row. Safety gates test immediate capture exposure along that path, accounting for the source square becoming vacant. OR-like saturation prevents counting multiple routes for the same man repeatedly.

The added score is the difference between the sides' promotion potentials. A reachable future king receives the man-to-king value increment, discounted by 1/2 per quiet step. This discount is a fixed design assumption, not fitted from games.

Binary conjunctions use ReLU(sum(conditions) - number_of_conditions + 1). Saturation uses ReLU(z) - ReLU(z - 1). The two subnetworks are combined through positive/negative score channels, preserving signed values. At inference, the saved tensors execute only matrix operations and ReLU; the path compiler is not called.

Static route availability is a heuristic. Opposing pieces are held fixed for this feature. Future opponent moves, compulsory captures and multi-capture tactics can invalidate a corridor. It is not a proof that promotion will occur.

Why earlier threat recognition did not make the player much stronger

The first strengthening stage reduced unrecognized victims in old D3 trajectories from 124 to 6 out of 671, but did not establish a substantial playing-strength gain.

Decision-level analysis clarified the difference between recognizing a threat and changing an action. On 2,010 non-forced decisions, the two-jump feature changed the best-move set in only 63 cases. New information was often identical across alternatives, or too small to change their ranking. The old archive also contained 365 forced single-move decisions.

A separate temporal analysis found 93 materially unfavorable offer/capture/recapture sequences; 81 had only one legal capture at the later decision. Detecting danger at that later point does not create an escape.

Additional experiments corrected or explored:

• negative mandatory-exchange values that earlier ReLU/max pooling had clipped away;
• availability masking, so an absent capture is not a free zero-valued alternative;
• compulsory continuation and king landing choices;
• recapture guards for both men and kings;
• prospective quiet-bait and fork motifs;
• phase-dependent material interactions and king proximity;
• promotion routes, including empty-only, safety-gated and best-route readouts.

The released route component changed the best-move set in 520 of those 2,010 diagnostic decisions, including 428 strict preference reversals. That statistic measures decision relevance, not correctness. Fresh games below establish the outcome effect.

Across the two held-out D3 cohorts, observed promotions increased from 3.17 to 4.48 per 100 own moves, consistent with the intended mechanism. This behavioral association is not a separate proof of the entire causal pathway.

All explored constructions, including unsuccessful and larger candidates, are documented in the code, model catalogue and logs. Bigger models and combinations did not reliably add their benefits.

Frozen independent evaluation

Development used seed ranges beginning at 70000; validation used ranges beginning at 80000. The selected compact candidate r3-v1-safe, secondary candidate r0-complete-empty, and controls were checksum-frozen before the new comparisons. The local freeze record is in reports/ROUTE_CONFIRMATION_LOCK.json; this was not an external preregistration.

The main cohort used 128 seed/opening pairs, 256 games per model/opponent, seeds 90000–90127, both colors. A separately planned D3 repetition used 64 further pairs, seeds 100000–100063. Neither cohort was used to alter the weights.

Starts were sampled after 0, 8, 16, 24, 32, 40, 48 or 56 random legal half-moves. Terminal positions were rejected before model evaluation. Model and baseline received identical starting positions and corresponding seeds. Positions may be materially unbalanced; color pairing reduces side advantage. This is an artificial opening distribution, not an Elo estimate.

Main cohort

Score means (wins + 0.5 × draws) / games.

Opponent	Network	Wins	Draws	Losses	Score
SimpleEngine D3	v1	41	48	167	25.39%
SimpleEngine D3	v2	66	47	143	34.96%
SimpleEngine D4	v1	42	40	174	24.22%
SimpleEngine D4	v2	49	38	169	26.56%
SimpleEngine D5	v1	40	31	185	21.68%
SimpleEngine D5	v2	51	29	176	25.59%

Paired seed/opening uncertainty for v2 minus v1, in percentage points:

Opponent	Gain pp	Paired 95% interval pp	Six-comparison interval pp
D3	+9.57	+5.86 to +13.28	+4.69 to +14.65
D4	+2.34	-1.56 to +6.25	-2.73 to +7.62
D5	+3.91	+0.59 to +7.42	-0.78 to +8.79

The adjusted intervals use percentile bootstrap endpoints for the six comparisons of two candidates across D3/D4/D5. They are empirical uncertainty estimates conditional on this opening generator, not universal strength bounds.

SimpleEngine's nominal depth includes its native capture-quiescence extension. D3 is not strictly a three-half-move total horizon, and increased nominal depth does not guarantee monotonically better results on every sample.

Separately planned D3 repetition

Network	Wins	Draws	Losses	Score
v1	27	23	78	30.08%
v2	34	20	74	34.38%

The repetition's difference is +4.30 pp, with a 95% paired interval of −0.78 to +9.77 pp. Its positive direction alone is not statistically conclusive. Pooling the two preplanned D3 cohorts gives +7.81 pp, 95% interval +4.82 to +10.94 pp. The main cohort already has a positive multiplicity-adjusted interval.

The starting-board subgroup of the main D3 cohort contained 32 games per model: v1 had 0 wins, 1 draw, 31 losses; v2 had 7 wins, 1 draw, 24 losses. This is a post-hoc descriptive subgroup, not a separate selection criterion or rating claim.

Causal control and regressions

The architecture-matched control keeps the entire network and route computation but zeros only the two final readout links from the route branch. This disables the branch; it does not mean the useful program resides in two parameters.

Configuration	Wins	Draws	Losses	Score
Full v2	66	47	143	34.96%
Same architecture, route readout disabled	42	44	170	25.00%
Original v1	41	48	167	25.39%

The paired D3 difference between full v2 and that control is +9.96 pp, 95% interval +6.25 to +13.67 pp. The integer-scaled control differs slightly from floating-point v1 because near-tie rounding can change trajectories. This is why both comparisons are reported.

The larger secondary composite improved relative to v1, but its route-readout ablation did not isolate a clear additional route benefit. The preselected compact model was retained.

Compact regression checks, 64 games per row on paired starts:

Opponent	Network	Wins	Draws	Losses	Score
random	v1	56	1	7	88.28%
random	v2	56	1	7	88.28%
greedy	v1	54	0	10	84.38%
greedy	v2	53	0	11	82.81%

Direct v2-versus-v1 play was 25 wins, 15 draws, 24 losses: 50.78% score, not an established head-to-head advantage. The observed one-game decline against greedy play is retained in the report. No guarantee is made that every opponent or position benefits.

Speed and memory

Single-thread CPU measurements on the local Ryzen 9 5950X machine used a separate fixed corpus of 512 positions. No GPU, paid cloud compute or large local LLM inference was used for game evaluation.

Procedure	Median decision time	P95
v1	0.125 ms	0.160 ms
v2	0.468 ms	0.554 ms
Larger secondary candidate	1.638 ms	2.157 ms
SimpleEngine D3	3.013 ms	7.535 ms
SimpleEngine D5	18.377 ms	50.005 ms
Greedy	0.058 ms	0.098 ms

Times include applying candidate moves, encoding, evaluation and tie selection; model loading is excluded. Common legal generation is measured separately. Persistent engine objects can reuse their native tables. This is a reproducible microbenchmark, not proof of better play at exactly equal compute.

The model uses approximately 0.96 MiB of sparse arrays and a 1.02 MB decimal NPZ file. Whole-process benchmark RSS also includes Python, libraries, the board corpus and engine tables; see reports/route_benchmark.json. v2 costs more than v1. No speed advantage over an optimized classical implementation of the same route strategy is claimed.

Verification and known limitations

• New circuit tests compare programmed formulas, compulsory capture behavior, legal continuation masks, exact branch composition and static reachability.
• Dense ReLU(XW+b) and sparse execution agree for the selected network.
• During a selector test, opponent move generation and conventional engines are patched to raise; the neural selector still works.
• Full selected weights can be regenerated byte-identically from geometry and formulas, without downloading weight files or reading game outcomes.
• Held-out paths were replayed strictly; published verification tools also recompute winners, draw reasons and scores from the moves.
• Earlier rule tests compared 3,000 positions, including synthetic sparse positions, and 15,247 successor/push-pop checks against an independent pydraughts environment.

An early v1 evaluation accidentally included terminal starts. It was invalidated and rerun. The invalidated records remain clearly separated under evidence/invalidated/ and do not contribute to the main tables.

The referee implements capture/promotion rules, repetition and draw counters, including regulated endings, with a separately recorded 300-half-move emergency cutoff. It does not prove all theoretically drawn positions. Tactical motifs and static routes do not replace long-term adversarial planning; sacrifices, king endings and changing opponent geometry remain weaknesses.

This experiment supports a specific benchmark improvement from directly programmed weights. It does not establish universal superiority of WSP, a general procedure for writing strong weights, or parity with strong commercial/search engines.

Reproduce at home

The repository includes selected and v1 weights, all research source, protocols, checksums, full per-game traces, failed hypotheses and the original freeze records. No training set or pretrained checkpoint is needed.

Rebuild the selected model and secondary/control models directly from formulas:

python rebuild_selected.py --output .work/rebuilt --include-secondary

This refuses to overwrite an existing output directory. It verifies that regenerated selected and baseline NPZ files match the published hashes. It reads the published checksum for validation, not published weights for construction.

A short local comparison:

cd .work/rebuilt
OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 MKL_NUM_THREADS=1 \
python ../../reproduce/tournament.py \
  --models v2-safety100 r3-v1-safe --opponents engine-d3 \
  --pairs 8 --start-seed 90000 \
  --opening-plies 0 8 16 24 32 40 48 56 \
  --output results/quick-comparison

v2-safety100 is the historical experimental name of baseline v1, not the released v2. r3-v1-safe is the released model's experimental name.

Replace the short-run options with --pairs 128 --opponents engine-d3 engine-d4 engine-d5 to repeat the main model/baseline comparison. The full recorded cohort also includes r0-complete-empty; its builder is included through --include-secondary. Refer to saved config.json files for every original command configuration.

Recompute reported effects from the published logs, optionally replaying rules and final outcomes:

cd ../..
python analyze_evidence.py --replay

The selected-network tests can be run from the rebuild directory:

cd .work/rebuilt
OPENBLAS_NUM_THREADS=1 python ../../reproduce/route_tests.py

Optional independent rule-library checks require the separate .oracle-venv described in reproduce/setup.sh; pydraughts and py-draughts use the same import name and should not be installed into one environment. The conventional compiled safety control requires a C++ compiler; neural inference and the main D3–D5 comparison do not.

example_game.json and example_game.pdn are the first fixed-seed selected-model D3 game in the held-out cohort, included irrespective of result. They are illustrative, not separate evidence.

Files, license and feedback

• weights.npz, model.json, network.py: standalone fixed network.
• agent.py, rules.py: minimal playable agent and tournament-compatible referee.
• baselines/v1/: preserved v1 weights.
• reproduce/: architecture/weight builders, tests, engines and tournament code.
• evidence/: full game logs, configurations, timing data and explicitly invalidated archives.
• reports/: research reports, catalogue, protocols, diagnoses and checksum locks.
• MANIFEST.json: SHA-256 integrity manifest.

Released under GPL-3.0; see LICENSE and THIRD_PARTY.txt. py-draughts is a separately installed GPL-3.0 dependency; pydraughts is an optional MIT-licensed test dependency. No third-party pretrained weights are included.

Independent replications, different opponents, difficult positions, rule corrections and failure reports are welcome. Please include starting positions, seeds, software versions, opponent settings and full move traces. Evaluation resources are limited, and we cannot guarantee competence or preservation outside the measured settings.