.mtgr

Appearance

0028: Archetypes ​

Status: Accepted. Item 5's rationale corrected by decision 0032.

Context ​

Most of what players and tools want from a pile of game records is grouped by matchup: how does my deck do against this other deck, which matchups are being played, how did game 1 go compared with the sideboarded games. The key to all of that is the archetype each player is piloting, for example "Izzet Murktide" or "Boros Energy".

Nothing in the format names it. The deck block (spec section 10.5) can carry a name, but that is the perspective player's own label for their list (on MTGO, whatever they called the deck file, such as "Test Deck"), not a classification. The opponent has no deck block at all, because their decklist is hidden (decision 0001), yet the opponent's archetype is the more important of the two for matchup records.

Decision ​

  1. Two optional tags, Player1Archetype and Player2Archetype, give the archetype of each player's deck. They follow PGN's pattern for per-player tags, which pairs a side with a property (WhiteTitle and BlackTitle, PGN section 9.1.1), using the Player1 and Player2 naming from decision 0012.
  2. The value is the archetype's name as it is commonly used in the format, for example "Izzet Murktide". There is no registry of archetype names. This follows PGN's Opening tag (PGN section 9.3.1), which holds "the traditional opening name" as a plain string.
  3. An archetype is a classification, not game data. Nothing in the body depends on it, and a reader MUST NOT derive game state from it. Like PGN's Opening and ECO tags, it can be set by the writer, by the player, or later by another tool (a classifier, an annotator, a tournament's published decklists) without touching the record of the game.
  4. When no classification is known, the tag is omitted, like every optional tag (spec section 4.3). It is never filled with a placeholder such as "?" or "Unknown".
  5. The archetype SHOULD be the same in every game of a match. This is a classification convention: sideboarding changes a deck without making it a different archetype. In Limited a player may rebuild their deck between games, and a tool may then classify each game separately. If a classification is revised (for example, because game 2 revealed more of the opponent's cards), it is revised in every game of the match.

Rules basis ​

Checked against the Comprehensive Rules effective 2026-09-25.

No rule defines archetypes; they are a community classification of decks, so the tags are a format choice. Two rules bear on item 5, which is a convention rather than a consequence of them:

  • 100.4: "Each player may also have a sideboard, which is a group of additional cards the player may use to modify their deck between games of a match." In constructed play, sideboarding adjusts a deck rather than replacing it.
  • 100.4b: "In limited play involving individual players, all cards in a player's card pool not included in their deck are in that player's sideboard." In Limited the whole deck can change between games, so the convention is a SHOULD, not a MUST.

Alternatives rejected ​

  • An archetype field on the deck line. Rejected: the deck block exists only for the perspective player, and the opponent's archetype matters most. Tags are also where PGN puts information about the players, and a tool grouping games by matchup can read the tags without parsing the body.
  • Using the deck name as the archetype. Rejected: it is the player's private label for their list, often meaningless to anyone else ("Test Deck", "v3 final").
  • A fixed list of archetype names. Rejected: archetypes are named by the community, the names differ between sites, and the list changes with every set. A registry in this repository would always be out of date.
  • Recording who classified the deck, or a confidence. Rejected for now: no concrete case needs it yet. Tools that do can use an extension tag (spec section 13).
  • A single archetype tag for the opponent only. Rejected: a record is written from one seat, but every game is played by two players, and readers grouping by matchup need both sides. The tags are symmetric, like PGN's.

Consequences ​

  • The spec lists Player1Archetype and Player2Archetype among the optional core tags (section 4.3).
  • Examples show both tags, including an opponent's archetype classified from the cards they revealed.
  • Readers can group games by matchup from the tags alone.