How to Evaluate POE2 Tablet Modifiers: A Combination Checklist

A striking modifier does not settle a tablet’s usefulness or current trade case. Review the complete combination against one intended use before deciding what to do with it.

Define the tablet’s intended use

Give the evaluation a specific player goal before any modifier or value judgment is made.

• Name the activity or outcome the tablet is meant to support.
• Record the current build, route, resource, and risk constraints that matter to the decision.
• Separate required traits from optional preferences.
• Use an unknown label when the closed evidence cannot verify a modifier’s effect or relevance.

Review the complete modifier combination

Evaluate whether the tablet presents one coherent use case instead of scoring isolated lines.

• Classify each modifier as supportive, conflicting, neutral, or unverified for the intended use.
• Check whether multiple modifiers point toward the same practical outcome.
• Flag combinations that require conditions the player cannot currently confirm or sustain.
• Avoid converting modifier count, rarity, or eye-catching wording into an unsupported value conclusion.

Separate personal utility from trade assumptions

Prevent a useful tablet and a marketable tablet from being treated as the same decision.

• Ask whether the tablet advances the player’s stated plan under current constraints.
• Record whether using the tablet would displace a more suitable option.
• Describe the plausible buyer use case without claiming current demand.
• Keep the personal-use decision independent when current market evidence is unavailable.

Build a current comparison set

Turn visible listings into documented references while avoiding unsupported price certainty.

• Compare tablets with a similar intended use and broadly similar modifier combination.
• Record meaningful differences instead of matching on one shared modifier.
• Treat asking prices as observations, not completed transactions or confirmed value.
• Mark the comparison inconclusive when closely matched examples are unavailable.

Choose use, keep, verify, or list

Convert the review into one reversible next action with a clear reason.

• Use when the combination fits the defined goal and the remaining uncertainty is acceptable.
• Keep when a credible future or fallback use is documented but immediate use is premature.
• Verify when an unresolved effect, interaction, or comparison could change the decision.
• List only as a testable valuation assumption, with the comparison basis recorded.

Apply a patch-aware review gate

Keep the workflow useful without inferring tablet or economy changes from general update activity.

• Record the update context at the time of the evaluation.
• Recheck the decision after authoritative information relevant to tablets, modifiers, or the economy changes.
• Do not infer a modifier increase, decrease, or price movement from the supplied patch index alone.
• Preserve the original decision record so a later review can identify what changed.

Decision checklist

• Write down the tablet’s intended use.
• Record the build, route, resource, and risk constraints relevant to that use.
• Classify every modifier as supportive, conflicting, neutral, or unverified.
• Check whether the complete modifier set supports one coherent use case.
• Separate personal usefulness from the possible buyer case.
• Compare only current listings with a similar purpose and combination.
• Record important differences between the tablet and each comparison.
• Choose use, keep, verify, or list and state what evidence would change the decision.

Worked example

A player finds a tablet with two appealing modifiers and initially assumes it deserves a premium listing. They first define the intended activity, then review each modifier against that goal. One appears to support the plan, while the other has an unclear relationship to it. The player marks the combination as partially verified rather than treating both lines as equally valuable. Their available comparisons share one modifier but serve unclear or different use cases, so the visible asking prices do not establish a valuation. Because the tablet could still fit the player’s own plan, the recorded decision is to keep it temporarily and verify the uncertain modifier before choosing between use and a listing test.

Common mistakes

• Ranking a tablet from one modifier while ignoring the rest of the combination.
• Assuming a useful tablet automatically has a verified buyer case.
• Treating visible asking prices as proof of completed demand.
• Comparing tablets that share one line but support different purposes.
• Inferring tablet or economy changes from general patch activity.
• Leaving uncertain effects unmarked and presenting the result as settled.

Related guides