Chess Game Status Notation (CGSN) Specification

Version: 1.0.0
Author: Cyril Kato
Published: November 8, 2025
License: Open Web Foundation Agreement 1.0

1. Status of this document

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as normative requirements.

Capitalized terms (Game, Rule System, Match, Game State, Position, Terminal Piece, Protocol-Valid Move, Pseudo-Legal Move, Legal Move, Piece, Piece Side, Player Side, Board, Hand, Active Player, Inactive Player) are defined in the Glossary. This document does not redefine those terms.

2. Overview

Chess Game Status Notation (CGSN) defines a finite list of game status values for two-Player, turn-based abstract strategy board games implemented on top of the Sashité Game Protocol.

A game status (or simply status) is:

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

3. Dependencies

None. CGSN is a foundational notation and does not depend on other Sashité specifications.

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).

4. Scope

4.1 What CGSN defines

CGSN defines:

a vocabulary of standardized status identifiers,
a classification system distinguishing Position-inferable from explicit-only statuses,
formal definitions for each status value,
composition rules for status combinations.

4.2 What CGSN does not define

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,
the transport or storage format for statuses (that belongs to notations like PCN).

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

5. Status classification system

CGSN divides game status values into two fundamental categories based on observability.

5.1 Position-inferable statuses

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

Knowing the current Position (e.g., via a FEEN string) and the Rule System is sufficient to determine whether this status applies to the current Game State, without needing any additional information (History, clocks, explicit declarations, etc.).

Formal criterion:

Position + Rule System ⇒ Status can be computed

Key characteristics:

Can be derived algorithmically from Position analysis
Does not require external state or History
May be omitted in notation (can be reconstructed)
Verification is deterministic given the Position

5.2 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 determine whether this status applies, because extra information is required.

Formal criterion:

Position + Rule System ⊬ Status determination
Additional context required (History, clock, declaration, etc.)

Key characteristics:

Cannot be derived from Position alone
Requires external state, History, or Player actions
Must be explicitly recorded in notation
May depend on time-based or declarative events

6. Status taxonomy

CGSN organizes statuses into three conceptual groups:

6.1 Terminal Piece Statuses

Statuses that describe the condition of specific Terminal Pieces relative to Capture threats.

Scope: Evaluated per Terminal Piece of the Active Player’s Side.

Status	Inferable	Description
`check`	Yes	A specific Terminal Piece can be captured by an Inactive Player’s Pseudo-Legal Move
`stale`	Yes	A specific Terminal Piece cannot be captured by any Inactive Player’s Pseudo-Legal Move
`checkmate`	Yes	A specific Terminal Piece is in check and remains in check after all Pseudo-Legal Moves
`stalemate`	Yes	A specific Terminal Piece is stale but would be in check after all Pseudo-Legal Moves

Note: For any given Terminal Piece in a Position, exactly one of check or stale applies.

6.2 Position Statuses

Statuses that describe global properties of the current Position.

Status	Inferable	Description
`nomove`	Yes	No Pseudo-Legal Moves exist for the Active Player
`bareking`	Yes	At least one Side has exactly one Terminal Piece remaining on the Board, with no other Pieces
`mareking`	Yes	At least one Side has no Terminal Pieces on the Board
`insufficient`	Yes	Neither Side can force a decisive outcome with available material

6.3 External Event Statuses

Statuses that describe Player actions or rule violations external to the Position.

Status	Inferable	Description
`resignation`	No	A Player explicitly resigned
`illegalmove`	No	A played Move violated legality constraints
`timelimit`	No	A Player exceeded the time control limit
`movelimit`	No	The Match reached a Move count limit
`repetition`	No	A Position repeated according to the Rule System’s policy
`agreement`	No	Both Players mutually agreed to end the Match

7. Complete status list

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

Extensibility: Implementations MAY define additional, non-standard statuses, but the names listed above MUST keep the semantics defined in this specification if used.

8. Formal definitions: Terminal Piece Statuses

The following statuses describe the threat condition of individual Terminal Pieces. All definitions assume:

