Math Modeling Contest Route Selection

SKILL.md

---
name: math-modeling-contest-route-selection
description: Select superior mathematical modeling contest problems and modeling-solution routes for CUMCM A/B/C, MCM, ICM, and similar contests. Use when comparing contest topics, choosing modeling methods, distilling award-paper per-subquestion modeling/solving logic, auditing AI-generated topic choices, evaluating engineering feasibility, designing baseline-main-validation-refutation model stacks, or proving why one problem/method route is more executable and paper-worthy than alternatives.
---

# Math Modeling Contest Route Selection

## Overview

Use this skill to prevent blind AI topic choice. The central object is not just "which problem should we choose"; it is "which problem has the strongest feasible modeling route under contest time, data, coding, validation, and paper-writing constraints."

For CUMCM, always compare A/B/C through two layers:

1. Problem selection: Does this topic have enough clarity, data/parameter access, and paper narrative?
2. Method-route selection: Can the team implement, solve, validate, and explain a superior modeling path?

Choose the problem whose best method route is strongest. Do not choose a problem merely because its domain looks familiar or its generic AI plan sounds impressive.

## CUMCM A/B/C Workflow

1. Parse all three problems before recommending any one.
   - Extract task outputs, inferred judge-visible criteria, data/parameter needs, constraints, likely figures/tables, and final decision objects.
   - If only letters A/B/C are provided, ask for the full statements or give only a provisional prior.

2. Build one "problem card" for each problem.
   - Domain: engineering/physics, optimization, data analysis, public policy, evaluation, forecasting, network, simulation, or hybrid.
   - Mathematical core: mechanism model, optimization, prediction, evaluation, simulation, uncertainty, graph/network, control, or data mining.
   - Deliverables: what the paper must calculate, rank, predict, optimize, explain, or recommend.
   - Risks: missing data, fragile assumptions, excessive coding, weak validation, unclear outputs, or generic method stack.
   - Crowding risk: whether many teams will use the same obvious method stack; if high, include `crowd_escape_mechanism`.
   - Team fit: whether the route matches the team's coding, domain, optimization, statistics, or physics strengths.

3. Build at least two "method route cards" for each plausible problem.
   - Minimum viable route: simplest route that can finish a coherent paper.
   - Strong paper route: route with the best originality/validation/presentation balance.
   - Optional ambitious route: only include if failure can fall back to the minimum route.
   - When sub-questions are available, map them to role-based slots (`first`, `main`, `extend`, `final`) instead of assuming every problem has exactly Q1-Q4.
   - For any fully stated problem, `question_chain` is mandatory. Do not finalize a recommendation if a route card has no sub-question chain; mark the chain as provisional only when the statement itself is unavailable.
   - For each sub-question, explain why the chosen model was selected over at least one simpler or fashionable alternative.

4. Compare method routes before comparing final topics.
   - A weaker topic with a robust, elegant route can beat an attractive topic whose route is vague.
   - A fashionable method does not help unless it improves a measurable output, supports validation, or creates a clearer paper story.
   - Show topic differentiation and best-route differentiation separately when they disagree.
   - Run a model-choice tournament: baseline, one rejected alternative, chosen route, deciding test, and flip condition.

5. Recommend one primary problem and one fallback.
   - The fallback should reuse part of the team's prepared code, data workflow, or method stack where possible.
   - If the top two final scores differ by 0.20 or less on a 0-5 scale, state that the lead is uncertain; if they differ by 0.05 or less, call it a near tie.
   - Include the strongest reason to reject the primary problem and the test or evidence that lets it survive.

## Method Route Card

For every candidate route, fill these fields:

