Sashité for Developers
  1. Sashité for Developers
  2. Specifications
  3. CGSN
  4. 1.0.0

Chess Game Status Notation (CGSN) Specification

Overview

Chess Game Status Notation (CGSN) provides a rule-agnostic taxonomy of observable game status values for abstract strategy board games. CGSN defines standardized identifiers for terminal states, player actions, and game progression states that can be recorded independently of competitive interpretation.

Note on Terminology

While “chess” appears in the specification name for consistency with PCN (Portable Chess Notation), CGSN is rule-agnostic within its domain. It applies to Western chess, Japanese shōgi, Chinese xiangqi, Thai makruk, and other two-player abstract strategy games in the chaturanga family that share similar concepts (terminal pieces, turn-based play, piece movement).

The term “chess” reflects historical naming conventions in the Sashité ecosystem, not cultural primacy or hierarchical relationship between game traditions. CGSN is designed for games with compatible mechanics; it may not be suitable for all abstract strategy games (e.g., games without terminal pieces, simultaneous-turn games, or games with fundamentally different state concepts).

Terminology

All terms used in this specification are precisely defined in the Glossary and Protocol. Bold terms reference these formal definitions.

Key Concepts

Terminal Piece: A piece identifiable as essential to a player’s continued participation in the match. A player may control zero, one, or multiple terminal pieces depending on the rule system.

Terminal State: An observable condition indicating that the match has reached its conclusion.

Check State: An observable condition where a terminal piece can be captured by at least one move by the opponent, evaluated based on piece movement capabilities.

Move Hierarchy: The specification distinguishes three levels of moves:

Side vs. Control: The Side attribute indicates a piece’s camp affiliation (first or second player), distinct from operational control. CGSN evaluates status relative to pieces matching the Active Player’s side.

Active Player: The player whose turn it currently is.

Pass Move: A move concluding the turn without displacement or mutation.

Dependencies

None. CGSN is a foundational taxonomy with no dependencies on other specifications.

Core Principles

Rule-Agnostic Foundation

CGSN records observable facts about game state without interpreting their competitive significance. The same status value may have different outcomes under different rule systems:

This separation ensures universal applicability across different game systems while preserving implementation flexibility.

Observable vs. Competitive

CGSN maintains strict separation between:

Observable status: Factual game state that can be verified

Competitive interpretation: Outcome determination based on rules

CGSN addresses only observable status. Competitive outcomes are determined by the specific rule system being applied.

Status Independence

Status values are independent of:

A CGSN status simply records what is observed, not why or with what consequence.

Status Categories

CGSN organizes status values into two fundamental categories based on their derivability from game position.

Inferable Statuses

Statuses that can be determined through position analysis when game rules are known:

These statuses may be omitted in notation formats, allowing implementations to infer them from position when needed.

Explicit-Only Statuses

Statuses that require information external to position:

These statuses must be explicitly recorded as they cannot be reliably determined from position analysis alone.

Status Values

CGSN defines the following standardized status identifiers:

Complete Status Taxonomy

Status Category Game Over Involved Player
in_progress Inferable No Both players
checkmate Inferable Yes One player
stalemate Inferable Yes One player
staleturn Inferable Yes One player
bare_king Inferable Yes One player
mare_king Inferable Yes One player
insufficient Inferable Yes Both players
resignation Explicit-only Yes One player
illegal_move Explicit-only Yes One player
time_limit Explicit-only Yes One player
move_limit Explicit-only Yes Both players
repetition Explicit-only Yes Both players
agreement Explicit-only Yes Both players

Status Semantics

Note on Terminology: Active Player’s Pieces

Throughout this specification, phrases like “the active player’s terminal pieces” or “pieces of the active player’s side” refer to pieces whose Side attribute matches the Active Player.

The Side attribute indicates a piece’s camp affiliation, not operational control. The rule system determines which pieces the active player can actually play. However, for status evaluation purposes (which is rule-agnostic), CGSN evaluates conditions relative to pieces matching the active player’s side.