A = the Active Player
S = the Player Side of A
T = a Terminal Piece with Piece Side = S currently on the Board
P = the current Position

8.1 `check`

Informal: A Terminal Piece of the Active Player’s Side is under threat of Capture.

Formal definition:

Terminal Piece T is in check in Position P iff:
  ∃ Pseudo-Legal Move m for the Inactive Player such that:
    applying m results in T being captured
    (typically via a Board → Hand Displacement)

Key points:

Evaluated per Terminal Piece
Based on Inactive Player’s Pseudo-Legal Moves
Independent of whether self-check is allowed
Does not prescribe any consequence

Example: In chess, a king on e8 threatened by a rook on e1 is in check.

8.2 `stale`

Informal: A Terminal Piece of the Active Player’s Side is not under threat of Capture.

Formal definition:

Terminal Piece T is stale in Position P iff:
  ∄ Pseudo-Legal Move m for the Inactive Player such that:
    applying m results in T being captured

Equivalently:

T is stale ⟺ T is not in check

Key points:

The logical negation of check
For any Terminal Piece, exactly one of {check, stale} applies
Represents the “safe” or “normal” state

Example: In chess, a king on e8 with no attacking Pieces is stale.

8.3 `checkmate`

Informal: A Terminal Piece is in check, and the Active Player cannot make any Move that removes the check from that same Piece.

Formal definition:

Terminal Piece T is in checkmate in Position P iff:
  1. T is in check in P
  AND
  2. ∃ at least one Pseudo-Legal Move for the Active Player
  AND
  3. ∀ Pseudo-Legal Move m for the Active Player:
     Let P' = Position after applying m
     If T still exists on the Board in P':
       T is in check in P'

Key points:

Combines three conditions: current check, Moves exist, all Moves preserve check
Evaluated for the same Terminal Piece before and after each Move
If the Terminal Piece is captured during the Move, this condition does not apply to that Move (but such Moves are typically illegal in most Rule Systems)
Does not define consequences (win/loss)

Example: In chess, Scholar’s Mate where the black king cannot escape check.

8.4 `stalemate`

Informal: A Terminal Piece is stale (safe), but all possible Moves would put that same Piece in check.

Formal definition:

Terminal Piece T is in stalemate in Position P iff:
  1. T is stale in P (not in check)
  AND
  2. ∃ at least one Pseudo-Legal Move for the Active Player
  AND
  3. ∀ Pseudo-Legal Move m for the Active Player:
     Let P' = Position after applying m
     T is in check in P'

Key points:

The “dual” of checkmate: starts stale, all Moves lead to check
Evaluated for the same Terminal Piece before and after each Move
Does not define consequences (draw/loss/other)

Example: In chess, a Position where the king is safe but any Move puts it in check.

9. Formal definitions: Position Statuses

These statuses describe global properties of the Position, not tied to specific Pieces.

9.1 `nomove`

Informal: The Active Player has no mechanically possible Moves.

Formal definition:

Status nomove applies to Position P iff:
  ∄ Pseudo-Legal Move for the Active Player in P

Key points:

Purely mechanical/geometric constraint
Independent of check status
Does not consider Terminal Pieces
Expresses complete blockage of movement

Distinction from mates:

checkmate = Terminal Piece in check + all Moves preserve check
stalemate = Terminal Piece stale + all Moves create check
nomove = no Moves exist at all (independent of check)

Example: A king completely surrounded by own Pieces with no Legal Moves.

9.2 `bareking`

Informal: At least one Side has exactly one Terminal Piece remaining on the Board, with no other Pieces.

Formal definition:

Status bareking applies to Position P iff:
  ∃ Player Side S such that:
    Let B_S = {all Pieces with Piece Side = S on the Board}
    1. |B_S| = 1  (exactly one Piece on the Board for Side S)
    AND
    2. That single Piece is a Terminal Piece

Key points:

Represents the classic “bare king” situation: a single, unsupported Terminal Piece
Only counts Board occupancy (Pieces in Hands are not considered)
In Games with multiple Terminal Pieces per Side, this status applies when only one remains
Does not prescribe consequences (may be insufficient material, may be a loss condition, etc.)

