The PHH format is a derivative of the Tom's Obvious, Minimal Language (TOML) format. This design allows PHH files to take advantage of TOML format's type system and be human-readable and writable while maintaining easy parsability by software systems. This differs from historical game file formats like PGN or SGF which use in-house formatting.
The PHH format puts restrictions on the naming and types of the key/values, with which the poker games are described. These definitions, named "fields", fall under two classifications. The first involves state construction and progression and must be specified. The second describes various miscellaneous information about the game and may be omitted by the annotator. The full fields are described below.
Field | Name | TOML Native Type | Required |
---|---|---|---|
Variant code | variant |
String | yes |
Antes | antes |
Array of integers or floats | yes |
Blinds/Straddles | blinds_or_straddles |
Array of integers or floats | yes |
Bring-in | bring_in |
Integer or float | yes |
Small bet | small_bet |
Integer or float | yes |
Big bet | big_bet |
Integer or float | yes |
Min bet | min_bet |
Integer or float | yes |
Starting stacks | starting_stacks |
Array of integers, floats, or null | yes |
Actions | actions |
Array of strings | yes |
Annotator full name or mononym | author |
String | no |
Event name | event |
String | no |
Event or organizer URL | url |
String | no |
Venue | venue |
String | no |
Venue street-level address | address |
String | no |
Venue city | city |
String | no |
Venue region, state, or province | region |
String | no |
Venue postal code | postal_code |
String | no |
Venue country | country |
String | no |
Timestamp at the start of the hand | time |
Local time | no |
IANA time zone | time_zone |
String | no |
Time zone abbreviation | time_zone_abbreviation |
String | no |
Event day | day |
Integer | no |
Event month | month |
Integer | no |
Event year | year |
Integer | no |
Hand name or number | hand |
String or integer | no |
Tournament level | level |
Integer | no |
Players' seat numbers | seats |
Array of integers | no |
The number of seats | seat_count |
Integer | no |
Table name or number | table |
String or integer | no |
Player full names or mononyms | players |
Array of strings | no |
Final stacks | finishing_stacks |
Array of integers or floats | no |
Winnings | winnings |
Array of integers or floats | no |
ISO 4127 currency | currency |
String | no |
Currency symbol | currency_symbol |
String | no |
Ante uniformity | ante_trimming_status |
Boolean | no |
Allocated time per action | time_limit |
Integer or float | no |
Time banks at the beginning of the hand | time_banks |
Array of integers or floats | no |
An ideal representation of poker hands should not only be concise but also easily readable and writable by human readers. It should also support only describing the bare minimum information necessary to comprehensively describe a hand while facilitating options to give rich details for various use cases beyond simple action tracking. For convenience in parser implementations, the formatting must also be simply structured in a consistent manner. In addition, the format must be powerful enough to describe a wide variety of poker games played in formal settings. Such selections should cover games played in reputable poker tournaments around the world while the inclusion of various eccentric or esoteric variants is not as necessary.
In the implementation of the PHH parser, the program should report an error when any violation of the specification is encountered. The parser may stop parsing the file, ignore the problematic field or action, or proceed as normal.
The fields that have a value of type array where each element corresponds to a particular player must have their elements ordered identically to the ordering of the players and have lengths equal to the number of players. The ordering of the players is table agnostic, that is, it is purely based on position.
The first player in the PHH format is typically the very first person being dealt the hole card by the dealer while the last player in the PHH format is typically the person being dealt the last hole card. This is assuming a proper dealing order is followed. In general, the ordering of the players must represent a clockwise order.
In typical button games such as no-limit Texas hold 'em or pot-limit Omaha hold 'em, the first player must be in the small blind while the last player must be in position (i.e. has the button). In non-button games like stud, there is no strict notion of position. In such games, the first player should be the one in the dealer's immediate left while the last player should be in the dealer's immediate right.
As poker is a game with a diverse set of rules that often differ based on regions or events, it is impossible to point to anything as an authoritative documentation of poker rules that must be followed both by the annotator and the parser. The parser implementation should be designed to handle actions that may be potential transgressions in certain poker rule sets, either silently or with a warning.
While annotating the fields, especially the "actions" field, the author should follow the specific set of rules followed by the game being annotated. Where applicable or possible, the author is encouraged to conform to the latest WSOP Live Action and Tournament Rules of which the most recently released versions as of the writing of this page are for the 2023 WSOP. If there is any contradiction between the two documents, the tournament rules take precedence, as they impose stricter guidelines on poker playing. When there is an ambiguity in both documents, it is to be considered as an undefined behavior. In such a case, the annotator should adhere to a historically informed custom of poker playing.