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

Portable Action Notation (PAN) Specification

Overview

Portable Action Notation (PAN) is a human-readable string format for representing:

in abstract strategy board games.

PAN provides an operator-based syntax to describe how Pieces:

PAN is rule-agnostic: it encodes requested protocol-level transformations (Displacements and Mutations). Whether such transformations are legal, and how they interact with the rest of the Position, is determined by the Rule System and other higher-level game descriptions, not by PAN itself.

PAN is also geometry-agnostic and order-agnostic:

All geometric and ordering semantics belong to Rule Systems and other higher-level game descriptions, not to PAN and not to the Game Protocol.

Key Features

Quick Examples

e2-e4       # Move from e2 to e4 (Board → Board)
d1+f3       # Move with capture at f3 (Board → Board, plus capture)
e1~g1       # Special move with implicit effects (e.g. castling)
P*e5        # Drop from Hand to Board
e7-e8=Q     # Move with piece mutation (e.g. promotion)
...         # Pass Move (no Actions, turn passes to opponent)

Terminology

For all core concepts (Game, Match, Position, Action, Move, Pass Move, Piece, Location, Board, Square, Hand, Mutation, Displacement), see the Glossary and the Game Protocol.

PAN uses these terms exactly as defined there and does not alter their meaning.

PAN introduces the following notation-specific terms:

PAN strings are intended to describe either:

PAN itself does not introduce any geometry or ordering over Locations. Any notion of axes, directions, neighborhoods, or scanning order is introduced by Rule Systems and other higher-level specifications.

Dependencies

PAN relies on two Sashité specifications:

PAN treats CELL coordinates and EPIN identifiers as opaque but syntactically validated tokens:

Format Structure

Basic Syntax

A PAN string follows this general pattern:

[piece][operator][position][transformation]

Depending on the operator, the components may encode:

Component Description Examples
Piece EPIN identifier (optional) P, +R, k'
Operator Action category -, +, ~, *, ., =
Position CELL coordinate(s) for Squares e4, h8, e2-e4
Transformation Final piece identifier (EPIN) after mutation =Q, =+S, =k'

Operators are applied between positions, or between a Piece (in Hand) and a Square, or between a Square and a Piece identifier, depending on the action type.

Operator Reference

Operator Name Primary Use
... Pass Pass Move (no Actions)
- Dash Move to empty Square (Board → Board)
+ Plus Move with capture at destination / static capture
~ Tilde Special movement with implicit effects
* Asterisk Drop from Hand to empty Square
. Period Drop from Hand with capture
= Equals In-place Mutation of a Piece

The sections below describe each category in more detail. All “Effects” subsections are informative and describe typical protocol-level interpretations; exact semantics are defined by Rule Systems.

Action and Pass Categories

PAN distinguishes:

Pass Move

Syntax: ...

The PAN code ... represents a Pass Move in the sense of the Game Protocol: a Move with zero Actions that toggles the Active Player.

...

Typical protocol-level effects (informative):

Whether Pass Moves are allowed, and under which conditions, is defined by the Rule System. If Pass Moves are forbidden, the PAN code ... is never legal in that game, even though it remains syntactically valid.

Movement Actions (Board → Board)

These PAN strings describe protocol-level Displacements from one Board Square to another. Optionally, they may also encode a Mutation of the moving Piece.

Move to Empty Square (-)

Syntax: <source>-<destination>[=<piece>]

e2-e4        # Displacement from e2 to e4
e7-e8=Q      # Displacement from e7 to e8, then Mutation into Q (e.g. promotion)

Typical protocol-level effects (informative):

Whether <destination> must be empty, and how the Mutation is interpreted, depends entirely on the Rule System and the current Position.

Move with Capture at Destination (+)

Syntax: <source>+<destination>[=<piece>]

Movement that results in a capture at the destination Square, and optionally a Mutation.

d1+f3        # Displacement from d1 to f3 with capture at f3
b7+a8=R      # Displacement from b7 to a8, capture, then Mutation (e.g. promoted rook)

Typical protocol-level effects (informative):

Whether captured Pieces go to Hands or are removed is Rule System–dependent.

Special Movement with Implicit Effects (~)

Syntax: <source>~<destination>[=<piece>]

Movement that includes implicit effects beyond the primary Displacement, such as side effects affecting other Pieces.

e1~g1        # Castling (king Displacement plus rook movement)
e5~f6        # En passant (moving pawn plus implicit capture)

Direct effect (typical interpretation):

Implicit effects (handled by the Rule System):

PAN does not enumerate these implicit Actions; it only signals their presence via the ~ operator. The Rule System and engine are responsible for applying them, including any geometry-specific considerations.

Static Capture Actions (Board → Hand / removal)