Example: In chess, one Side has only its king remaining on the Board; all other Pieces (pawns, rooks, knights, bishops, queen) have been captured.

Note: If a Game has multiple Terminal Pieces per Side and all remain on the Board with no other Pieces, this is NOT bareking — it would be a different condition (e.g., “barekings” or similar).

9.3 `mareking`

Informal: At least one Side has no Terminal Pieces on the Board.

Formal definition:

Status mareking applies to Position P iff:
  ∃ Player Side S such that:
    ∄ Terminal Piece with Piece Side = S on the Board

Key points:

Terminal Pieces may be captured and held in Hands
Only checks Board presence
Does not define what this means for the Match

Example: In a hypothetical variant where kings can be captured, a Side with its king in the Inactive Player’s Hand.

9.4 `insufficient`

Informal: Neither Player has sufficient material to force a decisive outcome.

Formal definition:

Status insufficient applies to Position P iff:
  Given the Rule System R and Position P:
    ∄ sequence of Legal Moves that leads to a Position
    that R classifies as "decisive" for either Player

Key points:

Highly Rule System-specific
Position-inferable only when insufficiency rules are precisely defined
May include both material and positional considerations

Examples:

Chess: King vs King
Chess: King + Knight vs King
Chess: King + Bishop vs King + Bishop (same color)

10. Formal definitions: External Event Statuses

These statuses cannot be determined from Position + Rule System alone. They require additional context.

10.1 `resignation`

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

Required information: Player declaration or action external to the Position.

Note: CGSN does not encode which Player resigned or the resulting outcome. Those details belong to the surrounding notation or Rule System.

10.2 `illegalmove`

Definition: A Move that was played is recognized as not being a Legal Move under the Game Protocol and Rule System.

Required information: The Move History and the legality validation result.

Possible reasons (not distinguished by CGSN):

Structurally invalid (not Protocol-Valid)
Movement-invalid (not Pseudo-Legal)
Rule-invalid (violates self-check, repetition, or other constraints)

Note: CGSN only records the fact; consequences (loss, rewind, correction) are Rule System-defined.

10.3 `timelimit`

Definition: A Player exceeds the allotted time defined by the current time control.

Required information: Clock state, time control parameters.

Note: Cannot be inferred from FEEN + Rule System. Must be tracked externally.

10.4 `movelimit`

Definition: The Match reaches a Move-count limit defined by the rules or competition regulation.

Required information: Move History, limit threshold.

Examples:

Maximum total Ply count
Fifty-move rule (chess)
Repetition counters

Note: Counting methods are Game-specific and History-dependent.

10.5 `repetition`

Definition: The same Position occurs a specified number of times during the Match, according to the Rule System’s repetition policy.

Required information:

Move History
Position equality definition (may extend Position Identity)
Repetition threshold (e.g., 3-fold, 4-fold)

Note: CGSN provides the name; the Rule System defines the threshold, equality criteria, and consequences.

10.6 `agreement`

Definition: Both Players mutually agree to end the Match.

Required information: Joint Player declaration or action.

Note: Commonly associated with draws, but CGSN does not assume any outcome. How agreements are handled belongs to the Rule System or competition rules.

11. Status composition rules

11.1 Terminal Piece Status exclusivity

For any single Terminal Piece in a Position:

Rule 1: Exactly one of {check, stale} applies.

check(T) ⊕ stale(T)  (exclusive OR)

Rule 2: At most one of {checkmate, stalemate} applies.

checkmate(T) ⇒ check(T)
stalemate(T) ⇒ stale(T)
checkmate(T) ∧ stalemate(T) = False

11.2 Multiple Terminal Pieces

When a Side has multiple Terminal Pieces, status evaluation is per Piece:

Each Terminal Piece independently has a {check, stale} status
Each Terminal Piece may independently be in {checkmate, stalemate}
The Game State may simultaneously report different statuses for different Terminal Pieces

