EPD Chess Format: Position Tests, Opcodes & Data

Extended Position Description — EPD — is a position-oriented text format related to FEN but designed to attach extensible operations to a position.

It is more specialized than:

• SAN;
• FEN;
• PGN.

For most readers, EPD is reference literacy rather than daily notation.

FEN describes a position state. EPD describes a position core plus optional operations/tasks/metadata.

Relationship to FEN

EPD shares the first four FEN fields:

1. piece placement;
2. active color;
3. castling availability;
4. en-passant target square.

It normally omits FEN's default:

• halfmove clock;
• fullmove number.

Those can be represented through EPD operations if needed.

Why EPD exists

EPD was designed to be expandable.

A position can carry operations such as:

• best move;
• avoid move;
• identifier;
• comment;
• evaluation/test information.

That makes EPD useful for:

• engine test suites;
• tactical/position test collections;
• opening-library preparation;
• research datasets;
• automated position tasks.

Operations and opcodes

An EPD operation contains:

• opcode;
• zero or more operands;
• terminating semicolon ;.

Example conceptual structure:

<four position fields> bm <move>; id "example.001";

Multiple operations can follow one position.

bm

Best move(s) according to the EPD author.

Operands are immediately playable SAN moves.

am

Avoid move(s).

id

Position identifier string.

Other operations

The historical specification defines many more opcodes.

General EPD literacy does not require memorizing the complete opcode catalog.

An opcode says what extra statement is being attached to the position.

Typical test-suite use

A test record can state:

• position;
• side to move;
• expected best move;
• test ID.

Example schematic:

8/8/8/8/8/3k4/8/3K4 w - - bm Kc1; id "demo.001";

This example is schematic. Before final publication every bm move must be verified as legal and genuinely intended by the task.

EPD vs FEN

EPD is not a complete game

Like FEN, EPD does not inherently provide:

• every previous move;
• full event/player metadata;
• a complete variation tree.

PGN remains the main complete-game representation in this domain.

Reading a simple EPD

Use a structure such as:

<placement> <active> <castling> <ep> bm <SAN>; id "name";

Read in order:

1. reconstruct position;
2. identify side;
3. rights/ep;
4. read operation;
5. decode operand under opcode semantics.

Selected opcodes worth recognizing

You do not need the full historical opcode catalog, but a few additional names make real EPD files much easier to read.

• hmvc — halfmove clock, corresponding to the fifth FEN field when that state needs to be preserved.
• fmvn — fullmove number, corresponding to the sixth FEN field.
• c0 through c9 — comment fields.
• pv — a predicted variation, written as a sequence of moves from the represented position.
• ce — a centipawn evaluation supplied by the record.

The important pattern is not the mnemonic itself but the data model: one position can carry several typed statements, each terminated by a semicolon.

For example, a position record could conceptually combine an identifier, a best move and move-counter state without turning into a complete game record.

Advanced opcode caution

Some EPD opcodes encode concepts that overlap later domains:

• centipawn evaluations;
• predicted variations;
• engine analysis counts.

This guide only needs to establish that the format can carry them. Interpreting engine scores, search depth or principal variations is a separate engine-analysis topic.

Anatomy of an EPD record

Think of an EPD line as two layers.

Position core

<piece placement> <side> <castling> <ep>

Operations

opcode operand...;

A record can contain several operations after the position core. The semicolon terminates each operation, so an EPD parser must understand operation boundaries as well as the four position fields.

SAN operands are still position-dependent

Common move-oriented operations such as bm and am use moves interpreted from the represented position. The move operand therefore cannot be understood safely without first reconstructing that position.

This is the same broader principle seen throughout chess data:

a move representation is meaningful only against the correct board state.

EPD as dataset infrastructure

EPD is especially useful when many independent positions need to carry a small amount of structured task data.

Examples include:

• tactical benchmark positions with expected moves;
• regression tests for a chess engine;
• opening or endgame position libraries;
• research datasets where every row is a position rather than a complete game;
• quality-assurance fixtures for move generators and evaluators.

A PGN database can also hold positions indirectly through games, but EPD is often more direct when the position itself is the unit of work.

What EPD does not guarantee

An opcode such as bm means "best move" according to the creator of that EPD record. The format does not prove that the move is objectively best.

Likewise, an evaluation operand is data supplied by the record, not a universal truth certified by EPD.

The format tells you how a statement is attached to a position, not whether the statement is correct.

Frequently asked questions

Is EPD just a shortened FEN?

No. It shares the first four FEN fields, but its defining feature is the extensible sequence of operations attached to the position.

When should I use EPD instead of PGN?

Use EPD when independent positions and attached tasks or test metadata are the main objects. Use PGN when the move sequence and complete game record are central.

Do I need to memorize every EPD opcode?

No. For general literacy, understanding the operation model and recognizing common examples such as bm, am and id is enough. Specialized tooling can implement a broader opcode set as needed.

Key takeaways

EPD:

• shares FEN's first four fields;
• adds semicolon-terminated operations;
• supports position tests and machine workflows;
• is reference-weighted, not a beginner core format.

Important opcodes to recognize conceptually:

• bm best move;
• am avoid move;
• id identifier.

Check your understanding

• [ ] I know what EPD is for.
• [ ] I know its first four fields relate to FEN.
• [ ] I know why halfmove/fullmove are not default fields.
• [ ] I recognize opcode + operands + semicolon.
• [ ] I recognize bm, am, and id conceptually.
• [ ] I can distinguish EPD from FEN and PGN.
• [ ] I know advanced engine interpretation belongs elsewhere.