Problem solving

From vague discomfort to explicit plan: workflows that keep complexity visible instead of hiding it in memory.

Frame the problem before you “solve” it

Many failures are framing failures. The presenting question may not be the real question; constraints may be implicit; success criteria may be unstated. A disciplined first step is to produce a problem sheet: inputs, outputs, rules, unknowns, and non-goals.

Non-goals matter. They prevent scope creep: “We are not optimizing elegance yet” or “We are not choosing implementation details until feasibility is established.” In puzzle contexts, non-goals might include avoiding a particular tempting shortcut that historically led you astray.

Reasoning diagram illustrating structured inference.
Explicit structure turns “I think…” into auditable steps.

Decomposition without losing the thread

Subproblems, interfaces, and dependency order

Decomposition splits a large problem into smaller ones with clear interfaces. The classic mistake is creating subproblems that are not independent—solving A changes the rules for B—without tracking those dependencies. A workable method is a simple dependency sketch: nodes are subtasks; edges mean “requires partial result from.”

For logic-heavy tasks, decomposition often aligns with layers of abstraction: first establish ontology (what kinds of objects exist), then local constraints, then global consistency. Jumping to global search before ontology is stable tends to waste time.

Representation: choose a language that matches the pain

If the problem feels slippery, change representation: tables, graphs, algebraic notation, or a sequence of states. The right representation makes deductions mechanical; the wrong one makes them heroic.

“A good notation is not a convenience—it is a theory.” Training is learning when to switch notations, not clinging to the first diagram you drew.

Verification as a first-class stage

Check types of errors, not only the final answer

Verification is not rereading while nodding. It is executing a checklist against known failure modes: boundary cases, reversed inequalities, swapped quantifiers, off-by-one, and unit mismatch. For puzzles, verification includes re-deriving the key step from a different angle—often by plugging the solution back into the original constraints independently.

On Solvexis, we encourage post-mortems: after a solve, spend two minutes answering: “Which step would have been wrong if the puzzle were slightly altered?” That question converts a single success into durable skill.