Sashité for Developers
  1. Sashité for Developers
  2. Specifications
  3. LCN
  4. 1.0.0
  5. Examples

LCN Examples

Essential format patterns for Location Condition Notation v1.0.0.


Quick Reference

Value type Example Intended meaning
"empty" { "e4": "empty" } Location is intended to be unoccupied
"enemy" { "f5": "enemy" } Location is intended to contain an opposing Piece
QPI identifier { "h1": "C:+R" } Location is intended to contain exactly the specified Piece
(none) {} No constraints — all Location states are acceptable

Evaluation note: How these values are evaluated (including what perspective is used for "enemy") is defined by the consuming specification, not by LCN. See the LCN specification §8 for details.


1. Empty Object

{}

No conditions — all Location states are acceptable. Valid LCN format.


2. Single "empty" Condition

{
  "e4": "empty"
}

One Location constrained to be unoccupied.


3. Single "enemy" Condition

{
  "f5": "enemy"
}

One Location constrained to contain an opposing Piece. Evaluated from the Active Player’s perspective in standard Sashité usage.


4. Multiple "empty" Conditions — Path Clearance

{
  "b2": "empty",
  "c3": "empty",
  "d4": "empty"
}

All intermediate Locations along a path must be unoccupied. Typical use: verifying a sliding piece’s trajectory is not blocked.


5. Specific Piece Requirement — QPI Identifier

{
  "h1": "C:+R"
}

The Location h1 must contain exactly the Piece identified by C:+R (an enhanced Chess Rook on Side first). QPI identifiers encode Style, Side, State, and Terminal Status unambiguously.


6. Mixed Conditions — Keywords and QPI Identifiers

{
  "f1": "empty",
  "g1": "empty",
  "h1": "C:+R"
}

Combines "empty" constraints with an exact Piece requirement. Typical use: verifying castling eligibility — squares between the King and Rook must be clear, and the Rook must be in place.


7. Mixed Conditions — Empty and Enemy

{
  "b2": "empty",
  "c3": "empty",
  "d4": "enemy"
}

Intermediate squares must be clear; the target square must contain an opposing Piece. Typical use: a long-range capture where the path must be unobstructed.


8. Multiple Piece Requirements — Same Type

{
  "e1": "C:K^",
  "e3": "C:K^"
}

Multiple Locations constrained to the same Piece type. Typical use: verifying a positional pattern involving several identical Pieces.


Game-Specific Patterns

Chess — Kingside Castling

{
  "f1": "empty",
  "g1": "empty",
  "h1": "C:+R"
}

Squares f1 and g1 must be clear; the unmoved Rook (C:+R, enhanced state encoding its virginity in this convention) must be at h1.

Chess — Queenside Castling

{
  "b1": "empty",
  "c1": "empty",
  "d1": "empty",
  "a1": "C:+R"
}

Three squares must be clear between King and Rook.

Chess — En Passant

{
  "f6": "empty",
  "f5": "c:-p"
}

The destination square f6 must be empty; f5 must contain the opposing pawn eligible for en passant capture (encoded here with a diminished state marking its vulnerability in this convention).

Chess — Diagonal Pawn Capture

{
  "f5": "enemy"
}

The target square must contain an opposing Piece.

Chess — Facing Kings

{
  "e1": "C:K^",
  "e3": "c:k^"
}

Both Kings are on the same file with one empty square between them. Typical use: verifying the “opposition” or a “facing kings” rule.


Shōgi — Drop Destination

{
  "e4": "empty"
}

The target square must be unoccupied before a Piece is dropped there.

Shōgi — Nifu (No Double Pawn) Check

{
  "e1": "S:P",
  "e2": "S:P",
  "e3": "S:P",
  "e5": "S:P",
  "e6": "S:P",
  "e7": "S:P",
  "e8": "S:P",
  "e9": "S:P"
}

Checks whether the file already contains a friendly Pawn before allowing a drop. The square e4 — the intended drop destination — is intentionally absent from the condition: the rule prohibits dropping if any other square on the file already holds a friendly Pawn.

Shōgi — Promotion Zone Verification

{
  "e5": "S:P"
}

A single Pawn at a specific square, used as a precondition for checking promotion eligibility.


Xiangqi — Cannon Screen

{
  "b7": "enemy"
}

For a Cannon capture, exactly one Piece (the “screen”) must intervene between the Cannon and its target. Here the screen square must contain an opposing Piece.

Xiangqi — Cannon Path

{
  "c7": "empty",
  "d7": "empty"
}

Squares between the Cannon and its screen must be unoccupied.

Xiangqi — Facing Generals

{
  "e2": "empty",
  "e3": "empty",
  "e4": "empty",
  "e5": "empty",
  "e6": "empty",
  "e7": "empty",
  "e8": "empty"
}

When checking the “facing generals” rule, all squares between the two Generals on the same file must be empty. The Generals themselves (X:G^ at e1 and x:g^ at e9) are not part of the LCN condition — they are already known from the position.


Format Notes

Property Rule
Keys Must be valid CELL coordinates
Values Must be "empty", "enemy", or a valid QPI identifier
Evaluation Defined by the consuming specification, not by LCN
Composition How multiple conditions are combined (AND, OR…) is defined by the consuming specification
"enemy" perspective Must be provided by the consuming specification (typically Active Player)
"ally" / "occupied" Not expressible as positive LCN conditions; require negation in the consuming specification

For semantic interpretation and evaluation rules, consult the specification that uses LCN.