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

Chess Game State Notation (CGSN) v1.0.0

• Name: Chess Game State Notation (CGSN)
• Version: 1.0.0
• Author: Sashité
• License: MIT License

---

Overview

CGSN defines a finite list of game state status values for two-player, turn-based abstract strategy board games implemented on top of the Sashité Game Protocol.

A game state status (or simply status) is:

• a short, lowercase identifier (e.g. checkmate, repetition), and
• a rule-agnostic description of an aspect of the current Game State.

CGSN does not define:

• how a given status affects the result of the match (win / loss / draw / other),
• whether a status is considered terminal or non-terminal,
• any scoring or tournament-specific interpretation.

Those choices belong entirely to the Rule System or to competition rules.

---

Terminology and layering

All capitalized terms used here (Game, Rule System, Match, Game State, Position, Terminal Piece, Terminal Piece Status, Protocol-Valid Move, Pseudo-Legal Move, Legal Move, etc.) are defined in the:

• Sashité Glossary, and
• Game Protocol.

CGSN adds:

• a vocabulary of game state statuses, and
• a classification of those statuses according to how they can be known.

CGSN is designed to be used together with:

• a position encoding (for example, FEEN), and
• a concrete Rule System (the rules of the game being played).

---

Status categories

CGSN divides game state statuses into two categories:

Position-inferable statuses

A status is position-inferable if, for a given Rule System:

knowing the current Position (for example, via a FEEN string) and the rules of the Game is sufficient to decide whether this status applies to the current Game State, without needing any additional information (history, clocks, explicit declarations, etc.).

In other words:

• FEEN + Rule System ⇒ the status can be inferred.

Explicit-only statuses

A status is explicit-only if, even with:

• the current Position (FEEN or equivalent), and
• full knowledge of the Rule System,

it is not possible to decide whether this status applies, because extra information is required (for example: move history, clocks, or a player’s declaration).

In other words:

• FEEN + Rule System is not enough ⇒ the status must be stored or communicated explicitly if it matters.

CGSN does not mandate how statuses are stored or transported (that is the role of match notations or APIs), but every CGSN status value is classified as either position-inferable or explicit-only.

---

List of CGSN status values

CGSN v1.0.0 defines the following status identifiers:

Status	Position-inferable
check	Yes
stale	Yes
checkmate	Yes
stalemate	Yes
nomove	Yes
bareking	Yes
mareking	Yes
insufficient	Yes
resignation	No
illegalmove	No
timelimit	No
movelimit	No
repetition	No
agreement	No

Column definition:

• Position-inferable: indicates whether the status can be derived from Position + Rule System alone (Yes) or requires explicit external information (No).

CGSN does not prevent implementations from defining additional, non-standard statuses, but:

• the names listed above MUST keep the semantics defined in this specification if used.

---

Status definitions (position-inferable)

This section defines the semantics of position-inferable statuses. All definitions are understood relative to a fixed Rule System and the current Position.

Let:

• A be the Active Player,
• S be the Player Side of A,
• T be a Terminal Piece with Piece Side = S currently on the Board.

---

check

A Terminal Piece of the active player’s side is in check.

Formal condition:

A Terminal Piece T is in check if, in the current Position, there exists at least one Pseudo-Legal Move for the opposing side whose result includes T being captured by an Action (typically a Board → Hand displacement) according to the opponent’s movement capabilities.

Key points:

• check is evaluated for a specific Terminal Piece, relative to the opponent’s Pseudo-Legal Moves.
• It depends on:
  • the current Position (e.g. FEEN),
  • piece movement rules (via the Rule System),
  • the Game Protocol’s notion of Actions and Displacements.
• It does not depend on:
  • whether the Rule System allows self-check,
  • how being in check affects outcomes.

CGSN does not say whether:

• self-check is allowed or forbidden,
• being in check is permitted or not as a Legal Move result,
• check must be announced, etc.

---

stale

A Terminal Piece of the active player’s side is stale (i.e., not in check).

Formal condition:

A Terminal Piece T is stale if, in the current Position, there exists no Pseudo-Legal Move for the opposing side whose result includes T being captured by an Action (typically a Board → Hand displacement) according to the opponent’s movement capabilities.

Key points:

• stale is the negation of check: a Terminal Piece is stale if and only if it is not in check.
• A Terminal Piece that cannot be captured by any opponent’s Pseudo-Legal Move is considered “safe” or “stale”.

Note that for a given Terminal Piece, stale and check are mutually exclusive:

• if the Terminal Piece can be captured → check applies.
• if the Terminal Piece cannot be captured → stale applies.

CGSN does not attach any particular significance to stale beyond indicating absence of threat.

---

checkmate

A Terminal Piece of the active player’s side is in check, and every Pseudo-Legal Move for the active player keeps that Terminal Piece in check.

Formal conditions:

1. A Terminal Piece T is in check.
2. There exists at least one Pseudo-Legal Move for the active player.
3. For every such Pseudo-Legal Move m, in the resulting Position:
   • T (if it remains on the Board) is still in check.

Intuition:

• the Terminal Piece is in check,
• the active player can move,
• but all movement options leave that specific Terminal Piece in check.

CGSN does not define how a Rule System interprets checkmate (win, loss, or otherwise).

