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 off-board reserve Locations in board games. HAND represents the Hand Location component, enabling uniform representation of reserve areas across diverse game systems regardless of whether those reserves are ever used during play.
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,
- whether Pieces in a reserve may be reused during play.
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 Protocol-level reserve vs. Rule System reuse
At the protocol level, every Capture moves a Piece from a Board Square to a Player’s Hand (*). This is a protocol invariant: all captured Pieces go to the Hand of the capturing Player, regardless of Game context.
Whether those Pieces may subsequently be placed back onto the Board is an entirely separate question, determined by the Rule System — not by the protocol, and not by HAND. A Rule System may:
- allow the Player to drop any Piece from their Hand (Shōgi, Crazyhouse),
- forbid any reuse of Hand Pieces (Western Chess, Xiangqi),
- allow reuse under specific conditions (variant-defined rules).
HAND makes no distinction between these cases. The * notation is valid in all of them.
7.2 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.3 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.4 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 and reuse policies.
- 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,
- whether and under what conditions Pieces in reserves may be reused.
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
The following examples illustrate how HAND applies to different game systems. In all cases, the * notation is identical — only the Rule System’s reuse policy differs.
Shōgi: Captured Pieces go to the capturing Player’s Hand and MAY be dropped back onto the Board on a subsequent Turn.
- Reserve Location:
* - Reuse policy: allowed (Rule System-defined)
Crazyhouse: Captured Pieces go to the capturing Player’s Hand and MAY be dropped back onto the Board on a subsequent Turn.
- Reserve Location:
* - Reuse policy: allowed (Rule System-defined)
Western Chess: Captured Pieces go to the capturing Player’s Hand. The Rule System does not allow reuse — Hand Pieces play no further role in the Game.
- Reserve Location:
* - Reuse policy: not allowed (Rule System-defined)
Xiangqi: Captured Pieces go to the capturing Player’s Hand. The Rule System does not allow reuse — Hand Pieces play no further role in the Game.
- Reserve Location:
* - Reuse policy: not allowed (Rule System-defined)
Go: Stones are placed from the Player’s supply onto the Board. The supply is large enough not to be a practical constraint.
- Reserve Location:
* - Reuse policy: not applicable (stones are not captured and redeployed in standard rules)
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.
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)”.