Hold And Notation Designator (HAND) Specification

Version: 1.0.0
Author: Cyril Kato
Published: June 17, 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 (Board, Square, Hand, Location, Game Protocol, Rule System) are defined in the Glossary and are not redefined here.

2. Overview

Hold And Notation Designator (HAND) provides a standardized notation for piece reserve locations in board games where pieces can be held off-board and potentially placed. HAND represents the off-board Location component, enabling universal representation of reserve mechanics across diverse game systems.

HAND complements Coordinate Encoding for Layered Locations (CELL) when both Board positions and reserve areas are needed, providing complete Location coverage for any board game system.

3. Dependencies

None. HAND is a foundational primitive with no dependencies on other Sashité specifications.

4. Scope

4.1 What HAND defines

HAND defines:

a single-character notation (*) for off-board reserve Locations,
a validation rule for that notation,
a canonical representation for all reserve areas regardless of game context.

4.2 What HAND does not define

HAND is deliberately syntax-only. It does not define:

which player owns a particular reserve,
what pieces are contained in a reserve,
any semantics about capture, drop, or placement mechanics,
any relationship between multiple reserves (if a game has more than one per player).

All semantic meaning belongs to Rule Systems, not to HAND.

5. Format specification

5.1 Structure

A HAND string consists of exactly one character:

5.2 Grammar (BNF)

<hand> ::= "*"

5.3 Regular expression

^\*$

Anchoring requirement (normative): Implementations MUST validate HAND notation using a full-string match (not a substring search). No leading or trailing characters (including whitespace) may be ignored or trimmed. Implementations MUST reject any input containing line breaks (\r or \n) and MUST NOT enable multiline anchoring modes that change the meaning of ^ and $.

6. Validation rules

A string is a valid HAND notation if and only if:

Exact match — The string MUST be exactly the single character * (U+002A ASTERISK).
No whitespace — The string MUST NOT contain any leading, trailing, or embedded whitespace.
No additional characters — The string MUST NOT contain any characters other than the asterisk.

7. Design principles

7.1 Canonical representation

All reserve Locations share the same identifier (*) regardless of game context. This design choice reflects that:

The protocol-level distinction is between Board Squares and Hands (off-board reserves)
Player ownership is determined by context, not by the Location identifier itself
Game-specific reserve semantics belong to the Rule System

7.2 CELL complementarity

HAND and CELL together provide complete Location coverage:

Location type	Notation	Examples
Board Square	CELL	`a1`, `e4`, `b2A`
Off-board reserve	HAND	`*`

7.3 Character choice

The asterisk character (*) was chosen for:

ASCII compatibility — Standard character (U+002A) available on all keyboards
Visual distinction — High contrast with CELL coordinates (which use letters and digits)
Semantic fit — Commonly associated with wildcards or special locations

8. Design properties

HAND is intended to be:

Simple — Single character representation minimizes complexity.
Rule-agnostic — Independent of specific reserve mechanics.
Universal — Works with any off-board piece management system.
CELL-complementary — Can be combined with CELL for complete Location coverage.
Context-independent — Game rules determine reserve semantics.

9. Usage within the Game Protocol

Within the Game Protocol:

A HAND notation identifies a Hand Location (off-board reserve).
The protocol defines exactly two Hands: First Player Hand and Second Player Hand.
HAND provides the notation; the surrounding context determines which Hand is referenced.

Rule Systems define:

which pieces can be placed in reserves,
how pieces enter and leave reserves,
any restrictions on reserve usage.

10. Usage examples

10.1 Movement patterns

* → e4    # Place piece from reserve to Board (Hand → Board)
e4 → *    # Move piece from Board to reserve (Board → Hand)
e2 → e4   # Standard Board-to-Board movement (CELL coordinates)

10.2 Game context examples

Shōgi: Reserve represents captured pieces available for dropping

Reserve Location: *
Board Locations: a1 to i9 (CELL coordinates)

Crazyhouse: Reserve represents captured pieces available for dropping

Reserve Location: *
Board Locations: a1 to h8 (CELL coordinates)

Go: Reserve represents stone supply before placement

Reserve Location: *
Board Locations: Various intersections (CELL coordinates)

11. Examples

See HAND Examples for practical implementation guidance.

12. Reference implementations

The following reference libraries are maintained by Sashité and are intended to be idiomatic, fully tested, and spec-accurate implementations of HAND 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.

Ruby — hand.rb

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