A chess-variant article is trustworthy only if another reader can reconstruct the same game from the documentation. That requires more than a name and a paragraph of rules: legal state, objectives, version, implementation and data representation all have to agree.
The Ruleset Profile below is a reproducible template for players, editors, developers and researchers.
Ruleset Profile
Identity and Provenance
Record:
- stable internal ID;
- canonical name for the chosen source;
- aliases;
- variant family/category;
- ruleset, mode, format or historical-relative classification;
- inventor, earliest source or community attribution;
- evidence level;
- rules authority;
- implementation/platform profile;
- effective or verification date.
Do not use an alias as the only identity field.
Board and Setup
Record geometry, dimensions, coordinates, wrapping or multiple-board behavior. Then specify the full starting state:
- fixed or random;
- exact initial position or generation algorithm;
- seed/position number convention;
- mirrored/asymmetric setup;
- pockets/reserves;
- castling identities or other start-dependent rights.
Piece Definitions
For every piece type, store movement and capture separately where needed, plus:
- ownership;
- royal status;
- promotion source/target;
- identity after promotion or capture;
- any hurdle, zone or direction restrictions.
A display glyph or name is not a movement specification.
Move Legality
Document every rule that can change legal move generation:
- compulsory captures or moves;
- drops;
- king/check semantics;
- king adjacency;
- castling;
- en passant;
- promotion;
- special regions;
- explosion/rebirth/transfer;
- hidden-information legality feedback.
Turn and Player Structure
For multiplayer or coupled-board games, record:
- players;
- side/player to move;
- turn order;
- team mapping;
- communication;
- simultaneous actions if any;
- coupled-board transfer events.
Objectives and Results
List all win/loss/draw conditions and their precedence. Include stalemate, repetition, move-count rules, point scoring or elimination when relevant.
Information and Randomness
Store authoritative full state separately from each player's visible state in hidden-information games. Record visibility algorithms, umpire signals and private/public data.
For randomness, distinguish pre-game from in-game randomization and preserve a seed or generated start when reproducibility matters.
Clock and Mode
Record special timing rules when they affect play: coupled clocks, sitting/stalling, correspondence time, conditional moves or mode-specific adjudication.
Notation and Data Envelope
A variant-aware record should normally identify:
ruleset_id;ruleset_version;implementation_id;implementation_version;source_verified_at;- complete typed
state; move_history;- original
raw_source.
The state schema is variant-specific. A Crazyhouse position needs pockets and promoted identity. Three-Check needs check counters. Multiplayer needs turn and team state. Hidden-information play needs private views. A normal FEN cannot express all of those.
Preserve Raw Data Before Normalizing
Always keep the original PGN/FEN/export/API payload where possible. Normalization can silently discard:
- pocket syntax;
- promotion markers;
- variant tags;
- custom piece identifiers;
- visibility state;
- team mapping;
- scores;
- proprietary but semantically necessary fields.
A beautiful normalized record that cannot reconstruct legal moves is data loss.
Round-Trip Interoperability Test
For every supported ruleset/implementation pair:
- import a canonical test position;
- verify complete state;
- enumerate legal moves;
- make representative special moves;
- export;
- re-import;
- compare complete state again;
- compare legal moves and result status;
- compare engine interpretation when an engine is part of the workflow.
PASS means semantic identity, not text identity. Two encodings can differ as strings and represent the same state; two visually identical boards can represent different castling, pocket, check-count or hidden-information states.
Variant-Specific QA Cards
Chess960
Store exact start, rook identities for each castling side, rights, FEN dialect, PGN variant metadata and engine Chess960 mode. Test:
- both pieces move;
- transposition castling;
- king-only castling;
- rook-only castling;
- blocked paths;
- attacked king path;
- a piece already on its final castling square.
Crazyhouse
Store board, pockets, promoted-piece identity and ordinary rights. Test ordinary drops, pawn restrictions, drop blocks, checking drops and the capture of a promoted piece.
Bughouse
A global state requires both boards, both clocks, pockets, team map and transfer-event order. Two unrelated FEN strings are not enough.
Three-Check / King of the Hill
Three-Check requires check counters in addition to the board. King of the Hill requires exact winning center squares and ordinary legality of the king move.
Antichess Family
Record mandatory capture, king status, check, castling, en passant, stalemate result, lose-all condition and promotion choices. Never assume another site's Antichess label matches your profile.
Atomic
Record explosion center/radius, collateral immunity, king blast legality, king adjacency, traditional mate behavior and version. Legal move generation depends on those details.
Horde / Racing Kings
Store exact start and side-specific objectives. For Racing Kings, also preserve check prohibition and the implementation's first-mover compensation/result rule.
Hidden Information
Preserve an authoritative full state and separate per-player view states. A screenshot is not a canonical state representation.
Multiplayer
Store ownership, turn order, team map, communication, scores, eliminated/frozen pieces and clock semantics.
Historical and Regional Games
For a historical reconstruction, separate:
- directly attested rules;
- scholarly inference;
- disputed rules;
- chosen playable convention;
- rationale and version.
For living regional chess-family games, use local terminology and current rules authorities where possible. FIDE chess comparisons are optional explanatory aids, not normative definitions.
Correspondence and Blindfold Are Mode Cards
A correspondence card should store the underlying ruleset, governing authority, time system, conditional-move support, external-analysis policy, tablebase/adjudication rules and event date.
A blindfold card should distinguish absence of a visual board from genuine hidden information. The full objective position remains available in cognitive blindfold chess even if it is held mentally rather than shown.
Engine Match Record
When an engine is used, record:
- engine and version/commit;
- selected variant/config;
- protocol options;
- NNUE/network where relevant;
- rules source;
- known deviations;
- test positions or perft/reference checks.
Stockfish's UCI_Chess960 switch and Fairy-Stockfish's broader variant configuration are not interchangeable concepts: one enables Chess960 castling/encoding behavior, while the other can select entirely different rulesets.
How to Document a “Solved” Claim
Before writing that a variant is solved, define:
- exact ruleset/version;
- start position;
- weak versus strong solution;
- proven outcome;
- proof/computation method;
- provenance;
- date.
“Solved” without those fields is not a reproducible mathematical statement.
Publication Checklist
Before publishing or localizing a variant guide, verify:
- [ ] ruleset separated from mode/format/time control;
- [ ] canonical ID and aliases recorded;
- [ ] rule authority and verification date present;
- [ ] board/setup exact;
- [ ] king/check and capture rules exact;
- [ ] objective/stalemate/draw precedence exact;
- [ ] promotion/castling/en-passant exact where relevant;
- [ ] pocket/drop/promotion identity exact;
- [ ] information/player/team state represented;
- [ ] implementation differences explicit;
- [ ] raw source retained;
- [ ] semantic round trip tested;
- [ ] correct engine/config selected;
- [ ] historical provenance expressed at the right confidence level;
- [ ] strategy derived from the documented rules rather than a variant name.
A variant record is complete when rules, state, implementation and interpretation all point to the same game.
Classify Implementation Differences by Severity
When two implementations disagree, classify the difference before deciding whether they share one profile:
- presentation-only — colors, names, icons;
- notation-only — different encoding of the same state;
- strategic — same legal game but timing/scoring environment changes decisions;
- legal-move changing — different move sets;
- result changing — same position can terminate differently;
- data-incompatible — one format cannot represent the other's full state.
Legal-move and result-changing differences normally deserve explicit subprofiles.
Preserve a Small Canonical Test Corpus
For each ruleset, keep a curated set of positions that exercise:
- ordinary play;
- every special move;
- terminal conditions;
- ambiguous edge cases;
- import/export round trips;
- engine configuration.
A Ruleset Profile without test positions is documentation; a profile plus reproducible tests becomes an interoperability contract.