Suggest edit — problem-framing

Title

Name

Note

---
visibility: public-edit
---

# problem framing

the most important part of mathematical problem-solving happens before any math. choosing *what* to model and *what to ignore* determines everything downstream.

## "all models are wrong, but some are useful"

this idea from George Box (see [[modeling]]) is the foundation of problem framing. the goal isn't to capture reality perfectly — it's to build a representation that's useful for answering your specific question.

the framing move: "given this messy real-world situation, what's the simplest mathematical structure that captures the dynamics i care about?"

## the framing process

how i actually approach it, refined through HiMCM, MCM/ICM, and other competitions:

1. **read the problem 3 times.** first for the gist. second for the constraints. third for what's NOT said — the degrees of freedom.
2. **identify the core tension.** every interesting problem has a tradeoff or a conflict. find it. the model should capture this tension.
3. **list your assumptions explicitly.** what are you ignoring? what are you simplifying? writing these down isn't busywork — it's the intellectual honesty that judges (and reviewers) respect. it also prevents you from accidentally building on an assumption you forgot you made.
4. **choose the level of abstraction.** this is the hardest step. too detailed and the model is intractable. too abstract and it's useless. the art is finding the level where the key dynamics survive but the noise drops out.

## common framing mistakes

- **modeling everything** — trying to include every variable. the model becomes a worse version of reality instead of a useful simplification.
- **wrong abstraction level** — modeling individual agents when you should be modeling aggregate behavior, or vice versa. the question determines the right level.
- **forgetting what question you're answering** — the model drifts as you build it, and you end up with something technically interesting but irrelevant to the original problem. this connects to [[intentionality]].
- **not checking if a simpler model works first** — always start simple. add complexity only when the simple model fails at something the problem requires. see [[estimation-and-sanity-checks]].

## framing in competition vs research

in competition ([[competition-strategy]]), framing speed matters. you have limited time and need to commit to a framing quickly. the 70% rule from [[information-gathering]] applies — frame at 70% confidence and iterate.

in [[research-workflow]], you can afford to explore multiple framings before committing. often the insight IS the framing — finding the right way to look at the problem is the paper.

## connection to the rest of the work

problem framing isn't just a math skill. it's the same skill as identifying the [[critical-path]] in a project, or choosing what to focus on when [[zooming-out]]. the underlying move is always: "what's the simplest representation that captures what matters?"