Anatomy of a winning paper

A HiMCM paper has a fixed shape. Master the shape, then fill it with your modeling. Every section on this page is something the judges explicitly look for, based on COMAP's published commentary.

The fixed structure (in order)

Section	Page budget	Counts toward 25?
Summary Sheet (1 page)	1	Yes
Table of Contents	~0.5–1	Yes
1. Introduction & Problem Restatement	~1	Yes
2. Assumptions & Justifications	~1	Yes
3. Notation / Variables Table	~0.5–1	Yes
4. Model Development	~5–8	Yes
5. Application of the Model / Results	~3–5	Yes
6. Sensitivity Analysis	~1–2	Yes
7. Strengths & Limitations	~1	Yes
8. Conclusion & Recommendations	~0.5–1	Yes
9. Non-technical letter / article / blog	1–2	Yes
10. References	~1	Yes
11. Appendices (code, big tables)	remaining	Yes
Report on Use of AI	any	No

Aim to leave 1–2 pages of margin. Going right up to 25 leaves no room for last-minute additions.

Each page header

Top of every page must show Team #1234, Page X of 25. Do this once with a header in your word processor or LaTeX template; check before exporting the PDF.

Anonymity check. Strip every student name, advisor name, and institution name from the paper before exporting. This includes header/footer metadata, PDF properties, image captions, and screenshots. A paper with identifying info can be disqualified.

1 · The Summary Sheet — written last

This is page 1. It's the most-read page of your paper. Write it after everything else, because it must summarize results, not just the plan.

A strong summary contains, in this order:

The problem in one sentence — phrased in your own words.
What you did — the model(s) you built, in two or three sentences.
What you found — the actual numerical/structural answers to each problem requirement.
Why you trust it — one sentence on validation, sensitivity, or comparison.
Recommendation / conclusion — what should the decision-maker do?

Judge's tell. If a summary tells you what the team did but not what they found, it's a sign of a weaker paper. Make sure concrete numbers and recommendations appear.

Example: Summary Sheet skeleton you can adapt

Title: [Problem-appropriate title — not "HiMCM Solution"] The increasing demand for X has created Y problem. We were asked to [restate the goal in one sentence]. To address this, we built a [type of model — e.g., compartmental ODE model / weighted-sum decision model / agent-based simulation] that captures [the 2–3 key mechanisms]. Inputs: [list]. Output: [list]. Applying our model: • Result 1 (with units): ... • Result 2 (with units): ... • Result 3 (qualitative finding): ... Sensitivity analysis shows the result is most affected by [parameter], with a 10% change producing a [N%] change in the output. The model is robust to [parameter] within ±20%. We recommend [the decision-maker] [specific action]. Our analysis suggests this would [quantitative benefit] while [acknowledged trade-off].

2 · Problem restatement & understanding

Don't copy COMAP's prompt verbatim. Show that you understand the problem by:

