Math Modeling Contest Route Selection

---
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 more, with a reproducible scoring script."
---
<!-- ==================== 本仓适配块（Academic Agent Toolkit, 2026-09-03） ==================== -->
<!-- 上游: y3519712124-ui/math-modeling-contest-route-selection (MIT, pinned 2026-09-03); 正文为上游原文，仅头部/尾部适配 -->

## 本仓适配：路径与运行方式

- **脚本路径**：本技能 scripts/score_topics.py（相对工具箱根 `academic-toolkit/skills/math-modeling-contest-route-selection/scripts/score_topics.py`），Python 3 标准库实现，`python score_topics.py <input.json>` 直接可跑，零第三方依赖。
- **references 加载**：本目录 references/ 10 文件按 SKILL.md Resource Routing 段的触发条件按需加载，路径改为本目录相对路径。
- **触发条件（本仓场景）**：CUMCM/MCM 选题会、AI 选题结果审计、建模路线比较、获奖论文逐问建模蒸馏。

## 输入/输出契约（上游已有，此处摘要）

- 输入：选题评分 JSON（topic/route 级 evidence + flip_condition 按准则分键；fallback 必须含 trigger/action/deadline 三元结构；热门题强制 crowd_escape_mechanism）
- 输出：三层编号结构（A/B/C 选题 12 段 / 单题 9 段 / 深度规划 +4 项）+ score_topics.py 产出的排名表与警告

## 质量铁律（上游 13 条同质化判据 + 7 条强制重写 + 工程 7 问门禁，逐条保留）

任一命中即判泛型并强制重写；工程可行性 7 问任一缺失即拒绝/降级。

<!-- ==================== 适配块结束 ==================== -->


# 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.


## 执行与产出

- artifacts: 选题输出（12/9/4 段编号结构）、score_topics.py 产出的 report.md 排名表与警告、Method Route Card 17 字段 JSON
- gates: 工程 7 问门禁全过；同质化 13 条零命中；fallback 三元结构完整；评分 JSON 按 schema 分键
- 执行记录：score_topics.py 经执行会话 `run` 下发，脚本产出与评分 JSON 由程序自动登记；不手工落盘 .engine/evidence/