EPIN Examples

This page provides practical examples for EPIN v1.0.0.

EPIN is a minimal extension of a PIN-shaped token 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 / application conventions).

EPIN in one glance

An EPIN token is:

[ state-modifier ] letter [ terminal-marker ] [ derivation-marker ]

Where:

state-modifier is optional: + (enhanced) or - (diminished)
letter is a single ASCII letter (A–Z / a–z)
terminal-marker is optional: ^
derivation-marker is optional: ' (always last)

Native vs Derived (strictly EPIN-level)

No ' → style-status is Native
With ' → style-status is Derived

That is the only universal meaning EPIN assigns to '.

Basic variants (applies to any letter)

These examples use X/x as a placeholder for “some piece letter” defined by your context.

PIN-shaped base	EPIN variants	Notes
`X`	`X`, `X'`	native / derived style-status
`x`	`x`, `x'`	same, for the other side
`X^`	`X^`, `X^'`	terminal marker can be combined
`+X`	`+X`, `+X'`	enhanced can be combined
`-x`	`-x`, `-x'`	diminished can be combined

Notes:

' always comes after ^ if ^ is present.
What X means is context-defined, just like in PIN.

Worked example A — “Chess-like capture”: keep identity, no style derivation

Some Rule Systems (e.g., western chess) model capture as:

the captured piece is removed from the board,
it does not change side,
and 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.

Example (informative):

Event	EPIN token
white rook exists on board	`R`
rook is captured	(removed from board; optionally recorded as `R` 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, optional derived style-status

Other Rule Systems (e.g., shōgi) model capture as:

the captured piece changes side,
and may re-enter play later (drops).

EPIN can represent a “style-status” decision independently from side changes.

Step 1 — Side swap (core token change)

Because side is encoded by letter case, a side swap is modeled by flipping the case of the piece letter:

Before (first side)	After (second side)
`R`	`r`

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 token	Meaning (context-defined)
keep native	`r`	still native style-status
mark derived	`r'`	derived style-status

Both are valid EPIN.

A common convention in single-style games is to keep tokens native (omit ') because style is implicit in the game being played; but EPIN itself does not require that.

Context conventions: how styles may be resolved (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, for example:

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

Native and derived style-status resolve to the same concrete style.
' is semantically redundant, but still syntactically valid.

Example:

Token	Status	Resolved style (example)
`K`	Native	Shōgi
`K'`	Derived	Shōgi (same)

Convention 2 — Catalog-driven resolution (lookup table)

The context provides a mapping that uses:

the piece letter,
the side,
and the native/derived flag, to select a concrete style label.

Example (purely illustrative):

Token	Status	Resolved style
`P`	Native	Style A
`P'`	Derived	Style B

Convention 3 — Rule-defined transformation pipeline

The context decides that derived pieces follow a different movement tradition (or a transformed ruleset), without necessarily naming a “style”.

Example:

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

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

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
`P`	`p`
`k'`	`K'`

State change

Add/change/remove the + / - prefix:

Before	After	Note
`p`	`+p`	normal → enhanced
`+p'`	`-p'`	enhanced → diminished
`-R`	`R`	diminished → normal

Terminal status change

Add/remove ^:

Before	After
`K`	`K^`
`k^'`	`k'`

Style-status change (native ↔ derived)

Add/remove ':

Before	After	Note
`B`	`B'`	native → derived
`+n'`	`+n`	derived → native

Combined modifier matrix (useful for testing)

All combinations for a piece letter K (placeholder) on both sides:

First side (uppercase)

Token	Side	State	Terminal	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

Second side (lowercase)

Token	Side	State	Terminal	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

Single-style contexts (recommended practice)

In single-style contexts (where the game’s style is implicit), ' is often redundant.

Producers SHOULD omit ' unless the context assigns a specific meaning to “derived”.
Consumers MUST accept both forms.

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

More examples

For additional, game-specific scenarios, see the Rule System documentation or any context-provided catalog that defines:

what piece letters mean,
what “native” and “derived” mean,
and how concrete styles are resolved.