These PAN strings represent captures that do not involve the capturer’s Displacement.

Static Capture (+)

Syntax: +<square>

+d4          # Capture the Piece on d4 without moving a Piece

Typical protocol-level effects (informative):

Static captures are useful for modeling custodial captures, ranged effects, or rule-driven removals where no single Piece “moves into” the captured Piece’s Square. How such effects relate to geometry, rays, or ranges is determined by the Rule System.

Drop Actions (Hand → Board)

These PAN strings describe Displacements from a Hand to a Board Square. The Piece being dropped may or may not be explicitly indicated.

Drop to Empty Square (*)

Syntax: [<piece>]*<destination>[=<piece>]

P*e5         # Drop a pawn from Hand onto e5
*d4          # Drop a Piece whose identity is clear from context
S*c3=+S      # Drop a silver on c3 and immediately mutate it (e.g. enhanced)

Typical protocol-level effects (informative):

The Rule System defines:

PAN itself does not prescribe any particular geometry or hand structure.

Drop with Capture (.)

Syntax: [<piece>].<destination>[=<piece>]

Similar to *, but the target Square is occupied and the drop causes a capture.

L.b4         # Drop a lance onto b4, capturing the occupant

Typical protocol-level effects (informative):

Again, whether such drops are allowed in a given game and how they relate to geometry is entirely Rule System–dependent.

In-Place Mutations (=)

These PAN strings describe Mutations of Pieces at a fixed Location, without any Displacement.

Modification (=)

Syntax: <square>=<piece>

Where:

e4=+P        # Enhance the Piece at e4 (e.g. promotion)
c3=k'        # Change the Piece at c3 into a different style King (EPIN)

Typical protocol-level effects (informative):

The Rule System defines when such Mutations are allowed and what they mean tactically.

Grammar Specification

EBNF Grammar

The grammar below describes the syntactic structure of PAN strings. Semantic interpretation, including legality and geometry, is delegated to the Game Protocol and, above all, to Rule Systems.

pan = pass
    | movement
    | static-capture
    | drop
    | modification ;

pass = "..." ;

movement = move-quiet
         | move-capture
         | move-special ;

move-quiet   = square "-" square [transformation] ;
move-capture = square "+" square [transformation] ;
move-special = square "~" square [transformation] ;

static-capture = "+" square ;

drop = drop-quiet
     | drop-capture ;

drop-quiet   = [piece] "*" square [transformation] ;
drop-capture = [piece] "." square [transformation] ;

modification = square "=" piece ;

transformation = "=" piece ;

square = cell ;    (* As defined in CELL specification *)
piece  = epin ;    (* As defined in EPIN specification *)

PAN does not interpret CELL or EPIN beyond requiring them to be syntactically valid according to their respective specifications.

Validation Rules

Syntactic Validation

A PAN string is syntactically valid if:

  1. It conforms to the EBNF grammar above.
  2. All Squares (square) are syntactically valid CELL coordinates.
  3. All Pieces (piece) are syntactically valid EPIN identifiers.
  4. The operator used is one of the supported PAN operators.

Semantic Guidelines

PAN itself does not enforce semantic correctness or legality, but implementations are encouraged to consider:

  1. Meaningful transformations

    • A PAN string SHOULD correspond to an observable change in the Position or a Pass Move.

  2. Movement sanity

    • For movement Actions, <source> and <destination> SHOULD differ.

  3. Transformation consistency

    • If a transformation is present, the resulting Piece identity SHOULD differ in at least one attribute from the original (otherwise the Mutation is redundant).

  4. Context awareness

    • Some semantic checks require knowledge of the current Position, Rule System and geometry:

      • whether Squares are empty or occupied,
      • which Hands contain which Pieces,
      • whether special moves (castling, en passant, drops on occupied Squares, static captures, etc.) are permitted,
      • how CELL coordinates are embedded in the game’s Board geometry.

PAN remains neutral on these questions; they are the responsibility of higher-level logic: the Game Protocol engine and, above all, the Rule System and any geometry description used by that game.

Design Philosophy

Alignment with the Game Protocol

PAN is designed to mirror the Action and Mutation model of the Game Protocol:

The ~ operator serves as a compact notation for composite transformations (multiple Actions in one Move) when the Rule System models them as a single special Move.

Principle of Least Surprise

Operators were chosen for intuitive associations:

Separation of Concerns

PAN focuses on describing what protocol-level transformation is requested, not:

This separation keeps PAN:

Limitations and Scope

Well-suited for

Not designed for

PAN can be adapted or extended for such contexts, but such extensions lie outside this specification.

Examples

See PAN Examples for comprehensive usage patterns across different game types and Rule Systems.

Reference Implementations

Ruby