EPIN Examples

This page provides practical examples for EPIN v1.0.0.

EPIN is a minimal extension of PIN that adds a single optional trailing marker:

the derivation marker: '

EPIN does not encode a concrete Piece Style. Instead, it flags whether a Piece is considered Native or Derived with respect to Style, and leaves all interpretation and Style resolution to the surrounding context (Game, Rule System, or application conventions).

When to use EPIN vs QPI

Both EPIN and QPI can represent Native/Derived Style status, but they serve different purposes:

Aspect	EPIN	QPI
Style encoding	None (context-defined)	Explicit (via SIN)
Native/Derived	Explicit flag (`'`)	Computed from `sin.side == pin.side`
Use case	Single-Style contexts, implicit Style	Cross-Style contexts, explicit Style
Token size	Compact	Slightly larger (SIN + `:` + PIN)

Use EPIN when:

The Style is implicit (all Pieces share the same Style)
You want minimal token size
Style resolution is handled externally

Use QPI when:

Multiple Styles coexist in the same Match
You need explicit Style identification
You want deterministic Native/Derived from the token alone

EPIN structure

An EPIN token is:

<pin> [ derivation-marker ]

Where:

<pin> is a valid PIN token
derivation-marker is optional: ' (always last)

The PIN component encodes:

Attribute	Encoding
Piece Name	Letter identity (case-insensitive)
Piece Side	Letter case (uppercase = `first`, lowercase = `second`)
Piece State	Prefix (`+` enhanced, `-` diminished, absent = normal)
Terminal Status	Suffix `^` (present = terminal, absent = non-terminal)

Native vs Derived

No ' → Style status is Native
With ' → Style status is Derived

That is the only universal meaning EPIN assigns to '. What “Native” and “Derived” mean is entirely context-defined.

Component extraction and transformation

Accessors

Accessor	Description
`pin`	The underlying PIN token
`native?`	Boolean: true if derivation marker is absent
`derived?`	Boolean: true if derivation marker is present

Transformation methods

Method	Description
`native`	Returns a copy with Native Style status (derivation marker removed)
`derive`	Returns a copy with Derived Style status (derivation marker added)

These methods are idempotent:

Before	Method	After
`R`	`native`	`R`
`R`	`derive`	`R'`
`R'`	`native`	`R`
`R'`	`derive`	`R'`

Basic variants

These examples use X/x as a placeholder for any Piece letter defined by your context.

PIN base	EPIN variants	Notes
`X`	`X`, `X'`	Native / Derived Style status
`x`	`x`, `x'`	Same, for Side `second`
`X^`	`X^`, `X^'`	Terminal marker can be combined
`+X`	`+X`, `+X'`	Enhanced State can be combined
`-x`	`-x`, `-x'`	Diminished State can be combined

Note: The derivation marker ' always comes after ^ if ^ is present.

Worked example A — Chess-like Capture (identity-preserving)

Some Rule Systems (e.g., Western Chess) model Capture as:

The captured Piece is removed from the Board
It does not change Side
It does not re-enter play

