Practical guide
Why Does SGF HA Not Place Handicap Stones? Check HA and AB
HA is handicap metadata, not a stone-placement instruction. To reconstruct a handicap start, read the actual AB setup points in the same node. If the count and points disagree, repair from the original agreement rather than guessing a missing stone.
HA describes the handicap; AB places the stones
HA[2] records a two-stone handicap. It does not add two stones to an SGF board. The Go FF[4] specification says the actual handicap position should be set up with AB in the same node. It also says HA does not imply a particular arrangement.
If a file with HA opens on an empty board, first look for the corresponding AB points. Do not invent two star-point placements from the handicap count. You need the actual board size, coordinates and original agreement or record.
This guide compares three complete original files. They are small diagnostic examples, not records of played games, screenshots from a tested viewer or a complete validation tool for every SGF. For general properties and tree reading, use the SGF introduction.
Example 1: HA-only metadata leaves the root board empty
(;FF[4]GM[1]SZ[19]HA[2])The file declares Go, FF[4], a 19×19 board and a two-stone handicap. It contains no setup or move properties. Its root therefore supplies no Black or White stone placements: all 361 intersections remain empty in the reconstruction shown here.
The problem is missing intended setup information. It is not evidence that White removed the stones, or that the viewer should guess their locations. Also, do not confuse an incomplete intended handicap record with a claim that every such file is syntactically unreadable.
Download the original HA-only example. It is intentionally incomplete as a record of a two-stone starting arrangement.
Example 2: AB supplies the complete two-stone arrangement
(;FF[4]GM[1]SZ[19]HA[2]AB[dp][pd];W[dd])AB[dp][pd] adds Black setup stones at two actual points. SGF columns and rows both start at the upper left; the first letter is the column and the second the row from the top. On a 19×19 board, d is position 4 and p is position 16.
| Property | Column / top row | Human coordinate |
|---|---|---|
| AB[dp] | 4 / 16 | Black D4 |
| AB[pd] | 16 / 4 | Black Q16 |
| W[dd] | 4 / 4 | White D16 |
The human diagram uses A–H then J–T, omitting I, with rank 1 at the bottom. The same p that means the sixteenth SGF column maps to human file Q under that declared key. Do not carry the 9×9 A–I key into this 19×19 translation.
The first explicit ordinary move is W[dd]. It adds White D16 after setup; it does not place another Black handicap stone. No capture occurs in that displayed move. The resulting complete board is Black D4 and Q16, White D16, with every other point empty.
Download the complete setup-and-one-move example. The file deliberately omits komi and a result; neither may be inferred from these stones.
Example 3: HA and the supplied AB count disagree
(;FF[4]GM[1]SZ[19]HA[3]AB[dp][pd])HA declares three handicap stones, but AB supplies only two distinct setup points. The reconstructed root still has Black D4 and Q16. There is no third placement encoded by HA.
Keep both facts in the diagnosis: “declared handicap 3; supplied Black setup 2.” Find the actual agreement or source position before repair. You cannot know whether HA should be changed to 2 or whether one AB point was omitted merely from this fragment. Do not fill in a convenient centre stone.
Download the mismatch example. Its purpose is to expose conflicting information, not recommend an arrangement.
Repair a record from evidence in five steps
- Save the original file. Keep the source and make an edited copy so that a repair remains distinguishable from original metadata.
- Read SZ and the coordinate system. Check each supplied setup point against the actual dimensions, rather than a familiar printed letter key.
- Reconstruct AB and any other setup explicitly. Count distinct points; identify White setup or later setup changes if present. This article’s examples use root AB only.
- Compare HA with the intended agreement. A count conflict needs the actual record or players’ setup; HA alone supplies no location.
- Check the first ordinary move and playing settings. The BGA two-stone procedure has White next. For a real file, retain the adopted rules, komi and relevant history; do not certify all later moves from the root picture.
| Check | Question | Not established |
|---|---|---|
| File structure | Which properties and nodes are supplied? | A true game history or all legal moves |
| Root reconstruction | Which stones appear before ordinary play? | An intended missing handicap point |
| Playing agreement | Which turn, rules and komi apply? | A universal server default or best opening |
If a real SGF uses additional setup nodes or variations, read them in their own tree context. AB is a setup operation, not a normal move that alternates with White and makes ordinary captures. The examples here do not implement a general parser or claim a viewer round trip was tested.
Use the correct next reference
Use the handicap setup and first-turn checklist to arrange an actual game. Use the general SGF guide for AB, AW, AE, comments and move trees.
If a partial coordinate record lacks the starting stones, use the complete-position record note. A precise missing-information question is a better repair outcome than a guessed starting board.
Sources and further reading
- Go SGF FF[4]: HA, coordinates and move propertiesFull current Go-specific specification read 5 November 2026. HA defines the count but adds no stones or placement convention; AB supplies the actual setup. This reference also states top-origin SGF coordinates and compatibility pass values.
- SGF FF[4] properties: AB and ordinary move propertiesRelevant complete setup and move sections read from the retained full 2 November 2026 source snapshot; the page displays 25 June 2006. Current 5 November retries failed. AB adds setup stones without prisoners or ordinary captures; B and W are move properties.
- British Go Association: handicap systemThe introduction’s multi-stone procedure places Black setup stones before White’s next turn. Diagram 15 two-stone arrangement was visually read for P0; the labelled example here is original, not the source image.