This distinction is important in variant games where players might control opponent pieces, but CGSN statuses are evaluated based on side affiliation.

in_progress

The game session continues with no terminal state observed. This is the default state for ongoing games.

Observable fact: “No terminal condition has been reached; the match proceeds normally.”

Terminology note: This status applies when the Active Player can make at least one Legal Move, though CGSN itself does not determine legality—that is the rule system’s responsibility.

checkmate

All Terminal Pieces of the active player’s side are in Check State. Mechanically Possible Moves exist, but all such moves would result in at least one terminal piece remaining in or being placed in check state.

Observable fact: “All terminal pieces of the active player’s side are in check state, and all mechanically possible moves would leave or place terminal pieces in check state.”

Formal definition:

  1. All terminal pieces in check: Each terminal piece whose Side attribute matches the Active Player can be captured by at least one opponent move (based on piece movement capabilities)
  2. Moves mechanically possible: At least one Mechanically Possible Move exists (conforming to piece movement capabilities and protocol constraints, without regard to check state constraints)
  3. All moves violate check constraint: Every Mechanically Possible Move would result in at least one terminal piece of the active player’s side remaining in or being placed in check state

Rule-agnostic interpretation: Whether this results in victory for the opponent, defeat for the active player, or other outcome depends entirely on the rule system.

Examples across game types:

Note on check state evaluation: Check State evaluates whether the opponent could capture the terminal piece using a Mechanically Possible Move. In rule systems that permit leaving terminal pieces in check state (where such moves would be Legal Moves), checkmate can still be evaluated as a position where all terminal pieces are capturable and no mechanically possible move would change this.

Nature of blockage: Mechanically possible moves exist, but all would violate the check constraint. The blockage is rule-based (constraint about check states), not mechanical.

Relationship to move hierarchy: The distinction here is between Mechanically Possible Moves and Legal Moves. Checkmate occurs when mechanically possible moves exist, but none would satisfy the check constraint that the rule system imposes for legality.

stalemate

At least one Terminal Piece of the active player’s side is not in Check State. Mechanically Possible Moves exist, but all such moves would place at least one terminal piece of the active player’s side in check state.

Observable fact: “At least one terminal piece of the active player’s side is not in check state, but all mechanically possible moves would place at least one terminal piece in check state.”

Formal definition:

  1. Not all in check: At least one terminal piece whose Side attribute matches the Active Player is not capturable by any opponent move (based on piece movement capabilities)
  2. Moves mechanically possible: At least one Mechanically Possible Move exists (conforming to piece movement capabilities and protocol constraints, without regard to check state constraints)
  3. All moves violate check constraint: Every Mechanically Possible Move would result in at least one terminal piece of the active player’s side being placed in check state

Rule-agnostic interpretation:

Distinction from checkmate: In stalemate, at least one terminal piece of the active player’s side is NOT currently in check state. In checkmate, ALL such terminal pieces are currently in check state.

Distinction from staleturn: In stalemate, Mechanically Possible Moves exist but all would violate the check constraint (placing terminal pieces in check). In staleturn, no mechanically possible moves exist at all, regardless of check considerations.

Examples:

Nature of blockage: Mechanically possible moves exist, but all would violate the check constraint. The blockage is rule-based (constraint about check states), not mechanical.

Relationship to move hierarchy: Like checkmate, this involves the distinction between Mechanically Possible Moves and Legal Moves. Stalemate occurs when mechanically possible moves exist, but none would satisfy the check constraint for legality.

staleturn

No Mechanically Possible Moves exist for any piece of the active player’s side according to piece movement capabilities. Every piece whose Side attribute matches the Active Player is physically blocked from moving.

Observable fact: “No moves are mechanically possible for any piece of the active player’s side; all pieces are blocked according to their movement patterns.”

Formal definition:

Rule-agnostic interpretation: Different rule systems may treat this as:

Distinction from stalemate: In staleturn, no pieces can move at all due to physical blockage according to piece movement patterns. The blockage is mechanical (based purely on movement capabilities and board geometry), not caused by rule-based constraints about check states.