Example: In a hypothetical multi-king variant:

{
  "terminal_pieces": {
    "king1": "check",
    "king2": "stale"
  }
}

11.3 Cross-category combinations

Terminal Piece Statuses (§6.1) and Position Statuses (§6.2) are independent dimensions:

A Terminal Piece can be in check while nomove applies
A Position can be bareking and have a Terminal Piece in checkmate

External Event Statuses (§6.3) can combine with any other status:

resignation can occur when a Terminal Piece is in check
timelimit can occur simultaneously with checkmate

11.4 Notation guidelines

Single status recording:

When only one status is relevant or dominant:

{
  "status": "checkmate"
}

Multiple status recording:

When multiple statuses coexist:

{
  "status": ["check", "timelimit"]
}

Or for per-Piece Terminal statuses:

{
  "terminal_status": {
    "first": "check",
    "second": "stale"
  }
}

Note: The exact format for multiple statuses is not prescribed by CGSN. It belongs to the enclosing notation (e.g., PCN).

12. Extensibility

12.1 Custom statuses

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

Reserved names: CGSN-defined names (§7) MUST keep the semantics specified here
Namespace convention: Custom statuses SHOULD use a clear prefix or naming scheme to distinguish them
Documentation: Custom status semantics and inferability classification SHOULD be clearly documented

Example custom statuses:

{
  "status": "x-perpetual-check"
}

12.2 Future versions

Future versions of CGSN MAY:

Add new standardized statuses
Refine existing definitions
Introduce sub-categories or tags

Backward compatibility: New versions MUST NOT change the semantics of existing v1.0.0 status values.

13. Examples

See CGSN Examples for practical implementation guidance illustrating:

Position-inferable vs explicit-only statuses in context
Per-Piece Terminal Piece status evaluation
Cross-Game applicability (chess, shōgi, xiangqi)
Integration with PCN notation

14. Reference implementations

The following reference libraries are maintained by Sashité and are intended to be idiomatic, fully tested, and spec-accurate implementations of CGSN v1.0.0.

They generally provide:

strict parsing and validation (valid?, parse, and a raising/bang variant),
clear error reporting for invalid inputs.

If a library behavior appears to conflict with this document, this specification is normative. Please report issues (or propose clarifications) on the relevant repository.

Elixir — cgsn.ex
Ruby — cgsn.rb

15. License

This specification is made available under the terms of the Open Web Foundation Agreement 1.0 (OWFa 1.0).

The authoritative legal text is the OWF “Final Specification Agreement (OWFa 1.0)”.

Chess Game Status Notation (CGSN) Specification

1. Status of this document

2. Overview

3. Dependencies

4. Scope

4.1 What CGSN defines

4.2 What CGSN does not define

5. Status classification system

5.1 Position-inferable statuses

5.2 Explicit-only statuses

6. Status taxonomy

6.1 Terminal Piece Statuses

6.2 Position Statuses

6.3 External Event Statuses

7. Complete status list

8. Formal definitions: Terminal Piece Statuses

8.1 check

8.2 stale

8.3 checkmate

8.4 stalemate

9. Formal definitions: Position Statuses

9.1 nomove

9.2 bareking

9.3 mareking

9.4 insufficient

10. Formal definitions: External Event Statuses

10.1 resignation

10.2 illegalmove

10.3 timelimit

10.4 movelimit

10.5 repetition

10.6 agreement

11. Status composition rules

11.1 Terminal Piece Status exclusivity

11.2 Multiple Terminal Pieces

11.3 Cross-category combinations

11.4 Notation guidelines

12. Extensibility

12.1 Custom statuses

12.2 Future versions

13. Examples

14. Reference implementations

15. License

8.1 `check`

8.2 `stale`

8.3 `checkmate`

8.4 `stalemate`

9.1 `nomove`

9.2 `bareking`

9.3 `mareking`

9.4 `insufficient`

10.1 `resignation`

10.2 `illegalmove`

10.3 `timelimit`

10.4 `movelimit`

10.5 `repetition`

10.6 `agreement`