TLDR
To archive MTG proxy deck files properly, save a dated project folder containing three separate lists: the untouched source export, the cleaned print list, and the final approved configuration. Add exact set and collector identifiers, custom art and back files, token counts, double-faced card pairings, production choices, preview records, and a revision log. A decklist records what the deck plays; a project archive records what the physical deck should look like.
The goal is not merely to remember that the deck contained Lightning Bolt. The goal is to identify which Lightning Bolt, with which art, treatment, language, back, quantity, and exception notes. Build the archive so another person could recreate the approved project without relying on your memory or an old shopping cart.
Why a decklist is not enough for a proxy reorder
A normal decklist is a gameplay document. It usually records card names and quantities, sometimes divided into commander, main deck, sideboard, companion, or maybeboard sections. That is enough to rebuild the deck mechanically, but it may not reproduce the physical project.
Names alone do not preserve selected printings, collector numbers, frame treatments, languages, custom images, card backs, finish choices, tokens, helper cards, or manually paired faces. Even a platform link can change as the deck is edited. A saved ordering page may also disappear, expire, or omit decisions made during proofing.
Treat the archive as the approved manufacturing record for your deck. Existing Print MTG Cards workflow guidance similarly recommends retaining a cleaned list, section totals, version identifiers, appearance rules, exception notes, dated approval, and revision history rather than overwriting old configurations. The same discipline is useful whether you are preserving one Commander deck, a competitive testing gauntlet, or a Cube update.
The eight-part checklist to archive MTG proxy deck files
- Deck identity: Record the project name, format, owner or group, revision number, approval date, and intended use. Use a stable name such as cedh-blue-farm rather than final-deck-new.
- Untouched source export: Save the original text, CSV, or other export exactly as received. Also record its platform, export date, and source URL when applicable.
- Cleaned print list: Preserve the normalized list actually used for the batch, including quantities and clear sections for the main deck, commander, sideboard, companion, tokens, and extras.
- Exact version map: Record the set code and collector number for every version-sensitive card. Add treatment, language, or art notes when those identifiers do not tell the whole story.
- Custom-file record: Save every approved custom face and back as a separate file. Keep the final submitted file rather than only an editable source or a screenshot.
- Physical-production notes: Record the selected size, stock or material option, finish, back configuration, and any other relevant production choice using the exact wording shown when the project was approved. Recheck availability before a reorder because commercial options can change.
- Token and accessory manifest: List tokens, emblems, helper cards, reminders, copy tokens, and optional swaps separately from the playable deck.
- Approval and revision log: Save the approved preview or equivalent record when available, note who approved it, and document every later addition, removal, or version change. Preserve previous revisions instead of replacing them.
Do not assume an ordering tool will retain a cart, uploads, selected versions, or production settings indefinitely. If you rebuild the project through a decklist-based MTG printing workflow, compare the new configuration against your local archive before approval. PrintMTG states that its workflow can import lists from Moxfield, Archidekt, MTG Arena, and plain text, and allows versions to be changed after import; that flexibility makes your own approved version map especially important.
Keep three lists, not one
1. The source list
This is the unchanged export from Moxfield, Archidekt, ManaBox, Arena, or another source. Never silently clean this file. Its purpose is to show what entered the workflow, including odd punctuation, duplicate sections, unresolved aliases, and cards you later excluded.
2. The current-batch print list
This is the operational list for one batch. It reflects deliberate choices such as excluding basic lands, adding two replacement copies, printing only a ten-card upgrade package, or separating a sideboard. Put the expected count for every section at the bottom so omissions are visible.
3. The approved configuration record
This is the authoritative physical specification. It combines the final quantities with version IDs, fronts and backs, custom-file names, tokens, production notes, and approval date. For repeatable testing projects, the same distinction is useful in a competitive deck and gauntlet workflow.
When the three lists disagree, do not resolve the difference from memory. Read the revision log. It should explain, for example, that two sideboard cards were removed from the print batch, three tokens were added, and the default basic lands were replaced with a specific treatment.
Record each selected version so another person can follow it
Use one row per distinct physical version. If a deck needs three copies of a card but one uses different art, create two rows. Set codes and collector numbers are more dependable than descriptions such as “the dark one” or “the old-border art.”
| Qty | Card or component | Set | Collector no. | Treatment or language | Back or paired face | Exception notes |
|---|---|---|---|---|---|---|
| 1 | Card name | ABC | 123 | Standard frame; English | Default project back | Approved preview page 2 |
| 2 | Card name | DEF | 045 | Borderless; English | Default project back | Keep both copies identical |
| 1 | MDFC front name | GHI | 210 | Standard frame; English | MDFC back name | Front and back must remain paired |
| 3 | Custom token | Custom | T-01 | File: token-goblin-v2.png | File: token-back-v1.png | Use approved v2 face only |
Keep file names stable and descriptive. A useful custom-file name includes the component, version, and side, such as commander-face-v3.png or dungeon-token-back-v1.png. Avoid names such as final2-really-final.png. If you retain editable source files, store them in a working-files folder and keep the approved production file in a separate approved-files folder.
Archive tokens, sideboards, and special cards separately
Tokens are easy to lose because they may not appear in the main deck count. PrintMTG says tokens and sideboards can be included in its decklist workflow, but your archive should still give them independent sections and totals. For projects with many game aids, keep a dedicated manifest and apply the same readability checks covered in the MTG token printing guide.
- Tokens and emblems: Record name, quantity, relevant characteristics, selected image, and back.
- Sideboards and companions: Keep them in labeled sections rather than appending them to the main-deck total.
- Optional swaps: Mark these as optional modules so they are not mistaken for missing main-deck cards.
- DFCs and MDFCs: Record the front and back together in one manifest row, then verify both files or selected faces.
- Transform and meld cards: Document every required face and pairing. For meld components, note the relationship between the individual cards and combined result.
- Helper cards and reminders: List them as non-deck extras with their own quantities.
- Cube modules: Maintain a master manifest plus a smaller delta list for each update. Archive the pre-update and post-update revisions.
If the project follows a strict visual standard, write that rule down before listing exceptions. For example: “Use one specific era or frame unless the version map says otherwise.” The archived Old School test-deck workflow demonstrates why appearance rules and version identifiers belong in the approved record, not only in someone’s memory.
Name revisions without overwriting history
Use a sortable revision format such as project-name_r03_2026-04-18. The revision number tells you the sequence; the ISO-style date sorts cleanly. Increment the revision whenever gameplay contents, selected versions, custom files, backs, or physical options change.
A practical folder can contain these top-level directories:
- 00-project-readme: identity, intended use, owner, approval status, and archive instructions
- 01-source-list: untouched exports and source URLs
- 02-print-list: cleaned lists and section totals for each batch
- 03-version-map: spreadsheet or CSV containing exact printing selections
- 04-approved-files: final custom faces, backs, tokens, and helper cards
- 05-working-files: editable art or layout sources, if retained
- 06-proof-and-approval: dated previews, screenshots, PDFs, and approval notes
- 07-production-notes: recorded options and batch-specific instructions
- 08-revision-log: dated changes and links to superseded revisions
Keep the delta log short but exact. “Updated deck” is not useful. “Removed Card A; added Card B; changed Card C from set ABC #12 to set XYZ #88; replaced goblin-token-v1 with v2” can be audited months later.
Replacement-batch preflight checklist
A replacement order should begin from the archived approved revision, not from the deck’s current online list. Before importing or submitting anything, verify the following:
- Confirm the exact project name, revision number, and approval date.
- Compare main-deck, commander, sideboard, token, and extra counts independently.
- Check every version-sensitive card against its set code and collector number.
- Open custom files and verify that their contents match their file names.
- Confirm the intended back for normal cards, custom components, and double-faced cards.
- Audit every DFC, MDFC, transform, and meld pairing front to back.
- Identify whether this is an exact replacement, a partial reorder, or a revised batch.
- Recheck current production choices instead of assuming an older material or finish remains available.
- Save the newly approved configuration as another dated revision, even when no intentional change was made.
For a single damaged or missing card, record the replacement as a child batch of the original revision. That preserves the relationship between the replacement and the deck it must match. For a Cube or group order, also record which owner, module, or storage section receives each replacement.
Sanctioned-event note
Archive records do not change where player-created proxies may be used. The Magic Tournament Rules edition dated February 27, 2026 states that sanctioned events require genuine, publicly released Magic cards, apart from limited circumstances in which a judge may issue a proxy. The rules separately allow clear representations for tokens and similar game aids. Check the current official Magic Tournament Rules before an event because tournament policy can change.
Frequently asked questions
Is a decklist enough to reproduce the same proxy cards?
Usually not. A decklist may preserve names and quantities but omit exact printings, art treatments, languages, backs, tokens, custom files, and physical-production choices. Keep a separate approved configuration record.
How should I save custom art and card-back files?
Keep the exact approved production files in a read-only or clearly labeled folder. Use descriptive versioned names, retain editable sources separately, and record which face uses which back. Also retain any permissions or provenance records relevant to files you supplied.
What should I record for a Cube update?
Preserve the full master manifest, then create a dated delta listing additions, removals, replacements, and version changes. Record the Cube section or module for each changed card and save the completed post-update manifest as a new revision.
Should I keep old revisions after a reorder?
Yes. An old revision can explain why an existing card looks different, identify the correct match for a replacement, or let you restore a previous deck configuration. Mark superseded revisions clearly, but do not overwrite them.
Archive the approved physical project, not just the idea
A reliable archive answers four questions without guesswork: what was printed, which versions and files were approved, how every special component was paired, and what changed afterward. Create the folder before the project leaves your working computer, then complete the approval record as soon as the final configuration is settled.
Your final preflight is simple: open the approved revision, reconcile every section total, inspect the version-sensitive rows, verify custom fronts and backs, and confirm the production notes still describe available choices. If another player could rebuild the same project from that folder alone, the archive is ready.