Programming Implementation, Result Validation, and Data Figures
This phase follows
reports/ANALYSIS_MODELING_REPORT.md
and
reports/MODEL_SELECTION_REPORT.md
. If H2 for CUMCM 2026 has not been explicitly approved, stop and return to
; do not select a core model on your own.
As needed, read the “Question-Type Error-Prevention Quick Reference,” “Code Implementation and Results,” “Common Coding Errors,” and “Charts and Visualization” sections of
../_references/math_modeling_norms.md
.
Outputs and Scope
Responsible for: runnable source code, environment manifest, experiment outputs, result records, constraint checks, baseline, sensitivity analysis, and data-driven figures. Not responsible for flowcharts, architecture diagrams, or the paper body.
At least create:
text
code/
├── run_all.py
├── problem1.py
├── ...
├── utils.py
├── requirements.txt # 或 environment.yml
└── outputs/
├── preprocessing_summary.json
├── model_parameters.json
├── constraint_check.json
├── sensitivity.csv
├── figure_data/
└── logs/
results/
├── final_results.json
└── constraint_check.json
reports/RESULTS_REPORT.md
figures/*.pdf
Remove inapplicable intermediate files as appropriate for the actual problem, but
, the environment manifest,
, constraint/validity check records, and
are required outputs in CUMCM mode.
1. Establish a Unified Reproducibility Entry Point
should start from the raw inputs and execute preprocessing, each subproblem, baseline, validation, sensitivity analysis, result tables, and figure generation in dependency order. It must not rely on hidden IDE state, manually modified intermediate files, or undocumented interactive operations.
The environment manifest must list only dependencies actually used and record the Python version. Fix seeds for stochastic processes; when stability conclusions are needed, use multiple independent runs and record the distributions. Resolve relative paths explicitly from the project root or script location so that the workflow does not run only on the author’s machine.
2. Implement and Run Each Subproblem Iteratively
For each subproblem, proceed in this order: read data → implement → small-sample test → main run → independent validation → save results. If the implementation differs from the H2-approved approach, first explain the reasons and impact in the report, and, in CUMCM mode, request team confirmation of substantive changes.
For optimization problems, construct a feasible solution before optimization; for prediction problems, use correct training/validation boundaries; for evaluation problems, record metric direction, normalization, and the source of weights; for simulation problems, check units, boundary conditions, and convergence.
3. Baseline and Rapid Comparison
For each core conclusion, implement a task-appropriate simple baseline or small-scale exact reference solution, for example:
- Prediction: compare naive, linear, or classical time-series baselines with the complex model;
- Optimization: compare greedy or small-scale exact solutions with a heuristic/advanced solver;
- Evaluation: compare simple weighting with composite weighting.
Comparisons must use the same data splits, constraints, and evaluation criteria. If a baseline is not applicable, document the specific reason; do not merely state that the main model is more advanced.
4. Independently Validate Results
A solver’s
does not mean that the model solution is valid. Use validation logic independent of the objective solver to plug back and check each item:
- variable upper and lower bounds, integer/0–1 conditions;
- every constraint, capacity, time window, conservation relation, and unit;
- physical bounds, null/extreme inputs;
- orders of magnitude of results and progression relationships between subproblems;
- key metrics that will be cited in the paper.
Write constraint values, permitted bounds, slack, and pass status to
results/constraint_check.json
. The validation logic itself must not reuse the same potentially erroneous expression in a way that compromises independence. Failed constraints must prevent results from being marked final.
results/final_results.json
serves as the single source of truth for numerical values in the paper and records their definitions, units, and precision; chart data is saved to
code/outputs/figure_data/
.
documents the runtime environment, data processing, results for each question, baseline, validation, sensitivity, consistency with the modeling reports, and the complete execution command.
5. Generate Data-Driven Figures
Generate vector PDF figures in
as needed to support the actual analysis. For prediction, use actual-vs-predicted comparisons and error distributions; for optimization, use convergence, resource utilization, and solution comparisons; for evaluation, use rankings, heatmaps, and sensitivity plots. Every figure must be generated from saved data and referenced in
.
Do not place large titles inside figures; text, axes, and legends must use the same language as the paper; ensure that figures remain distinguishable in grayscale. Do not generate flowcharts, architecture diagrams, or charts merely to increase the number of figures.
6. CUMCM H3: Core Result Review
In CUMCM 2026 mode, after completing a reproducible run and independent validation, write the following to
compliance/HUMAN_REVIEW_LOG.md
:
text
STATUS: WAITING_FOR_HUMAN_RESULT_REVIEW
Provide the competition team with the minimum sufficient materials for review: the complete execution command, key results and units, baseline comparison, constraint checks, edge cases, sensitivity results, and core figures. Only after team members have explicitly rerun or verified the results and explained any modifications may
be recorded. The Agent must not check review items on the team’s behalf; if H3 is not approved, the results must not be handed to the paper stage as final conclusions.
AI Usage Audit Trail
In CUMCM 2026 mode, append an entry to
compliance/AI_USAGE_LOG.md
for each significant coding task, recording the tool name and version/model, workflow stage, purpose, main prompting approach, AI output, adopted/not adopted content, human modifications, and verification. All code and analysis other than language polishing must undergo a recorded human review; unknown information must not be guessed.
Completion Criteria
- can reproduce the core results and figures from clean inputs.
- The main model’s improvement over the baseline is evidence-based, or there is a sufficient reason for having no baseline.
- Every key result passes independent constraint/validity checks item by item.
- The report, JSON, tables, and figures use the same numerical conventions.
- In CUMCM mode, H3 has genuine confirmation from the team; otherwise, it remains in the waiting state.