In such a model, a captured Piece typically remains Native (no ') because it is still “that Piece” in the historical record.

Event	EPIN token	Notes
White Rook exists on Board	`R`	Native, Side `first`
Rook is captured	`R`	Removed from Board; optionally recorded in captured list

Here, the derivation marker is not needed. Capture is represented by where the Piece is stored (on-Board vs off-Board), not by changing its EPIN token.

Worked example B — Shōgi-like Capture (Side swap)

Other Rule Systems (e.g., Shōgi) model Capture as:

The captured Piece changes Side
It may re-enter play later (Drop)

Step 1 — Side swap

Because Side is encoded by letter case, a Side swap is modeled by flipping the case of the Piece letter:

Before (Sente)	After (Gote)	Method
`R`	`r`	Flip case

Step 2 — Decide Style status (context-defined)

Your context may choose to keep the Piece Native after Capture, or mark it Derived:

Modeling choice	After Capture	Method
Keep Native	`r`	—
Mark Derived	`r'`	`derive`

Both are valid EPIN.

A common convention in single-Style Games is to keep tokens Native (omit ') because Style is implicit; but EPIN itself does not require that.

Step 3 — Drop

When the Piece is dropped back onto the Board, it retains whatever Style status your Rule System assigns:

Captured token	Dropped token	Notes
`r`	`r`	Native throughout
`r'`	`r'`	Derived throughout
`r'`	`r`	Derived → Native on Drop (if Rule System specifies)

Step 4 — Promotion

Promotion is encoded with the State modifier:

Event	Before	After	Method
Promote	`r`	`+r`	Add `+` prefix
Demote (on Capture)	`+r`	`r`	Remove `+` prefix

Context conventions for Style resolution (informative)

EPIN does not define how to turn “Native/Derived Style status” into a concrete Piece Style.

A context MAY resolve Style in many ways:

Convention 1 — Single-Style context (one implicit Style)

Both Native and Derived resolve to the same concrete Style
' may be semantically redundant, but remains syntactically valid

Example (Shōgi context):

Token	Status	Resolved Style
`K^`	Native	Shōgi
`K^'`	Derived	Shōgi (same)

Convention 2 — Catalog-driven resolution (lookup table)

The context provides a mapping using:

The Piece letter
The Side
The Native/Derived flag

to select a concrete Style label.

Example (illustrative):

Token	Status	Resolved Style
`P`	Native	Chess
`P'`	Derived	Makruk

Convention 3 — Rule-defined transformation

The context decides that Derived Pieces follow different movement rules, without necessarily naming a “Style”:

Native: “moves like base Piece”
Derived: “moves like base Piece under transformed movement rules”

EPIN supports all of these by carrying only the status flag.

Mutation recipes

These show the minimal textual updates for common changes. They are format-level recipes; why the change happens is Rule System-defined.

Side change

Flip the case of the letter:

Before	After	Change
`P`	`p`	Side: `first` → `second`
`k'`	`K'`	Side: `second` → `first`

State change

Add, change, or remove the + / - prefix:

Before	After	Change
`p`	`+p`	State: normal → enhanced
`+p'`	`-p'`	State: enhanced → diminished
`-R`	`R`	State: diminished → normal

Terminal Status change

Add or remove ^:

Before	After	Change
`K`	`K^`	Becomes Terminal Piece
`k^'`	`k'`	Terminal Status removed

Style status change (Native ↔ Derived)

Add or remove ':

Before	After	Method
`B`	`B'`	`derive`
`+n'`	`+n`	`native`

Combined modifier matrix (useful for testing)

All combinations for a Piece letter K (placeholder) on both Sides:

Side `first` (uppercase)

Token	Side	State	Terminal	Style status
`K`	first	normal	no	Native
`K'`	first	normal	no	Derived
`K^`	first	normal	yes	Native
`K^'`	first	normal	yes	Derived
`+K`	first	enhanced	no	Native
`+K'`	first	enhanced	no	Derived
`-K`	first	diminished	no	Native
`-K^'`	first	diminished	yes	Derived

Side `second` (lowercase)

Token	Side	State	Terminal	Style status
`k`	second	normal	no	Native
`k'`	second	normal	no	Derived
`k^`	second	normal	yes	Native
`k^'`	second	normal	yes	Derived
`+k`	second	enhanced	no	Native
`+k'`	second	enhanced	no	Derived
`-k`	second	diminished	no	Native
`-k^'`	second	diminished	yes	Derived

Mutation sequences (informative)

A token can go through multiple updates. The events below are examples of what a Rule System might do.

Example: Shōgi-like Rook lifecycle

Step	EPIN	Event
1	`R`	Initial Position (Sente Rook)
2	`r`	Captured by Gote (Side swap)
3	`+r`	Promoted (State becomes enhanced)
4	`R`	Captured back by Sente (Side swap + demotion)
5	`R`	Dropped onto Board

Example: With Derived marking

Step	EPIN	Event
1	`R`	Initial Position (Native)
2	`r'`	Captured by Gote (Side swap + mark Derived)
3	`+r'`	Promoted (State becomes enhanced)
4	`R`	Captured back (Side swap + revert to Native + demotion)

Example: Terminal Piece lifecycle

Step	EPIN	Event
1	`K`	Standard King
2	`K^`	Designated as Terminal Piece
3	`k^`	Moved to Side `second` (if Rule System allows)
4	`k`	Terminal Status removed

Single-Style contexts (recommended practice)

In single-Style contexts (where the Game’s Style is implicit), the derivation marker ' is often redundant.

Producers SHOULD omit ' unless the context assigns a specific meaning to “Derived”.

Consumers MUST accept both forms (X and X').

If a context chooses a canonical form, it SHOULD do so explicitly as a separate step (e.g., normalize X' → X when Derived is meaningless in that context).

Single-Style catalogs (informative)

These tables illustrate common mappings for well-known Games. They are examples, not requirements.

Western Chess

EPIN	Piece	Notes
`K^` / `k^`	King	Terminal Piece
`Q` / `q`	Queen
`R` / `r`	Rook
`B` / `b`	Bishop
`N` / `n`	Knight
`P` / `p`	Pawn

Japanese Shōgi

EPIN	Piece	Notes
`K^` / `k^`	King	Terminal Piece
`K^'` / `k^'`	Jeweled King	Terminal Piece
`R` / `r`	Rook
`+R` / `+r`	Promoted Rook	Enhanced (Dragon)
`B` / `b`	Bishop
`+B` / `+b`	Promoted Bishop	Enhanced (Horse)
`G` / `g`	Gold
`S` / `s`	Silver
`+S` / `+s`	Promoted Silver	Enhanced
`N` / `n`	Knight
`+N` / `+n`	Promoted Knight	Enhanced
`L` / `l`	Lance
`+L` / `+l`	Promoted Lance	Enhanced
`P` / `p`	Pawn
`+P` / `+p`	Promoted Pawn	Enhanced (Tokin)

Thai Makruk

EPIN	Piece	Thai name	Notes
`K^` / `k^`	King	Khun	Terminal Piece
`Q` / `q`	Queen	Met	Moves one square diagonally
`R` / `r`	Rook	Rua
`B` / `b`	Bishop	Khon	Moves like Silver in Shōgi
`N` / `n`	Knight	Ma
`P` / `p`	Pawn	Bia	Promotes to Met on 6th rank