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

Location Condition Notation (LCN) Specification

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 (Board, Square, Location, Piece, Active Player, Inactive Player, Game Protocol, Rule System) are defined in the Glossary. This document does not redefine those terms.

2. Overview

Location Condition Notation (LCN) is a rule-agnostic, JSON-based format for describing Location conditions in abstract strategy board games. LCN provides a standardized way to express constraints on Board Locations, defining what states specific Locations should have.

LCN is a foundational specification designed to be used by other formats that require Location state definitions. LCN defines the format only — the interpretation and evaluation of conditions is the responsibility of consuming specifications.

3. Dependencies

LCN builds upon two foundational Sashité specifications:

Specification Purpose
CELL Multi-dimensional coordinate encoding for Board positions
QPI Qualified Piece Identifier for unambiguous Piece identification

4. Scope

4.1 What LCN defines

LCN defines:

4.2 What LCN does not define

LCN is deliberately format-only. It does not define:

All evaluation semantics belong to consuming specifications, not to LCN.

5. Format specification

5.1 JSON structure

An LCN object is a JSON object where:

{
  "<cell-coordinate>": "<state-value>"
}

5.2 Grammar (EBNF)

lcn-object     ::= "{" [ condition-list ] "}" ;
condition-list ::= condition ( "," condition )* ;
condition      ::= cell-key ":" state-value ;
cell-key       ::= json-string ;   (* Must conform to CELL specification *)
state-value    ::= keyword | qpi-identifier ;
keyword        ::= '"empty"' | '"enemy"' ;
qpi-identifier ::= json-string ;   (* Must conform to QPI specification *)

5.3 Empty object

An empty LCN object ({}) represents no conditions — all Location states are acceptable.

6. State value types

6.1 Reserved keywords

LCN defines two reserved keywords for common Location states:

Keyword Intended meaning
"empty" Intended to represent an unoccupied Location
"enemy" Intended to represent a Location occupied by a Piece from the opposing Side

These descriptions convey the conventional intent of each keyword. Because LCN is format-only (§4.2), the keywords carry no normative evaluation semantics within LCN itself. Consuming specifications MUST define exactly how each keyword is evaluated in their context (see §8).

Note — absent keywords ("ally", "occupied"): LCN does not define "ally" or "occupied" keywords. Both constraints can be expressed only through negation, which is outside LCN’s scope:

Consuming specifications that need to express either constraint SHOULD implement it via negation over the corresponding LCN condition (e.g., deny: { "a1": "enemy" } for an allied-Piece requirement in GGN), and MUST document this pattern clearly.

6.2 Piece identifiers

In addition to keywords, LCN accepts QPI identifiers to specify exact Piece requirements:

7. Validation rules

7.1 Structural validation

An LCN document MUST satisfy:

  1. JSON object — The document MUST be a valid JSON object.
  2. String keys — All keys MUST be JSON strings.
  3. String values — All values MUST be JSON strings.

7.2 Format validation

An LCN document MUST satisfy:

  1. Valid CELL keys — Keys MUST conform to the CELL coordinate specification.
  2. Valid state values — Values MUST be either:
    • One of the reserved keywords ("empty" or "enemy"), OR
    • A valid QPI identifier.

7.3 Semantic validation

Semantic validation is the responsibility of consuming specifications. Implementations MAY validate:

8. Semantic interpretation

8.1 Evaluation requirements

Important: LCN defines the format for expressing Location conditions, but does not specify how these conditions should be evaluated.

Consuming specifications MUST define:

8.2 Enemy keyword evaluation

The "enemy" keyword requires an evaluation perspective to determine which Pieces are considered “enemy” Pieces. Consuming specifications MUST specify this perspective.

Standard interpretation: In most use cases within the Sashité ecosystem, the "enemy" keyword is evaluated from the Active Player’s perspective:

This standard interpretation ensures consistency across specifications and aligns with the Glossary’s concept of Active/Inactive Players.

Alternative interpretations: Consuming specifications MAY define different evaluation perspectives if needed for specific use cases, but SHOULD document this clearly to avoid confusion.

8.3 Implementation considerations

Systems implementing LCN evaluation MUST:

  1. Receive evaluation context — The consuming specification MUST provide the necessary context (e.g., Active Player information) to evaluate "enemy" correctly.
  2. Document perspective — Clearly state which perspective is used for "enemy" evaluation.
  3. Handle edge cases — Define behavior for ambiguous situations (e.g., neutral Pieces, if supported by the Game system).

9. Format examples

9.1 Basic conditions

Single empty Location:

{
  "e4": "empty"
}

Single enemy Location:

{
  "f5": "enemy"
}

9.2 Multiple conditions

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

9.3 Specific Piece requirements

{
  "h1": "C:+R",
  "e1": "C:K^"
}

9.4 Mixed constraints

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

9.5 Empty conditions

{}

No conditions — all Location states are acceptable.

10. Usage patterns

10.1 Path verification

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

Checking that intermediate Locations are clear.

10.2 Capture requirements

{
  "e5": "enemy"
}

Requiring an opponent Piece at the target Location.

10.3 Special Move conditions

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

Complex conditions for special Moves like castling.

10.4 File/rank restrictions

{
  "e1": "S:P",
  "e2": "S:P",
  "e3": "S:P"
}

Checking for specific Piece distributions.

11. Integration guidelines

11.1 For consuming specifications

Specifications that use LCN SHOULD:

  1. Define evaluation semantics — Clearly specify how each state value type is evaluated.
  2. Specify evaluation perspective — Define the perspective for "enemy" evaluation (typically Active Player).
  3. Document composition logic — Define how multiple conditions are combined (AND, OR, etc.).
  4. Explain constraints — Document any usage restrictions or requirements.
  5. Provide examples — Show LCN usage within the consuming specification’s context.
  6. Document negation patterns — If the consuming specification supports negation of LCN conditions (e.g., to express allied-Piece constraints), document this pattern explicitly.

11.2 Common integration patterns

12. Design properties

LCN is intended to be:

13. JSON Schema

A JSON Schema for LCN is published for programmatic validation:

Implementations MAY rely on this schema as a baseline validator and add further semantic checks as needed.

14. Examples

See LCN Examples for practical implementation guidance.

15. Reference implementations

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

They generally provide:

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

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