Distinction from checkmate: In checkmate, Mechanically Possible Moves exist but all would leave/place terminal pieces in check. In staleturn, no mechanically possible moves exist at all.

Examples:

Nature of blockage: The blockage is purely mechanical/geometric - pieces cannot physically move according to their movement patterns (as determined by their Name, State, and Style attributes), independent of any rule constraints about check states or other game-specific rules.

Note on rarity: Staleturn is significantly rarer than stalemate and may indicate unusual board configurations, variant-specific positions, or composed problems rather than positions arising from normal play.

Relationship to move hierarchy: This status indicates that no Mechanically Possible Moves exist, which is more restrictive than both checkmate and stalemate where such moves do exist but would violate check constraints.

bare_king

Only Terminal Pieces remain on the board for at least one side, with all other pieces of that side having been captured or removed.

Observable fact: “One side is reduced to terminal piece(s) only, with no supporting pieces remaining.”

Formal definition:

Rule-agnostic interpretation:

Support for multiple terminal pieces: This status applies when a player has only their terminal pieces remaining, regardless of how many terminal pieces the game allows per player.

Examples:

Terminology note: “One side” refers to pieces sharing the same Side attribute value.

mare_king

All Terminal Pieces of one player’s side have been physically captured and removed from the board.

Observable fact: “All terminal pieces of one side have been captured and removed from play.”

Formal definition:

Rule-agnostic interpretation: This typically indicates game termination, but the competitive outcome depends on the rule system. Common in variants where leaving terminal pieces in Check State is permitted by rule, allowing actual capture to occur.

Distinction from checkmate: In checkmate, terminal pieces remain on the board in check state with all mechanically possible moves leaving/placing them in check. In mare_king, the capture has actually occurred and terminal pieces no longer exist on the board.

Support for multiple terminal pieces: This status is only recorded when all terminal pieces of one side have been captured. If a player has multiple terminal pieces and only some are captured, the game continues (unless other rules terminate it).

Examples:

Note on zero terminal pieces: In rule systems that define no terminal pieces for any player, this status cannot occur as there are no pieces designated as terminal.

Terminology note: “One player’s side” refers to pieces sharing the same Side attribute value.

insufficient

Neither player possesses sufficient material to force any Terminal State under the applicable game rules. The specific material combinations considered insufficient depend on the rule system and its winning conditions.

Observable fact: “Neither side can force any decisive outcome with remaining material according to the rule system’s terminal state definitions.”

Formal definition (rule-dependent):

Rule-agnostic interpretation:

Note on evaluation: This status is rule-dependent in its evaluation but position-derivable once rules are known. The definition of “sufficient material” varies significantly across rule systems.

Examples:

resignation

A player voluntarily resigned from the game. This is a player action, not a position state.

Observable fact: “A player resigned from the match.”

Rule-agnostic interpretation: Which player resigned and the consequences of resignation are determined by the rule system. Typically, the resigning player loses, but the outcome is rule-dependent.

Note: Resignation is a speech act or declared intention, not derivable from board position. It must always be explicitly recorded.

Terminology note: This status records the fact of resignation without indicating which player resigned or the competitive outcome. Integration formats like PCN provide additional fields (such as winner) to clarify outcomes.

illegal_move

An illegal move was made during the game. The specific nature of the illegality, how it was discovered, and the consequences are rule-dependent and may vary by competition format.

Observable fact: “A move was performed that violated the rule system’s constraints.”

Rule-agnostic interpretation: The response (correction, forfeit, etc.) depends on the rule system and competitive context.

Examples of illegality:

Relationship to move hierarchy: An illegal move is one that violates Legal Move constraints, which may include:

time_limit

A player exceeded their allocated time under the applicable time control.

Observable fact: “A player exceeded their time limit as defined by the time control rules.”

Rule-agnostic interpretation: The time limit and consequences are rule-dependent and may vary by competition format. Typically, the player who exceeded time loses.

Note: Time information is external to position and must be tracked separately. Time control systems may use various schemes (Fischer increment, byōyomi periods, etc.) as defined in integration formats like PCN.

