Rules and Audit

Core competition logic

• All public events belong to the IJCCRL Arena Series.
• Each event must clearly identify track, time control, stage and publication status.
• Only closed and publication-valid material should move to Downloads, Archive and Winners.
• Event naming should follow one public grammar across Classical, Blitz and Bullet.
• For Original UCI events, tournament-side UCI configuration is part of the rules framework rather than an informal GUI preference.

Legality and termination

• Threefold repetition: enabled.
• 50-move rule: enabled.
• Insufficient material: enabled.
• Illegal move / protocol failure: treated as a loss for the offending engine and preserved in the audit evidence when applicable.

Clock and engine control

• Time control depends on the event family: Classical, Blitz or Bullet.
• Clock mode: passthrough where applicable.
• Bestmove timeout: event-profile dependent and must be high enough not to conflict with the declared base time.
• No-bestmove policy: loss (forfeit).
• Stop grace: event-profile dependent and declared in backend configuration.
• Original UCI tournaments use an explicit backend UCI authority so engines are not left to accidental GUI carry-over, legacy defaults or strength-limited session remnants.

Tablebases and technical aids

• Syzygy: enabled where configured, with probe limit and depth set by the tournament profile.
• TB Turbo: may be enabled when the event profile explicitly uses it.
• 50-move rule with tablebases: enforced.

Why one-game Armageddon is rejected

• A human-style one-game Armageddon normally assigns draw odds to Black and uses an asymmetric time/colour decision.
• That model is not compatible with IJCCRL’s engine-audit doctrine because it breaks colour symmetry and opening-pair symmetry.
• IJCCRL adopts the decisive intent of Armageddon but implements it through mirrored two-game units.
• The public term for this procedure is therefore Mirrored Armageddon Ladder.

Decision rule

• If a tiebreak unit ends 2.0–0.0 or 1.5–0.5, the higher-scoring engine wins the match.
• If a tiebreak unit ends 1.0–1.0, the unit is recorded as audit-valid but not decisive.
• The tournament then advances to the next ladder step.
• Each unit must be archived with its own PGN/results/scheduler evidence before the next unit starts.

Publication and audit payload

• Each tiebreak step must be published as a separate audit unit when it affects knockout qualification.
• The required evidence set is games.pgn, results.json and scheduler_state.json.
• The scheduler must show the unit closed with no pending game.
• The result table must show one White and one Black game per engine for the unit.
• If a unit is tied, the public result is audit-valid but not decisive.
• Only the first decisive mirrored pair produces the finalist or match winner.

Derived Stockfish Track

• This branch contains Stockfish-derived engines and related derivative events.
• Knockout phases and finals may use fixed mirrored opening duels.
• Where the event profile states it, pair ratio = 0 and the same opening must be played once with each colour before advancing to the next opening line.
• Audit must verify colour balance and mirrored-opening integrity under the event format actually used.
• If a knockout tie remains unresolved after the first tiebreak pair, the Mirrored Armageddon Ladder may be used when the event notice adopts this ruleset.

Original UCI Track

• This branch contains original/upstream UCI engines rather than IJCCRL derivative tracks.
• League Stage and knockout phases must keep the public naming grammar of the IJCCRL Arena Series.
• Audit must verify completeness, pair integrity, legality and publication consistency under the exact competition format used.
• Stockfish may appear here as an original/upstream engine within the Original UCI Track when appropriate.
• UCI settings are not treated as a universal one-size-fits-all block. A safe common base is combined with engine-specific profiles when the original author or official engine notes define tournament-relevant settings.
• The Original UCI Track adopts the Mirrored Armageddon Ladder as its default knockout escalation procedure when a scheduled knockout block and its first mirrored tiebreak pair both fail to decide the match.

Why this rule exists

• Original engines do not expose identical UCI semantics.
• Some engines can be unintentionally weakened by retained GUI state, family-incompatible defaults, strength-limit options, own-book remnants or analysis-oriented settings.
• For that reason, IJCCRL declares tournament-side UCI settings as part of the rules framework for the Original UCI Track.
• The goal is not cosmetic uniformity but comparability at intended strength.

Common safe base

• Where supported, the backend may normalise a shared tournament base such as Threads, Hash, MultiPV=1, Ponder=false, OwnBook=false, UCI_Chess960=false, move-overhead protection and the declared Syzygy profile.
• This common base is intended to remove accidental weakness or hidden GUI carry-over without overriding the identity of the engine.

Engine-specific profiles

• When original engine authors document tournament-relevant UCI settings, IJCCRL follows those recommendations instead of forcing a Stockfish-style universal block.
• This may include engine-specific treatment of Skill, strength-limiting flags, contempt logic, evaluation mode, MCTS/normal mode, table memory or move-overhead parameters.
• Author-guided profiles are used only to reach the engine’s intended competitive behaviour, not to impose stylistic distortions.

Example of author-guided policy

• When official notes exist, they are preferred evidence for tournament-side configuration.
• For example, Dragon/Komodo documentation explicitly distinguishes between normal engine-vs-engine use and other modes, and also documents tournament-relevant parameters such as threads, hash, contempt handling, white-contempt behaviour, evaluation mode and move-overhead logic.
• IJCCRL therefore treats such settings as rules-level technical parity controls, not as ad-hoc user tweaks.

Openings policy

• When openings are book-driven, the event should identify the book source and PLY limit.
• Openings should be used consistently with the event format and public description.
• For mirrored finals and similar duels, the audit must confirm that opening sequence integrity was preserved.
• If an external opening source is declared for the event, engine-internal book features should not override the published opening contract.

Resource profile

• Threads, hash and pacing values may vary by tournament profile and hardware class.
• For the Original UCI Track, the resource profile also includes the declared backend UCI authority where that authority affects competitive strength or comparability.
• Public publication should remain reproducible enough that the competition profile is readable from the event documentation.
• Where relevant, the event may disclose values such as threads, hash, info_throttle, pv_tokens, ws_ping and selected UCI tournament defaults.

Audit checklist

• Completeness: all scheduled games present.
• Pair integrity: colour and pairing logic valid under the actual format used.
• Openings integrity: book order / mirrored logic / PLY limit respected when applicable.
• Rules integrity: terminations correctly encoded and explainable.
• UCI integrity: declared tournament-side UCI policy matches the effective event profile.
• Tiebreak integrity: if the Mirrored Armageddon Ladder is invoked, each step must preserve a two-game mirrored unit and pair ratio 0.
• Publication integrity: the public naming and event identity match the actual tournament.

Publication artifacts

• Public packs should include the relevant audited artifacts when applicable, such as games.pgn, results.json, scheduler_state.json, manifest.json, audit output and checksums.
• Where the event profile relies on explicit backend UCI normalisation, the publication layer should make that fact readable from the event documentation.
• When a tiebreak ladder is invoked, each non-decisive and decisive unit should be preserved as a separate audit block.
• Final publication packs belong in Downloads.
• Closed historical entries belong in Archive.
• Champion identity belongs in Winners.

Operational surfaces

Publication surfaces