Problem Analysis, Candidate Modeling, and Selection
This phase translates the problem statement into a verifiable, codable modeling plan; it does not write the paper body or generate the final
.
Read the “Problem Understanding and Subproblem Identification,” “Assumptions and Model Formulation,” and “Problem-Type Error-Prevention Quick Reference” sections of
../_references/math_modeling_norms.md
as needed. In CUMCM 2026 mode, also read
../_references/CUMCM_2026_RULES.md
.
Deliverables
Create or update:
reports/ANALYSIS_MODELING_REPORT.md
reports/MODEL_SELECTION_REPORT.md
Update the following in parallel in CUMCM 2026 mode:
compliance/AI_USAGE_LOG.md
compliance/HUMAN_REVIEW_LOG.md
1. Parse the Problem Statement and Attachments
Treat only explicitly numbered top-level questions in the problem statement as subproblems. For each question, record the inputs, outputs, objective or metrics, constraints, dependencies on other questions, and intended charts. Check each attachment for fields, scale, units, missing values, anomalies, duplicates, and derivable metrics; do not invent fields or treat submission requirements as subproblems.
You must first enumerate ambiguities that would change the modeling direction. For each key ambiguity, provide at least two interpretations and assess them based on the statement’s wording, units, minimal sanity checks, and progression across questions. If an interpretation causes conditions introduced later to have no marginal effect, return for re-review.
CUMCM H1: Problem Interpretation Confirmation
In CUMCM 2026 mode, first write the following into
ANALYSIS_MODELING_REPORT.md
:
- Number of subproblems, inputs, objectives, and outputs;
- Attachment fields and units;
- Key ambiguities, alternative interpretations, and the currently recommended interpretation;
- Risks that remain unresolved in the problem statement.
Then write
STATUS: WAITING_FOR_HUMAN_PROBLEM_CONFIRMATION
in
and request confirmation or modifications from the team. Until explicit confirmation is received, do not mark the recommended interpretation as final, and do not proceed to core model lock. After confirmation, faithfully record the team’s modifications and
, then continue.
2. Generate Candidate Models
Select models based on the data, mechanism, objective, and evaluation criteria rather than forcing models to fit algorithm labels. For model choices that materially affect the score or conclusions, compare at least:
- A simple, interpretable baseline;
- A primary candidate;
- An alternative that differs substantively in assumptions, model family, or solution route.
Do not mechanically assign three model names to every minor subproblem. If only one approach is reasonable, explain the specific grounds for excluding the other routes.
For each candidate, record: the reason it applies, mathematical definition, assumptions, inputs and outputs, constraints, advantages and disadvantages, interpretability, computational cost, main failure risks, and compatibility with subsequent questions. An algorithm name is not itself an innovation. For a complex model, explain what additional problem it is expected to solve compared with the baseline.
3. Quick Experiments, Edge Cases, and Independent Review
Validate candidate feasibility through manual calculations, toy data, small-scale exact solutions, or lightweight code. At minimum, cover the following where relevant to the current problem:
- Minimal and maximal inputs, zero values, or empty values;
- Physical limits, units, and orders of magnitude;
- Constraint conflicts, integer conditions, and conservation relationships;
- Prediction leakage, overfitting, and extrapolation boundaries;
- Whether subsequent conditions produce the expected marginal effect.
Perform a reviewer/critic check of the core approach that is separate from the design process. If the environment permits it and the user authorizes an independent review, use an independent reviewer; otherwise, re-examine the work using an independent checklist, but do not present a self-review as an external independent conclusion. The reviewer should only identify changes in problem intent, omitted constraints, unit errors, data leakage, unidentifiable parameters, unnecessary complexity, incorrect tests, and overclaiming, and should not make the final decision on behalf of the team.
Use a traceable comparison table in
MODEL_SELECTION_REPORT.md
:
markdown
| Candidate | Feasibility | Quick Metrics/Objective | Computational Cost | Interpretability | Main Risks |
| --- | --- | --- | --- | --- | --- |
4. Recommendation and CUMCM H2
The Agent may provide an evidence-based recommendation, but in CUMCM 2026 mode it must not automatically turn the recommendation into the “final approach.” In
MODEL_SELECTION_REPORT.md
, write the following separately:
markdown
## AI Recommendation
Recommended approach, rationale, uncertainties, and trade-offs that still require human judgment.
## Team Final Decision
STATUS: WAITING_FOR_HUMAN_MODEL_DECISION
Also update
. Wait until the team explicitly selects, rejects, or modifies the recommendation; then record the final approach, the team’s modifications and rationale, and change the status to
. Do not hand off a “locked approach” to
unless H2 is approved.
5. Complete the Modeling Report
Organize
ANALYSIS_MODELING_REPORT.md
according to the actual subproblems and include at least:
- Overall framework and subproblem dependencies;
- Data processing plan;
- Symbols, variables, and units;
- Assumptions and models confirmed through H1/H2;
- Objective function, complete constraints, inputs, and outputs;
- Solution steps, stopping conditions, complexity, or applicable scale;
- Baseline, edge cases, counterexamples, sensitivity, and result validation plan;
- Code implementation task list.
Formulas must be explicit enough to be implemented directly during the coding phase. End the report with an interface table:
markdown
| Task | Input | Output | Primary Method | Baseline | Validation |
| --- | --- | --- | --- | --- | --- |
AI Usage Logging
In CUMCM 2026 mode, before this phase ends or while awaiting a human approval gate, append a truthful record to
: tool name and available version/model, purpose, main prompting approach, output summary, adopted and non-adopted content, human modifications, and human verification. Mark unknown information as pending manual completion; do not guess or check off verifications the team has not completed.
Quality Gates
- Every conclusion must be traceable to the problem statement, data, experiments, or a human decision.
- Every critical model choice must have either a baseline or sufficient rationale for excluding alternatives.
- Issues raised by the reviewer must have been resolved, downgraded to risks, or explicitly referred for a human decision.
- In CUMCM mode, H1 and H2 must each have a genuine team confirmation record; otherwise, the phase status can only be waiting and must not be marked complete.