Keep a Cube Update Log: Track Cuts, Adds, and Why You Changed Them
Table of Contents
TLDR: A useful cube update log records each addition beside its corresponding cut, the reason for the change, and the evidence you want to collect in future drafts. Keep that design record separate from your reprint-only list. The log can contain experiments and reversals; the reprint list should contain only finalized physical changes.
An MTG Cube rarely improves through card swaps alone. It improves when you can connect a change to a design goal, observe what happened, and decide whether the result solved the original problem. Without that record, it is easy to repeat an abandoned experiment, forget why a favorite card was removed, or mistake one memorable game for a reliable pattern.
A cube update log closes that loop. It does not need to become a complicated database. A spreadsheet, notes document, or paper notebook works as long as it consistently answers three questions: What changed? Why did it change? What should you watch during the next draft?
What to record in a cube update log
Start with one row or entry for every paired change. In a fixed-size Cube, that normally means recording an addition and a cut together. Pairing them makes the real tradeoff visible: you are not merely evaluating whether the new card is good, but whether it performs its intended role better than the card or slot it replaced.
Record the following fields:
- Cube name and size
- Version name or number
- Date of the update
- Number and type of drafts since the previous update
- Card added and quantity
- Card cut and quantity
- Color, section, archetype, or functional role
- Reason for the change
- Expected effect on the draft environment
- Specific observation to make during future drafts
- Result after testing
- Final status: keep, revert, revise, or continue testing
- Reprint status and any physical-production notes
The “reason” and “what to watch” fields do the most work. “New card looked interesting” is difficult to evaluate later. “Replace a five-mana payoff with a three-mana enabler so the sacrifice deck can affect the board earlier” gives you a testable hypothesis.
The broader PrintACube guide to updating an MTG Cube without replacing the whole environment also recommends preserving dated versions, pairing additions with cuts, and recording what you intend to observe in later drafts. A dedicated log turns those practices into a repeatable maintenance system.
Copy-and-paste MTG Cube update log template
Use the following fields as a reusable entry in a notes app or as column headings in a spreadsheet. Do not feel obligated to complete every optional field for a routine one-for-one replacement.
- Cube:
- Version:
- Update date:
- Cube size:
- Draft format and player count:
- Drafts since previous update:
- Added card and quantity:
- Cut card and quantity:
- Section, archetype, or role:
- Reason for change:
- Expected effect:
- What to watch next draft:
- Observed result:
- Decision: Keep / Revert / Revise / Continue testing
- Reprint status: Not needed / Needed / Ordered / Installed
- Print notes: Version, treatment, DFC handling, token, or replacement details
For a spreadsheet, a compact version is usually easier to maintain:
| Version | Add / Cut | Reason and hypothesis | What to watch | Result / Status |
|---|---|---|---|---|
| v1.3 | Add: cheaper discard outlet; Cut: slower payoff | Improve setup speed without increasing the number of narrow sacrifice cards | Whether the outlet is drafted and played outside the dedicated deck | Pending |
| v1.3 | Add: flexible land; Cut: narrow dual land | Make fixing useful to more color pairs while preserving commitment | Splash frequency and whether late picks still communicate color availability | Keep after two more drafts |
| v1.4 | Add: interactive two-drop; Cut: expensive removal spell | Lower the interaction curve and give aggressive decks another playable body | Early-board interaction, sideboard frequency, and removal congestion | Continue testing |
These are structural examples rather than universal prescriptions. A powered 540-card Cube, a 180-card micro Cube, and a set Cube expose cards at different rates. Record enough context to understand whether an observation came from a full eight-player draft, a two-player Grid Draft, or another method with different card exposure. The available MTG Cube draft formats can produce meaningfully different evidence.
Use two lists: a design changelog and a reprint-only list
A design changelog and a production list serve different purposes. Combining them creates avoidable mistakes.
The design changelog preserves uncertainty
Your changelog should include proposed swaps, active tests, rejected ideas, reversals, and unresolved observations. It is the long-term memory of the environment. Keeping failed experiments is valuable because it prevents you from rediscovering the same problem six months later without remembering the earlier result.
The reprint-only list contains final decisions
The reprint-only list is operational. It should contain only the cards required for the next physical update, with quantities and any special handling made explicit. Remove abandoned tests and cards you already have available.
A finalized physical-update list can include:
- Exact card name and quantity
- Preferred version or treatment when that distinction matters
- Front and back requirements for double-faced cards
- Required tokens, emblems, or helper cards
- Replacement cards for damaged or unreadable pieces
- A checkbox for ordered, received, sleeved, and installed
If you are preparing unofficial proxy/play pieces, build this compact list only after the design decisions are final. A clean CubeCobra export for Cube printing reduces the chance that experimental cards, old cuts, or duplicate entries enter the production batch.
How to name Cube versions
The best version system is the one you will use consistently. It should let you identify an older list and connect it to the correct change entries. Three simple approaches work well:
| System | Example | Best fit | Tradeoff |
|---|---|---|---|
| Sequential | v1.3, v1.4, v2.0 | Designers who make small batches of changes | The number does not reveal when an update happened |
| Date-based | 2026.09, 2026.10 | Frequently updated or seasonal Cubes | Multiple updates in one month need an added suffix |
| Named release | Spring refresh, Set release update | Groups that remember drafts by season or event | Names sort less cleanly and may become inconsistent |
A practical hybrid is “Cube Name — 2026.10 — v1.4.” The date helps you locate it, while the version number connects it to the changelog. Reserve a major version change for a structural revision, such as replacing several archetypes, changing Cube size, or substantially altering the power target. Routine swaps can remain minor versions.
What to write down after a draft
Do not attempt to transcribe every pick and game. Capture observations that could change a future design decision. One draft provides clues, not a final verdict, especially in a larger Cube where an updated card may not appear at all.
Useful post-draft observations include:
- Was the changed card opened, drafted, played, or left in a sideboard?
- Did more than one drafter appear interested in its role?
- Did the intended archetype have enough enablers and payoffs to form a deck?
- Did the new card overlap with other strategies, or was it useful only in one narrow lane?
- Did mana fixing permit the intended deck without making color commitment trivial?
- Did the deck stumble because of its curve, card quality, or mana rather than the tested card?
- Did removal suppress the threat or synergy you were trying to evaluate?
- Did the draft method expose enough of the Cube to make the observation meaningful?
- Did the replacement improve gameplay while weakening draft signals or theme?
- What evidence would make you keep, revert, or revise the change?
Separate observations from conclusions. “The card went fifteenth and stayed in the sideboard” is an observation. “The archetype no longer works” is a much broader conclusion. Before making another cut, ask whether the result reflects low card quality, insufficient support, poor signaling, or one drafter’s preferences. If a card repeatedly creates unwanted play patterns rather than merely performing well, use a broader framework for diagnosing oppressive cards in an MTG Cube.
How to tell whether a replacement worked
Judge the swap against its stated purpose rather than asking whether the new card won games. A card introduced to improve archetype overlap succeeds if more decks can use the slot without undermining the Cube’s intended identity. A fixing change succeeds if it enables the desired decks while retaining meaningful color choices. A cheaper removal spell may improve interaction but still be a poor change if it suppresses the threats the environment is designed to showcase.
Use a simple four-part review:
- Restate the original problem and hypothesis.
- Record what happened when the card was available, including draft context.
- Consider plausible alternative explanations for the result.
- Choose keep, revert, revise, or continue testing.
“Continue testing” is often the honest answer. Larger Cubes and smaller playgroups produce fewer observations per card. Narrow build-arounds may also need several drafts before you can distinguish low exposure from genuine failure. When the evidence does point toward removal, a structured approach to making cuts in an MTG Cube can prevent one disappointing card from triggering unnecessary changes across the environment.
CubeCobra history versus a manual log
The CubeCobra open-source project describes the application as a tool for building, managing, and playtesting Magic Cubes, including version control, change tracking, and import/export support. Its current controls and available history features can change, so check the live interface before relying on a particular menu, comparison screen, or export workflow.
List-management software and a manual decision log are complementary. Software can preserve list states and show that one card replaced another. A manual log can preserve the reasoning that is difficult to reconstruct later: the expected effect, draft context, competing explanations, and the test you planned to run.
For resilience, save a dated export whenever you publish a meaningful version. Use a stable filename such as CubeName_2026-10_v1-4.csv. Store the matching update log beside it. Even if you later change platforms, those files preserve both the list and its design history.
A lightweight workflow for every Cube update
- Write the problem before choosing a replacement.
- Pair every addition with its cut and identify the affected role or archetype.
- Save the current Cube list as a dated version.
- State one or two observations that would support or challenge the change.
- Draft using your normal player count and format.
- Record concise post-draft evidence without treating one result as definitive.
- Keep, revert, revise, or continue testing.
- Move only finalized additions to the reprint-only list.
- After installing the physical updates, mark them complete and archive that list with the matching Cube version.
This process does not require perfect data. Its purpose is to replace vague memory with enough context to make the next decision better. A short entry completed after every update is more useful than an elaborate tracking system abandoned after one draft.
Keep the log focused on decisions
Start your cube update log with the next swap, not with an attempt to reconstruct the Cube’s entire history. Record the addition, the cut, the reason, and one thing to watch. After the next draft, add the result and choose a status.
Over time, the log becomes more than a list of card changes. It shows how your environment responds to adjustments in curve, fixing, interaction, archetype density, and card exposure. Keep that design history intact, then create a separate reprint-only list when the changes are final. That separation lets you experiment freely without turning every idea into a physical update.