Terminology note: This status records the fact of time expiration without indicating which player exceeded time or the competitive outcome. Integration formats like PCN provide additional fields to clarify outcomes.

move_limit

The game reached a maximum move count defined by the applicable rules.

Observable fact: “The maximum number of moves as defined by the rule system was reached.”

Rule-agnostic interpretation: The specific limit and consequences are rule-dependent (draw, win for specific player, etc.).

Examples:

Note: Move count is tracked through move history, not derivable from position alone.

repetition

A position occurred multiple times according to the applicable repetition rule.

Observable fact: “Position repetition occurred according to the threshold defined by the rule system.”

Formal definition (rule-dependent):

Rule-agnostic interpretation:

Note on position equality: What constitutes “the same position” is defined by the protocol. A Position captures piece locations, piece attributes, and active player identity. Position uniqueness is enforced through canonical representation.

Note on position uniqueness constraint: The protocol enforces that “all Positions within a Match must be unique” - no player may execute a move that produces a position identical to any previous position. The repetition status indicates this constraint was violated or approached (depending on rule system thresholds).

Relationship to Pass Moves: A Pass Move that results in a position identical to a previous position violates the uniqueness constraint. However, if the position after a pass move is unique (e.g., due to the active player changing), the pass is valid under the protocol.

agreement

Players mutually agreed to end the game. This is a collaborative action, not a position state.

Observable fact: “Players agreed to conclude the match.”

Rule-agnostic interpretation: The circumstances under which agreement is permitted and its consequences are rule-dependent. May result in draw, specific winner, or other outcome.

Note: Agreement is a speech act requiring consent from both players, not derivable from board position.

Terminology note: This status records the fact of mutual agreement without specifying the competitive outcome. Integration formats like PCN provide additional fields to clarify outcomes.

Hierarchical Relationship: checkmate / stalemate / staleturn

These three statuses form a conceptual hierarchy based on two independent dimensions:

Dimension 1: Check State of Terminal Pieces

Dimension 2: Nature of Blockage and Move Hierarchy

All three involve the active player being unable to make a satisfactory Legal Move, but differ in where the constraint lies within the move hierarchy:

Relationship to Move Hierarchy from Glossary

The glossary defines the following hierarchy:

Protocol-Valid Move
    ↓ (+ piece movement capabilities)
Mechanically Possible Move / Pseudo-Legal Move
    ↓ (+ rule system constraints)
Legal Move

Within this hierarchy:

Visual Hierarchy

Active player cannot make a Legal Move
│
├─ Are Mechanically Possible Moves available?
│  │
│  ├─ NO → staleturn (mechanical blockage)
│  │
│  └─ YES (but all violate check constraint)
│     │
│     └─ Are all terminal pieces currently in check?
│        │
│        ├─ YES → checkmate
│        │
│        └─ NO (at least one not in check) → stalemate

Key Insight

The fundamental distinction is between:

Within the rule-based constraint category, the distinction between checkmate and stalemate is simply whether all terminal pieces are currently in check (checkmate) or at least one is not (stalemate).

This hierarchy directly reflects the move hierarchy defined in the glossary, where Mechanically Possible Moves represent an intermediate level between Protocol-Valid Moves and Legal Moves.

Relationship to Terminal States

CGSN status values describe observable conditions that may indicate Terminal States. A Terminal State is “an observable condition indicating that the match has reached its conclusion.”

The relationship between CGSN statuses and match termination is entirely rule-dependent:

Terminal state indicators (typically end the match):

Non-terminal conditions (game typically continues):

Critical distinction: CGSN records what is observed, not whether the match should terminate. The protocol can identify when observable terminal conditions occur, but does not prescribe their competitive interpretation.

The protocol further clarifies: “A Terminal State is reached when no Protocol-Valid Moves remain that would produce a unique Position, or when an external terminal condition (resignation, time expiration, mutual agreement) occurs.”

Design Properties

Examples

See CGSN Examples for practical usage across different game scenarios.

Reference Implementations

Ruby