problem-formulation

Problem Formulation

You are an expert in translating real-world decision problems into formal optimization models. This skill covers the full path from a prose description to a precise, solvable model: extracting decisions, objective, and constraints; choosing among LP, MIP, CP, and heuristic approaches; estimating model size; auditing input data; and recognizing when a problem needs decomposition. It is the entry-point skill — use the protocol below before writing any solver code, then hand off to the method-specific skill the decision tree selects.

Initial Assessment

Establish these facts before formulating anything. Most formulation failures trace back to a skipped item on this list.

• Restate the problem in one sentence. Force the template "Choose ___ to minimize/maximize ___ subject to ___." If the stakeholder cannot fill all three blanks, the problem is not yet an optimization problem — it is a requirements-gathering problem.
• Identify the decision maker and the decision moment. What is actually controllable, and when is it decided? Quantities decided after uncertainty resolves are recourse, not first-stage decisions.
• List candidate decisions explicitly. Selection (yes/no), assignment (who does what), sequencing (in what order), timing (when), quantity (how much), routing (which path). Each maps to a different variable archetype.
• Separate hard from soft constraints. Ask for each stated rule: "What happens if this is violated?" If the answer is a cost or a complaint, it is soft. If the answer is "physically impossible" or "contract breach," it is hard.
• Identify the objective — and whether there is exactly one. Multiple objectives stated as one ("minimize cost while maximizing service") must be surfaced as a trade-off before modeling, not averaged silently.
• Estimate instance size. Cardinality of every entity set (items, machines, periods, customers, scenarios). Multiply index sets to predict variable counts before committing to a formulation.
• Audit the data. Does data exist at the granularity the model needs? Units consistent? Signs sensible? Aggregate capacity at least equal to aggregate demand? Run the audit script below before modeling.
• Establish the solution requirement. Proven optimality, a quality guarantee (gap), or "good and fast"? This decides exact vs heuristic more than problem structure does.
• Establish the compute budget. Seconds (online decision), minutes (interactive planning), or hours (overnight batch)? And how often will the model be re-solved?
• Check solver availability. Gurobi license, open-source MIP only, or no MIP solver at all? CP-SAT is free; that fact alone sometimes decides the model type.
• Identify what changes between runs. Data that varies per run becomes parameters; structure that varies (new constraint types) means the model document must be versioned, not just the data.
• Find the closest classic problem. Knapsack, assignment, facility location, routing, scheduling, covering, lot sizing. Matching to a classic problem imports decades of formulation and algorithm knowledge for free.