---

stalemate

A Terminal Piece of the active player’s side is stale (not in check), but every Pseudo-Legal Move for the active player would result in that Terminal Piece being in check.

Formal conditions:

1. A Terminal Piece T is stale (not in check) in the current Position.
2. There exists at least one Pseudo-Legal Move for the active player.
3. For every such Pseudo-Legal Move m, in the resulting Position:
   • T is in check.

Intuition:

• the Terminal Piece is in stale (not in check),
• the active player has movement options,
• but each option would put that specific Terminal Piece in check.

CGSN does not specify how a Rule System interprets stalemate (draw, loss, or otherwise).

---

nomove

The active player has no Pseudo-Legal Moves in the current Position.

Formal condition:

• there exists no Pseudo-Legal Move for the active player.

nomove is purely mechanical / geometric:

• it does not rely on check status,
• it only expresses that no Pseudo-Legal movement is available.

A Rule System may combine nomove with other information (e.g. Terminal Piece statuses) to define its own outcomes, but that logic is outside CGSN.

---

bareking

One side has only its Terminal Pieces remaining on the Board; all its non-terminal Pieces have been removed from the Board.

Formal condition:

• for at least one Player Side S, the set of Pieces on the Board with Piece Side = S is non-empty and is exactly equal to the subset of Terminal Pieces with Piece Side = S on the Board.

This generalizes the notion of “bare king” to games where:

• each side may have one or more Terminal Pieces.

CGSN does not assume any particular consequence of bareking.

---

mareking

All Terminal Pieces of at least one side have been removed from the Board.

Formal condition:

• for at least one Player Side S, there is no Terminal Piece with Piece Side = S present on the Board.

Captured Terminal Pieces are usually held in Hands or otherwise off-board; CGSN simply checks whether they are absent from the Board.

Again, CGSN does not define how a Rule System should treat this situation.

---

insufficient

Neither player has sufficient material (and, if relevant, positional resources) to force a decisive result under the Rule System.

This status is position-inferable once the Rule System is fixed, but its concrete evaluation is Game-specific.

High-level condition (informal):

• given the current Position and the rules, no sequence of Legal Moves exists that would allow either player to force a Game State that the Rule System classifies as “decisive”.

CGSN only provides the name insufficient; the Rule System must specify:

• which configurations are considered insufficient,
• and how this status is used.

---

Status definitions (explicit-only)

These statuses cannot be determined from Position + Rule System alone. They require additional information, such as:

• match history,
• time control data,
• players’ explicit declarations,
• or tournament-specific rules.

CGSN describes what they mean, but not how they affect results.

---

resignation

A player explicitly resigns the Match according to the conventions in use (verbal, written, UI action, etc.).

• This is a player action, not a property of the Position.
• It must be recorded explicitly if relevant.

CGSN does not encode which player resigned or which result is assigned. Those details belong to the Rule System or to the surrounding notation.

---

illegalmove

A move that was actually played is recognized as not a Legal Move under the combination of:

• Game Protocol invariants, and
• Rule System constraints.

This status does not distinguish the reason:

• structurally invalid (not Protocol-Valid),
• movement-invalid (not Pseudo-Legal),
• rule-invalid (e.g. violating a self-check rule, repetition rule, drop rule, etc.).

It simply records the fact that a move was deemed Illegal.

How the Match proceeds (loss, rewind, correction, etc.) is not defined by CGSN.

---

timelimit

A player exceeds the allotted time defined by the current time control.

• Requires clock information, which is stored outside the Position (in Game State).
• Cannot be inferred from FEEN + Rule System alone.

CGSN does not specify which player lost time or what consequence follows.

---

movelimit

The Match reaches a move-count limit defined by the rules or competition regulation.

Examples (Game-dependent):

• a maximum number of moves or plies,
• a specific “no-capture / no-pawn-move” counter, etc.

Because move-count policies and counting methods are Game-specific and depend on the History, movelimit cannot be deduced from Position + Rule System alone.

CGSN merely names the condition once some external logic decides it is met.

---

repetition

The same Position (under a given definition of equality) occurs a specific number of times during the Match, as defined by the Rule System’s repetition policy.

This status depends on:

• the History of Positions,
• the Rule System’s definition of Position equality (which may extend or restrict the protocol’s Position Identity).

CGSN does not fix:

• the threshold (e.g. 3-fold, 4-fold),
• the effect of repetition.

It only provides a name to indicate that “the repetition policy has been triggered”.

---

agreement

Both players mutually agree to end the Match.

• This is a joint player action, not a property of the Position.
• Commonly associated with drawn results, but CGSN does not assume any outcome.

How such agreements are handled (allowed or not, form of agreement, outcome) is determined externally.

---

Extensibility

Implementations MAY introduce additional status values beyond those defined by CGSN, provided that:

• CGSN-defined names (check, stale, checkmate, stalemate, etc.) keep the semantics specified here, and
• any non-standard status is clearly documented and does not conflict with CGSN terms.

CGSN itself does not reserve a namespace for extensions; naming schemes are left to implementations and higher-level specifications.

---

Examples

See CGSN Examples for practical implementation guidance.

---

Reference Implementations

Ruby

• CGSN.rb — Reference implementation.