Restating the problem in your words, in one short paragraph.
Listing what's being asked, ideally as numbered sub-goals matching the prompt's "Requirements" section.
Briefly describing the domain — what's the real-world context? What background do you bring?
Optionally, including a flowchart of your approach (judges love a good flowchart, but only if it's not overcomplicated).

3 · Assumptions with justifications

This is where many teams quietly lose points. Bad pattern:

"Assumption 1: People walk at 1.4 m/s. Assumption 2: Buildings have 4 walls. Assumption 3: ..."

Good pattern — each assumption is tied to the model and is justified:

Assumption. Responders move at a constant 1.4 m/s.
Justification. This is the standard walking pace for adults in good physical condition (Bohannon 1997), and is consistent with NFPA emergency-evacuation guidelines. Constant speed is a simplification that lets us focus on the routing problem rather than dynamics; we test sensitivity to walking-speed variation in §6.
Used in. Equation (4), the time-to-clear-floor formula.

Three things to nail down for each assumption: (a) what you're assuming, (b) why it's reasonable, (c) where in the model it appears.

4 · Variables / notation table

Don't dump every variable here up front. Best practice: a compact table of the most important variables — symbol, description, units, and (optionally) a typical value or source. Introduce minor variables locally where they appear.

Symbol	Description	Units	Typical value
$P(t)$	Honeybee population at time $t$	bees	20 000 – 80 000
$\beta$	Daily egg-laying rate	eggs/day	1 500 – 2 000
$\mu_w$	Worker mortality rate	per day	0.03–0.05

5 · Model development — the heart of the paper

For each model you build:

Motivate the choice. Why this model and not another? "We chose a compartmental ODE because the population evolves continuously and we have aggregate, not individual, data."
State the math. Write the equations clearly. Define every symbol the first time it appears.
Describe how it's solved. "Solved numerically using SciPy's solve_ivp with the LSODA method, time step adaptive."
Show intermediate results. Diagrams, plots, a worked example.
Connect back to the prompt. Each piece of math should clearly serve a requirement.

The judges' commentary specifically calls out one common failure mode: presenting multiple models without picking one. If you tried two approaches and one didn't work, briefly explain why and then commit to the better one.

Visualization rule. Every figure should be: (a) referenced in the text by number, (b) captioned with what it shows and where the data came from, (c) accompanied by a sentence interpreting it. Charts with no interpretation are wasted real estate.

6 · Applying the model

Most HiMCM problems include something like: "Test your model on at least three scenarios" or "Apply to City A, B, C". This is your chance to show your model isn't a one-off. Tips:

Pick scenarios with different characteristics so the model has to work harder than just rescaling.
Tabulate results across scenarios so the reader can compare at a glance.
Comment on counter-intuitive results, don't just report them. "City B scores poorly because…"

7 · Sensitivity analysis

Three legitimate ways to do this at HiMCM level:

One-at-a-time (OAT). Vary each key parameter by ±10% (or ±20%), holding others fixed, and tabulate how the output changes.
Local partial derivatives. For analytical models, compute $\partial \text{output} / \partial \text{parameter}$ at the operating point.
Monte Carlo. Sample parameters from their plausible distributions, run the model many times, report the distribution of outputs.

The output of sensitivity analysis is a list of which parameters matter. That list then feeds Strengths & Limitations and the recommendations.

Sensitivity-analysis worked example

Suppose your evacuation model outputs total clear time $T$. Baseline parameters: walking speed $v=1.4$ m/s, room-check time $\tau=8$ s, communication delay $\delta = 0.5$ s. Baseline output: $T_0 = 240$ s.

Run the model with each parameter shifted ±10%:

Parameter	−10% output	+10% output	% change per 10%
$v$	262 s	222 s	±8.3%
$\tau$	234 s	246 s	±2.5%
$\delta$	239 s	241 s	±0.4%

Conclusion: the model is most sensitive to walking speed and largely insensitive to communication delay at this scale, suggesting effort should focus on improving responder mobility, not radio latency.

8 · Strengths and limitations

This is your honesty section. Judges have explicitly said they don't penalize you for naming weaknesses — they penalize teams that pretend their model has none.

Strengths to claim (when true):

Simple and transparent enough to be reproduced by a non-expert.
Validated against historical data / a known baseline.
Generalizes to scenarios beyond the ones tested.
Modular — components can be swapped without rebuilding everything.

Limitations to flag (be specific):

Data quality (e.g., "we used aggregate national figures because per-city data was unavailable").
Assumptions that may not hold (e.g., constant walking speed in dense smoke).
Computational simplifications (e.g., ignoring stochastic effects below 5%).
Scope (e.g., model assumes a single emergency type and would need extension for…).

9 · Conclusion & recommendations

Half a page is plenty. Three jobs:

Restate what you set out to do and what you found, in 2–3 sentences.
Give concrete, actionable recommendations to the stakeholder.
Note one or two natural extensions of the work.

10 · The non-technical letter / article / blog

Almost every HiMCM problem asks for this. It's often the tie-breaker between two otherwise similar papers, because it's a quick read for the judges and it reveals whether the team can communicate at all.

Key principles:

Different from the Summary Sheet. The Summary is for a peer reviewer. The letter is for a city official, a UN board, a hobbyist, the NFL — name the audience and write to them.
Almost no math. Replace formulas with intuition. "A 10% reduction in fleet electrification translates to roughly 1,200 fewer tons of CO₂ over a decade."
Strong opening line. Lead with the recommendation or the finding, not background.
End with a call to action. What should the recipient do, and by when?

Sample letter opening (E-bus problem)

Dear Director Martinez,

Our analysis recommends that Denver convert 60% of its bus fleet to electric models by 2030, with full conversion by 2033. This trajectory avoids stranding diesel assets while taking advantage of the federal subsidies due to expire in 2028. Compared to a faster timeline, it reduces upfront capital pressure by an estimated $84 million; compared to a slower one, it captures an additional 38,000 tons of avoided CO₂.

The biggest single risk is charging-infrastructure timing — without committed federal funding for new depots by Q3 2027, the schedule slips by roughly two years. We outline three options for accelerating depot construction below.

11 · References

Cite everything you used: papers, books, websites, datasets, code libraries, AI tools. Use either inline numeric citations [3] or author-date (Smith 2022) — pick one and be consistent. Wikipedia is allowed but should be verified against primary sources before relying on it; cite the primary source when you can.

12 · Appendices

Use sparingly. Common contents:

The most important code (with comments) — not your entire codebase.
Large tables that interrupt the flow if placed inline.
Extra plots that didn't make the cut for the main body.
Derivations longer than a few lines.

Remember: appendices count toward the 25 pages. Dumping 8 pages of code at the end will crowd out actual analysis.

13 · Report on Use of AI

If you use any LLM or generative AI tool, you must append a section at the very end of the PDF titled "Report on Use of AI". This section is unlimited length and does not count toward the 25 pages.

What goes in it:

Which tool (name + version + date).
What you used it for (e.g., "polishing language", "generating an initial code skeleton", "summarizing a paper").
The exact prompts you used and the outputs you received.
Whether and how you verified the output.

What AI is bad at, per the judges. Selecting models, interpreting results, drawing scientific conclusions, generating citations (it hallucinates). Use it for language polishing and code drafts, verify everything else.

Final pre-submission checklist

Page count ≤ 25 (excluding AI Report).
Font ≥ 12 pt throughout (including captions and code).
Header on every page: Team #XXXX, Page Y of Z.
No student / advisor / school name anywhere in the PDF (including image metadata).
Every figure has a number, caption, and is referenced from the text.
Every assumption has a justification and points to where it's used.
Sensitivity analysis is present and identifies the most-sensitive parameters.
Strengths and limitations are both stated.
Non-technical letter exists, is to the right audience, contains a clear recommendation.
References cite every external source — including AI tools.
If AI used: separate AI Report appended after page 25.
Single PDF file, ≤ 20 MB, filename = control number (e.g., 1234.pdf).
Summary Sheet is at the front and contains actual results, not just plans.
Submit at least a few hours before the 9:00 pm EST deadline.

Next: Modeling techniques → Or browse past problems