When a HiMCM team submits a paper, the assumptions section is frequently treated as a disclaimer – a list of things they hope judges will ignore. Phrases such as ‘we assume demand is uniform’ or ‘we ignore weather effects’ appear without context. This approach fails because an assumption is not a shield against criticism; it is a modelling decision that shapes the mathematical structure. If you cannot trace an assumption to a specific variable, equation, and sensitivity check, your model lacks defensibility.
This guide focuses on the pre-modelling stage. It answers one key question: how do you justify a simplifying choice before building the model? The solution is not a longer list of assumptions, but a traceable register connecting each assumption to its specific model term, potential tests, and fallback plans.
The Modelling Decision Chain
Hanlin International Education, the independent operator of this guide, describes in its Study Pack 02 a modelling decision chain: deconstruct the problem, define variables and assumptions, choose and justify a model family, validate and test sensitivity, then write a defensible argument. The chain matters because assumptions sit before model choice. An assumption is not a post hoc excuse for a weak result; it is a commitment that determines what the model can represent.
If an assumption is unjustified, later validation cannot repair it. A validation test can reveal that predictions fail, but it cannot explain why the team chose a simplifying condition that was never linked to the mathematics. Sensitivity analysis can show that a result changes when a parameter moves, but it cannot rescue an assumption that was never tied to a parameter, equation, or decision variable. This is why assumption justification is not a formatting task. It is the first link in a chain that later sections depend on.
Three Common Failure Modes
Most HiMCM assumptions problems fall into three traps. The first is the untestable assumption. A team writes, ‘the population is stable’, but never defines stability numerically, never states the time horizon over which stability is assumed, and never shows which equation uses that stability. The second is the irrelevant assumption. A team writes, ‘we assume the earth is flat’, while the model uses Euclidean distances in a local delivery problem where curvature is already negligible. The assumption may be true, but it does not affect the model, so it wastes space and signals that the team is listing phrases rather than making decisions. The third is the hidden assumption. A team uses a default parameter in software, a cleaning rule in a spreadsheet, or a fixed threshold in code, but never states that choice in the paper. The judge sees the output but not the decision that produced it.
Each failure has the same root: no link to a model term. If a claimed assumption does not appear in the objective function, a constraint, a parameter, a data-processing step, or an algorithm choice, it should be removed. If it appears but cannot be tested, it should be flagged as a risk or replaced with a narrower condition that can be checked. If it appears only in code, it must be promoted into the assumptions section and cross-referenced to the relevant table, equation, or figure.
Worked Teaching Illustration: Tracing a Distance Assumption
Teaching illustration (hypothetical, not an actual contest problem). A team models delivery routing in a city laid out on a rectangular grid. The problem statement says streets follow a grid and diagonal avenues are rare. The team states: ‘We assume travel distance between stops i and j is Manhattan distance: d_ij = |x_i – x_j| + |y_i – y_j|.’ This is a strong assumption, but it is also testable and directly tied to the geometry of the city.
- Problem statement link: The prompt describes a grid street network. The assumption mirrors that geometry rather than ignoring it.
- Model term affected: The distance matrix d_ij becomes the cost coefficient in the route objective, min sum d_ij x_ij. Changing the distance metric changes which route is optimal.
- Sensitivity test: Compare Manhattan distance with Euclidean distance for the same stops. For depot (0,0) and stop (3,4), Manhattan distance is |0-3| + |0-4| = 3 + 4 = 7. Euclidean distance is sqrt((3-0)^2 + (4-0)^2) = sqrt(9 + 16) = sqrt(25) = 5. Manhattan is 2 units longer, a relative overestimate of (7 – 5) / 5 = 0.40, or 40%. For any single leg, Manhattan distance never underestimates Euclidean distance and can overestimate it by at most sqrt(2) – 1, about 41.4%, when the horizontal and vertical components are equal. For a multi-leg route, if you sum leg distances, the same maximum relative overestimate bound applies when Euclidean distance is the comparison.
- Limitation stated: If diagonal avenues are available, the model overstates travel time. The paper should say that the route plan is an upper-bound estimate under grid travel, or that validation against a road-network distance matrix would be required before using the route in operations.
This four-step trace transforms a one-line assumption into a defensible modelling decision. It shows why the simplification was made, where it enters the mathematics, how it can be challenged, and what the team would do if the challenge succeeds. The arithmetic is checkable, so the limitation is not a vague disclaimer.
The One-Page Assumptions Register
Teams should complete a register during initial brainstorming. The register forces clarity before coding begins. Each row contains five columns: claim, reason, model term affected, test method, and decision if violated. The table below is a teaching illustration, not a template tied to any contest problem.
| Claim | Reason | Model term affected | Test method | Decision if violated |
|---|---|---|---|---|
| Travel distance is Manhattan. | Grid streets; diagonal avenues rare. | Distance matrix d_ij in route objective. | Compare with Euclidean distance; example: 7 versus 5 for (0,0) to (3,4). | Use road-network distances or report upper-bound travel times. |
| Demand is independent of time. | No hourly data; focus on static routing. | Arrival rate in queue or service objective. | Run peak versus off-peak scenario. | Use time-dependent arrival rates. |
| Vehicles are identical. | Fleet specifications unavailable. | Capacity constraint. | Test one large and one small vehicle. | Separate vehicle classes. |
This register prevents hidden assumptions. If a team cannot fill in the model-term column, the assumption is likely irrelevant and should be removed. If they cannot define a test method, the assumption is untestable and weakens the paper’s credibility. If they cannot name a decision when the assumption fails, the limitation section will read as an apology rather than a modelling choice.
Team Clinic: 45-Minute Audit
Before moving to model-family choice, teams should run a 45-minute audit on a practice problem. Do not solve the problem. Select one major simplifying choice and apply the tracing method above. Start with ten minutes to identify the assumption and write it as a single testable sentence. Spend fifteen minutes mapping it to a specific equation, parameter, constraint, or algorithm step. Use another ten minutes to design a quick sensitivity check: what changes if the assumption is false? Finally, allocate ten minutes to draft the limitation paragraph and the decision if violated.
The output of the clinic is small: one completed register row and one paragraph. The value is not the amount of text. The value is the habit of refusing an assumption that cannot be located in the model. If the team cannot complete the model-term column, they should either narrow the assumption until it has a clear role or remove it and accept that the model needs a different simplification.
Checklist Before Model Selection
Once the assumptions are traced, teams can proceed to model-family choice with a cleaner basis. Ensure every assumption has a corresponding entry in the register. Ensure every critical assumption has a sensitivity plan, and link that plan to your HiMCM Sensitivity Analysis: Change One Assumption Without Losing the Decision. If an assumption is critical but untested, flag it as a risk. If an assumption is minor but heavily tested, consider removing it to save computational resources. This balance keeps the model robust without making it unnecessarily complex. Teams should also compare the register with HiMCM Baseline Models: Making a Complex Approach Earn Its Place so the simplest viable approach is justified before complexity is added.
Finally, before the final write-up, check HiMCM Model Validation: Test Predictions on Information You Did Not Fit against the assumptions register. If validation tests a condition that was never stated, the paper has an inconsistency. If validation ignores a critical assumption, the paper has a credibility gap. The assumptions section should match the equations, code, and validation plan.
Conclusion: Defensible Choices Carry the Paper
In HiMCM, a defensible argument is as important as accurate numbers. A paper whose assumptions match its equations, code, and validation plan is easier for any reader to follow. By tracing each simplifying choice through variables, equations, tests, and limitations, you create a transparent reasoning path. This transparency allows reviewers to follow your logic even if they disagree with a specific choice. Preparation should focus on this structural integrity rather than only on technical execution.
Hanlin International Education provides independent HiMCM information and preparation support through this guide and its coaching program. The goal of an assumptions clinic is simple: before your team builds, make one simplifying choice strong enough to defend. Then repeat the process for the next choice. Assumptions you can defend carry the paper.
Frequently Asked Questions
Do I need to list every possible assumption?
No. Focus on assumptions that significantly affect the model’s output, structure, or interpretation. Minor details that do not change the result can be omitted to keep the paper concise.
How detailed should the sensitivity test be?
The test does not need to be computationally expensive. A boundary case, an alternative scenario, or a simple comparison calculation is often enough to show that you understand the impact of the assumption.
Can I change assumptions after building the model?
It is better to define them beforehand, but if you discover a flaw during modelling, update the assumptions section to match the final model. Then re-check the affected equations, code, and validation plan for consistency.