TLDR
Give every physical cube slot a permanent slot ID. In a master manifest, record the card’s rules identity, exact printing, artwork or treatment, language, approved production file, revision, and quantity. Never use the card name as the only identifier. Before printing, audit the batch three ways: by card name, by set and collector number, and by slot ID or filename. That combination catches most wrong-version, missing-file, and accidental-duplicate errors.
The practical goal of cube proxy file organization reprints is not merely to keep a folder tidy. It is to ensure that the exact version you selected becomes the physical card you draft. A list containing “Counterspell” may identify the game piece to a human, but it does not identify the artwork, frame, language, treatment, revision, or front and back files that should enter a print batch.
Treat the project as physical-asset version control. The cube slot, underlying card, selected printing, and final print file are related, but they are not interchangeable. Once those identities are separated, replacing one image or changing one frame no longer risks silently changing quantities elsewhere in the cube.
Separate the four identities behind every cube card
A reliable system tracks four layers. Each layer answers a different question, and skipping one creates a specific kind of mistake.
- Cube slot identity: Where does this physical card belong in your cube? A stable value such as U-042 or ARTIFACT-018 remains unchanged even if you replace the card later.
- Game-card identity: Which underlying rules object is this? This distinguishes the card itself from its many published versions.
- Printing identity: Which set, collector number, language, artwork, frame, and treatment did you choose? This is the version the player should recognize in the sleeve.
- Production-asset identity: Which exported front, back, and revision are approved for manufacturing? This is the actual file package, not merely a database entry or preview image.
The Scryfall card-field definitions illustrate why these layers matter. Its data model separates an Oracle-level identity from a printing-specific identity and includes fields for set, collector number, language, frame, frame effects, border color, reprint status, and illustration identity. That metadata supports distinguishing the underlying card from a particular visual printing.
You do not need every available database field. You do need enough information to reconstruct your decision without relying on memory. “Use the old-border one” may feel clear today, but it becomes ambiguous as soon as you compare two old-border treatments or return to the project six months later.
Build one master manifest before collecting images
A spreadsheet or small database should be the source of truth. Folders are useful for storage, but they cannot reliably explain intent. A manifest can tell you that two copies are deliberate, one file is obsolete, and another still needs approval.
| Field | Purpose | Example |
|---|---|---|
| cube_slot_id | Permanent identity for the physical cube position | U-042 |
| copy_no | Distinguishes intentional copies of the same card | 02 |
| card_name | Human-readable sorting and review | Counterspell |
| oracle_id | Tracks the underlying rules-card identity | Stored database ID |
| printing_id | Identifies the selected published printing | Stored database ID |
| set_code | Provides a quick printing reference | SET |
| collector_number | Distinguishes the printing within its set | 123a |
| language | Prevents unintended language substitutions | en |
| art_or_illustration | Records the selected art | Illustration ID or short note |
| frame_or_treatment | Records the visual treatment | Retro frame |
| front_file | Points to the approved front asset | Approved filename |
| back_file | Points to a back asset when required | Approved filename or blank |
| quantity | Controls the exported physical count | 1 |
| status | Separates drafts from printable assets | Approved |
| revision | Identifies the current production revision | 03 |
| last_checked | Records when the row was verified | Date |
Store collector numbers as text, not numbers. Collector-number fields can contain non-numeric characters, so a spreadsheet that forces them into numeric formatting can alter meaningful values. Also preserve leading zeroes in slot and copy identifiers by treating those columns as text.
If you already use a deck manifest, the same principles apply. The workflow in organizing a complete Commander print file is a useful companion, but a cube adds more pressure around art curation, intentional repetition, and long-term replacement files.
Use filenames for sorting, not for storing everything
The manifest carries detailed metadata. The filename should carry only enough information to sort, identify, and verify the exported asset without opening it.
A practical pattern is: [slot]-[copy]-[name]-[set]-[collector]-[language]-[treatment]-r[revision].[extension]
A hypothetical export might be U-042-01-counterspell-SET-123a-en-retro-r03.png. If the cube deliberately contains a second copy using the same printing, give that physical card its own slot or copy value. If it uses different artwork, set, frame, or language, those fields change as well.
Keep names lowercase, use hyphens consistently, and avoid operating-system-sensitive punctuation. Do not try to place a full card description in the filename. Long filenames are harder to scan and easier to truncate in upload tools. The manifest should remain the authoritative record.
Choose reprints in a fixed order
Reprint selection becomes much easier when every card follows the same decision sequence. I would approve versions in this order:
- Lock the gameplay identity. Confirm that the intended card and rules object are correct before evaluating appearance.
- Choose the reading experience. Decide whether the cube prioritizes familiar English wording, a particular templating era, or another language with a reference system.
- Choose the artwork and visual treatment. Record illustration, frame, border, showcase treatment, or other distinguishing notes.
- Assign the cube slot and copy number. Do this even when the cube currently contains only one copy.
- Generate or collect the production asset. Keep it in a draft location until its text, crop, orientation, and front/back pairing have been checked.
- Approve one revision. Move or copy only that revision into the approved export set.
- Audit collisions and quantities. Confirm that no two active rows claim the same slot and that every approved row points to an existing file.
| Priority | What to standardize | Main tradeoff |
|---|---|---|
| Gameplay clarity | Language, current wording, recognizable layout | May exclude favorite foreign-language or highly stylized versions |
| Visual unity | Frame era, border, treatment, color character | Can make a curated cube feel less historically varied |
| Nostalgia | Specific sets, frames, or remembered artwork | May produce inconsistent readability across the cube |
| Art curation | A deliberate illustration for every slot | Requires more metadata and replacement discipline |
| Easy maintenance | One language and a limited set of treatments | Reduces artistic variety but simplifies future updates |
| Intentional duplication | Unique slot and copy IDs for every physical copy | Adds rows, but prevents accidental quantity changes |
Readability should be checked at the card level rather than assumed from a large screen preview. If you are mixing custom designs with published-style layouts, use the hierarchy checks in making custom MTG proxies easy to read before approving a file.
Distinguish duplicates from alternate versions
Duplicate names are not necessarily duplicate files, and duplicate files are not necessarily mistakes. Your manifest must express which situation is intentional.
Suppose two slots contain the same game card. Slot R-017 uses a standard-frame English printing, while R-093 uses a retro-frame version with different artwork. Both rows share the card name and underlying rules identity, but they have different slot IDs, printing selections, art notes, and filenames. A name-only deduplication tool could incorrectly delete one.
Now suppose both slots intentionally use the same printing and production image. You can either reference one approved asset from two manifest rows or create two clearly named exported copies. The first method reduces storage duplication; the second can make upload quantities easier to inspect. Whichever method you choose, the manifest quantity total must equal the number of physical cards requested.
Do not encode intentional repetition by quietly changing an upload quantity from one to two. Record the reason in the manifest. Separate rows are especially useful when copies occupy different modules, colors, rarity bands, or draft roles.
Handle special assets explicitly
Shared artwork and different frames
An illustration identifier alone is not enough when the same artwork appears in multiple frames or treatments. Record both the art choice and the printing or treatment. The player may see the same painting, but the crop, rules layout, border, and visual weight can differ.
Foreign-language cards
Record language as its own field rather than adding “foreign” to a note. If your group needs an English reference, track that reference separately from the printed cube asset. This prevents the reference image from being mistaken for the file that should enter production.
Double-faced and split cards
For a double-faced card, keep front and back filenames in separate fields and verify their pairing. Do not infer a back from alphabetical order. Split cards still need orientation review because an image can be technically present but rotated incorrectly. If your production method uses a generic back or a separate reference card, document that choice in the row rather than assuming it applies to the entire cube.
Tokens, emblems, dungeons, and reminders
Track support pieces in a separate asset class or sheet tab. They should not silently inflate the main cube count. Include a field that identifies whether each item is drafted, generated during play, or supplied only as a reminder. For more detailed token planning, see the custom MTG token workflow.
Replacement and superseded files
Never overwrite the only copy of an approved asset. Move superseded revisions to an archive folder and mark them inactive in the manifest. An archive is not the print queue: only files whose rows have an approved status should be eligible for export.
Use a folder structure that reflects approval status
A small number of clear folders works better than a deep hierarchy organized by every possible attribute. For example, maintain source, work-in-progress, approved, export, and archive folders. The source folder holds original downloads or design files. Work-in-progress contains edits. Approved contains the accepted revision. Export is rebuilt for each order, and archive contains superseded assets.
Do not manually “clean up” an old export folder and reuse it. Build each export from approved manifest rows into an empty batch folder. If you are sending a revised selection through a custom MTG card printing service, that clean rebuild prevents a removed card or obsolete revision from surviving simply because its file remained in the previous folder.
Run three audits before export
One sort order will not expose every mistake. Perform three passes, and compare the manifest total with the actual exported asset count after each material change.
- Sort by card name. Look for unexpected repeats, inconsistent languages, conflicting treatments, and cards that were renamed without updating their files.
- Sort by set code and collector number. Check whether repeated printing identifiers are intentional. Keep collector numbers as text during this review.
- Sort by slot ID and filename. Find missing slots, duplicate slots, broken file references, old revision suffixes, and front/back pairing errors.
Then run a final quantity check. Sum the manifest quantity column for approved rows. Compare that total with the number of physical fronts expected in the order, accounting deliberately for any shared files with quantities greater than one. Count support pieces separately. Open a sample from the beginning, middle, and end of the sorted export to confirm that filenames point to the expected images rather than merely existing files.
Pre-export checklist
- Every physical cube slot has one stable, unique slot ID.
- Every repeated card has an intentional copy or slot identifier.
- The underlying game-card identity matches the cube list.
- Set, collector number, language, art, frame, and treatment match the intended version.
- Collector numbers and IDs are stored as text where appropriate.
- Every approved row points to an existing front file.
- Back files are paired explicitly when the workflow requires them.
- Only one revision is marked approved for each asset.
- Superseded files are archived outside the export folder.
- Tokens and other support pieces are counted separately.
- The approved manifest quantity equals the intended physical-card total.
- The newly built export contains no files left over from an earlier batch.
A brief note about sanctioned events
A personal cube-production workflow and authorization to use a proxy card in a sanctioned tournament are separate issues. The Magic Tournament Rules govern the limited circumstances in which tournament officials may authorize proxy cards; a home cube file system should not be treated as tournament authorization.
Build the manifest before the final export
The safest next step is simple: assign slot IDs to the current cube list before selecting more images. Add the exact printing and production-file fields, mark only reviewed assets as approved, and generate a fresh export from those rows. Finish by comparing the exported count with the approved manifest quantity.
Good cube proxy file organization makes reprints boring in the best possible way. You can change an artwork, replace a damaged card, or add a deliberate second copy without guessing which file was used last time. The manifest preserves the decision; the filename makes the asset easy to inspect; and the final audit protects the physical batch.