- `core_question`: What mathematical question does this route answer?
- `decision_variables_or_states`: Variables, states, indicators, or predicted objects.
- `assumptions`: Necessary assumptions and how to stress-test them.
- `binding_constraints`: Hard constraints that can make the route infeasible, such as actuator stroke, adjacent-node deformation, capacity, inventory, conservation, boundary, time, or budget limits.
- `baseline`: Simple model that must be beaten or extended.
- `main_model`: Main equations/algorithm/model family.
- `solver_or_algorithm`: How it will be computed within contest time.
- `data_or_parameters`: Source, estimation method, or defensible synthetic plan.
- `validation`: Baseline comparison, sensitivity, ablation, external consistency, limiting case, or simulation stress test.
- `model_choice_rationale`: Why this model family fits the deliverable better than alternatives.
- `rejected_alternatives`: Simpler or fashionable methods considered and why they are weaker.
- `refutation_tests`: Tests that could disprove this route.
- `paper_figures`: Figures/tables that make the route visible to judges.
- `fallback`: Include `trigger`, `action`, and preferably `deadline`. Example: "If clustering silhouette stays below 0.25 after standardization and log-ratio transforms by Day 2 noon, switch to hierarchical clustering plus interpretable decision tree."
- `question_chain`: For each sub-question, role, deliverable, baseline, main model or upgrade, model-choice rationale, rejected alternative, refutation test, solver, validation, figure/table, fallback, and how it supports the next question.
- `superiority_claim`: One sentence explaining why this route is better than the generic AI route.

When using `scripts/score_topics.py`, `notes.highlight` is shown first in the route highlight column; `superiority_claim` is used as the fallback highlight.
For scoring JSON, add `evidence` and `flip_condition` at topic and route level. Use objects keyed by score criterion for decisive high or low scores; a single overall string is not enough to justify every decisive criterion. Use structured fallback objects when possible:
`{"trigger": "...", "action": "...", "deadline": "..."}`.
For `question_chain`, either provide explicit `question_weight` for every sub-question or omit all sub-question weights and let the script use role-based defaults.
For popular or crowded topics, add `crowd_escape_mechanism` at topic or route level. For team-dependent decisions, add `team_profile`, `team_fit_blend`, and each topic's `team_fit_score` or `team_fit: {"score": ..., "rationale": ...}`.

## Engineering Feasibility Gate

Reject or downgrade a route if any answer is missing:

- Can the model be implemented with the team's actual coding ability?
- Are the input variables measurable or defensibly estimated?
- Is there a baseline result within the first contest day?
- Can the main solver finish fast enough for iteration?
- Can errors, parameters, or weights be stress-tested?
- Can the final results become clear plots/tables rather than only prose?
- Is there a fallback route if data collection, tuning, or optimization fails?

Read `references/engineering-feasibility.md` when judging implementation load, solver risk, and fallback design.

## Anti-Homogeneity Rules

Treat a plan as too generic if it contains any of these patterns:

- "Use entropy weight/TOPSIS/AHP/grey prediction/LSTM/random forest" without problem-specific feature construction or validation.
- A method list that could fit any contest problem after replacing nouns.
- No baseline model.
- No reason why the chosen model beats at least one simpler or common alternative.
- No refutation test that could disprove the chosen route.
- High topic differentiation score on a crowded topic without a `crowd_escape_mechanism`.
- Strong route differentiation on a crowded or only moderately differentiated topic without a named `crowd_escape_mechanism`.
- No route-level fallback.
- Fallback has no measurable trigger, deadline, or switch condition.
- No failure mode analysis.
- No inventory of binding constraints for constrained optimization, physics, engineering, supply-chain, or capacity-planning routes.
- No explanation of why a simpler model is insufficient.
- No quantitative validation route.
- A paper highlight that only says "comprehensive," "accurate," "innovative," or "multi-factor."

When a plan fails this check, rewrite it by forcing:

- One domain-specific metric or state variable.
- One baseline comparison.
- One robustness, sensitivity, or ablation experiment.
- One binding-constraint inventory, with the constraints that are most likely to break feasibility.
- One solver or coding plan.
- One judge-visible visualization.
- One fallback model with a trigger condition and action that can still produce a full paper.

## Resource Routing

