The purpose of this practice guide is not to turn every reader into a format implementer.
It is to make chess representations readable, writable, and distinguishable.
The final test is reconstruction:
Can the reader move reliably between board events and the representations used by chess literature and software?
Reconstruction practice
SAN → move on board
Given:
- a legal position;
- SAN token.
Task:
- identify moving piece;
- resolve disambiguation;
- identify capture;
- destination;
- promotion;
- resulting check/mate;
- update board.
Example:
Nce2.
The position is required to know the exact c-file knight origin square.
Board move → SAN
Given:
- position;
- explicitly selected legal move.
Task:
- find same-type legal ambiguity;
- construct canonical SAN;
- append state suffix.
This tests legality reasoning and notation construction together.
FEN → position
Task:
- decode eight ranks;
- orient board;
- set side to move;
- castling rights;
- ep target;
- counters.
Then answer:
Which state is not visible from placement alone?
Diagram → FEN
Task must supply or state assumptions for:
- side to move;
- castling;
- ep;
- clocks.
A bare diagram is not enough for a fully determined FEN in general.
PGN → game
Task:
- read tags;
- choose initial position;
- replay SAN;
- follow main line;
- inspect RAVs separately;
- preserve result.
Game fragment → PGN/SAN
Given a short legal sequence:
- write SAN;
- add move numbers;
- add termination marker;
- wrap in minimal metadata when requested.
EPD → task
Read:
- four position fields;
bm/am/idoperation.
Explain:
- what the position asks.
SAN ↔ UCI
Given position:
- SAN
Nf3; - identify source g1;
- UCI
g1f3.
Given UCI:
e7e8q;- reconstruct SAN based on position, including capture/check if applicable.
SAN↔UCI conversion is position-dependent because the formats encode different information.
Mixed notation and data exercise set
1. Human vs PGN castling
Which is Appendix-C style?
0-0.
Which is canonical SAN?
O-O.
2. Promotion forms
Human FIDE example:
d8Q.
PGN SAN:
d8=Q.
3. Local piece letters
Explain why a local scoresheet can differ from PGN English SAN.
4. Pawn capture
Decode:
exd5.
5. Complex SAN
Decode:
fxg8=N+.
6. Disambiguation
Two legal knights reach e2:
- choose
Nce2/Nge2.
7. Pinned ambiguity
Pinned knight geometrically reaches target but cannot legally move. Question: Does it force SAN disambiguation? Answer: No.
8. Move-number fragment
Read:
17...Nf6.
9. RAV
Identify which move the variation replaces.
10. NAG
What does $1 encode conceptually?
11. Objective vs subjective
Classify:
+;#;!;±;$2.
12. Scoresheet marker
What can = mean in a FIDE scoresheet context?
- draw offer marker.
13. FEN fields
Name all six in order.
14. FEN starting position
Parse: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
15. FEN ep nuance
After a double push, can the target field exist even if no capture is available under the traditional spec? Answer: Yes.
16. FEN legality
Can syntactically valid FEN describe an illegal chess position? Answer: Yes.
17. PGN STR
List seven tags in order.
18. Result consistency
Find mismatch between tag and movetext termination.
19. Nonstandard start
Which tags?
SetUp "1";FEN "...".
20. PGN import/export
Which is more permissive?
- import.
21. EPD
What distinguishes EPD from FEN?
- four-field core + operations.
22. EPD opcode
Recognize:
bm;am;id.
23. UCI move
Decode:
g1f3.
24. UCI promotion
Decode:
e7e8q.
25. Null move
What is 0000?
- UCI protocol null-move representation, not an ordinary player move.
26. ECO
What does C65 do?
- classifies an opening family/entry; does not explain how to play it.
27. Diagram vs FEN
Which stores castling rights directly?
- FEN.
28. Diagram side to move
Can it always be inferred visually?
- no.
29. Representation choice
Best format for one position?
- FEN.
Best for whole annotated game?
- PGN.
30. Conversion
Given position + SAN, produce UCI; then reverse.
A complete representation workflow
A strong notation workflow is not about memorizing isolated syntax. It is about moving between representations without changing the underlying chess event.
Consider a short sequence played on a board.
You may need to:
- verify each move is legal;
- write each move in SAN;
- place the sequence into numbered movetext;
- wrap it in PGN metadata;
- replay the record to a target move;
- export that position as FEN;
- render a diagram from the FEN;
- convert one candidate move to a UCI coordinate string;
- attach a best-move task in EPD.
Every transformation changes the representation, not the underlying chess position or move.
Diagnose errors by layer
When a conversion fails, first ask which layer is wrong.
Board or legality error
The represented move cannot legally occur.
SAN error
The move is legal, but the SAN token has wrong capture, disambiguation, promotion or check/mate syntax.
FEN error
The position string has bad fields or inconsistent state.
PGN error
Tags, result, variations, comments or movetext structure are malformed or inconsistent.
Protocol/data error
A UCI/EPD token is being interpreted outside the correct position or protocol context.
This prevents one of the most common debugging mistakes: trying to fix a representation string when the actual problem is the chess state it was supposed to describe.
Translation and localization rules for chess data
Localization must preserve the difference between reader-facing language and invariant data tokens.
Translate or adapt:
- explanatory prose;
- headings and captions;
- human-friendly opening names where appropriate;
- examples of local scoresheet piece initials when the guide is explicitly teaching human notation.
Keep invariant inside raw technical examples:
- PGN SAN piece letters
K Q R B N; - PGN tag names in actual PGN data;
- FEN piece letters and state tokens;
- UCI coordinate move strings;
- ECO codes;
- EPD opcodes when demonstrating the actual format.
This rule will matter when the English guides are localized: the explanation should feel native in each language without corrupting portable chess data.
What mastery looks like
You do not need to become a PGN parser author or memorize every EPD opcode.
You should be able to:
- recognize which representation you are looking at;
- explain what information it preserves;
- reconstruct the relevant board state when required;
- choose the right representation for a task;
- spot common syntax/context errors;
- move between SAN, FEN, PGN and UCI when the position context is available.
That is enough notation and data literacy to support deeper tactical, strategic, analytical and software-oriented chess work.
Representation mastery check
You have a strong working foundation when the following skills are functional.
Algebraic/SAN
- read ordinary moves;
- captures;
- check/mate;
- castling;
- promotion;
- en passant;
- results.
Disambiguation
- legal candidates only;
- file;
- rank;
- full origin.
Annotated chess
- fullmove/ply;
- White/Black fragments;
- comments;
- RAV;
- nested RAV;
!/?family;- evaluation symbols;
- NAGs.
Scoresheets
- basic human layout;
- local piece letters;
- draw-offer marker;
- paper/electronic concept;
- transcription to PGN.
FEN
- six fields;
- build/decode;
- castling rights semantics;
- traditional ep target nuance;
- halfmove/fullmove;
- syntax vs legal position.
PGN
- STR;
- supplemental tags;
- movetext;
- comments/RAV/NAG;
- SetUp/FEN;
- import vs export;
- Result consistency.
EPD
- four-field relation to FEN;
- operations;
- purpose.
UCI
- source/destination move string;
- promotion;
- castling;
- null move;
- protocol distinction.
ECO / diagrams
- classification metadata;
- opening name distinction;
- instructional diagram conventions;
- representation selection.
Final checklist
- [ ] I can read and write canonical SAN.
- [ ] I distinguish FIDE human notation from PGN SAN.
- [ ] I can follow annotated variations.
- [ ] I can read a scoresheet.
- [ ] I can parse/build basic FEN.
- [ ] I can read/write a simple PGN.
- [ ] I understand EPD purpose.
- [ ] I recognize UCI coordinate moves.
- [ ] I understand ECO metadata.
- [ ] I know which representation matches which task.
Where to go deeper
Chess legality
Use the dedicated rules guides for complete legal-move, check, castling, en-passant, promotion and draw-state treatment.
Board geometry
Use the board-vision guides for coordinate fluency, rays, attack maps, mobility and visualization.
Tactical interpretation
Move on to tactics once you can record and reconstruct positions accurately.
Opening theory and classification depth
Use opening-specific material for transpositions, repertoires and the practical meaning behind ECO labels.
Engine analysis workflow
Engine scores, depth, principal variations and database workflows require a separate analysis layer.
Tournament scoresheet procedure
Competition rules cover recording obligations, time-pressure exceptions, arbiters and electronic scoresheet procedure.
Variant-specific representation
Chess960 and other variants may extend or reinterpret orthodox representation conventions.
Localization rule for technical chess data
Chess notation creates an important localization constraint: human explanation can change language while portable technical tokens often must not.
May localize
- explanatory prose;
- customary human scoresheet piece letters/examples;
- displayed opening names when appropriate.
Do not translate inside canonical technical strings
- PGN SAN data;
- FEN piece codes;
- UCI move strings;
- ECO codes;
- PGN tag names when showing actual raw PGN.
Translate the explanation, not the invariant data token.
Why this matters for deeper chess study
Once moves and positions are readable outside the board, tactical and strategic ideas can be described precisely and reproduced reliably.
A fork can be shown as:
- diagram;
- FEN;
- SAN sequence;
- annotated PGN fragment.
Notation and data literacy therefore acts as infrastructure for deeper chess study.
Final mental model
Chess information has layers:
BOARD EVENT ↓ SAN / human move record ↓ FEN position snapshot ↓ PGN game record ↓ EPD position task / UCI protocol move / ECO metadata
Not every layer contains the others.
Represent the right chess object with the right format.