- Read `references/contest-archives.md` when the user asks for historical grounding, official archive links, or long-horizon contest pattern distillation.
- Read `references/award-method-distillation.md` when the user asks what national-award or excellent papers tend to do, or wants historical solution-method inspiration before choosing A/B/C.
- Read `references/award-question-decomposition.md` when the user asks how each sub-question should be reasoned, modeled, validated, or connected into a national-award-style paper.
- Read `references/award-route-pattern-library.md` when the user asks to distill how award-style papers model and solve problem 1, problem 2, problem 3, and later sub-questions.
- Read `references/refutation-and-model-choice.md` when auditing or improving topic choice, model choice, rejected alternatives, flip conditions, or self-refutation loops.
- Read `references/paper-scoring-framework.md` when the user asks for scoring standards, paper competitiveness, multi-dimensional evaluation, or judge-visible strengths and weaknesses.
- Read `references/problem-taxonomy.md` when classifying A/B/C problem types or finding differentiated angles.
- Read `references/method-map.md` when mapping problem symptoms to modeling method families.
- Read `references/engineering-feasibility.md` when auditing solver complexity, data pipelines, fallback routes, and implementation realism.
- Read `references/selection-rubric.md` when scoring A/B/C or auditing final recommendations.
- Run `scripts/score_topics.py <input.json>` for final A/B/C ranking whenever possible; do not hand-reconstruct the final table if a scoring JSON can be written. Use `--help` to see CLI options.

## Output Format

Use a compact output for quick topic selection, and a deep output when the user asks for per-question planning, paper design, scoring standards, or national-award-style reasoning.

For CUMCM A/B/C selection, return:

1. `Conclusion`: primary problem, fallback problem, and one-sentence reason.
2. `Score-gap note`: state near tie (<=0.05), moderate uncertainty (>0.05 and <=0.20), or evidence-backed separation (>0.20).
3. `A/B/C comparison`: topic score, best route score, topic differentiation, route differentiation, main risk, feasibility judgment, and decisive evidence/flip condition.
4. `Crowding and team-fit note`: obvious generic route, crowd-escape mechanism, and whether team strengths could flip the recommendation.
5. `Route comparison`: minimum viable route, strong paper route, optional ambitious route; include route-level evidence and flip condition for decisive scores.
6. `Model-choice tournament`: baseline, rejected alternative, chosen route, deciding test, and flip condition.
7. `Question-chain sketch`: one line per sub-question role (`first`, `main`, `extend`, `final`) naming deliverable, baseline, chosen model, rejected alternative, why chosen, refutation test, validation, figure, fallback trigger/action, and dependency.
8. `Refutation ledger`: strongest reason to choose, strongest reason to reject, test that decides, flip condition, and rescue.
9. `Recommended modeling stack`: baseline, main model, solver, validation, sensitivity, fallback trigger/action.
10. `Why this is superior`: why this route beats the generic AI plan and the other two problems.
11. `Engineering plan`: data, code modules, solver steps, figures, and timeline.
12. `Risks and rescue`: what to do if data/model/solver/time fails; every rescue must have a measurable trigger or deadline.

For a single chosen problem, return:

1. Problem DNA.
2. Generic AI route to avoid.
3. Minimum viable route.
4. Strong paper route.
5. Model-choice tournament: baseline, rejected alternatives, chosen route, deciding test, and flip condition.
6. Role-based sub-question chain: required deliverable, baseline, chosen model/upgrade, rejected alternative, why chosen, refutation test, solver, validation, figure/table, fallback trigger/action, and dependency.
7. Route-level scoring.
8. Validation, ablation, refutation, and sensitivity plan.
9. Paper narrative and figure plan.

For deep paper planning, add:

1. Pre-selection score: feasibility, data/parameter access, day-one baseline, validation opportunity, and differentiation opportunity.
2. Paper-competitiveness score: deliverable alignment, assumption quality, model fit/originality, reproducibility, validation, decision value, expression, engineering feasibility, and differentiation.
3. Score-gap note: if candidates differ by 0.05 or less on a 0-5 scale, treat them as a near tie and choose by team strengths.
4. Moderate-uncertainty note: if candidates differ by more than 0.05 but no more than 0.20, state that the lead is not decisive unless decisive criteria have written evidence.