Problem Classifier

Purpose

Classify each parsed subquestion into standard mathematical modeling problem types.

This skill converts a validated problem parse into a problem-type map. It identifies the core task type of each subquestion, explains the classification reason, lists candidate method families at a high level, and flags common misclassification risks.

This skill does not select the final model, generate code, clean data, or write paper sections.

When to use

Use this skill:

• After problem-parser has produced a validated problem parse.
• Before related-paper-analyzer and method-selector.
• When subquestions need to be mapped to standard mathematical modeling types.
• When a problem appears mixed and the team needs to separate evaluation, prediction, optimization, mechanism, classification, graph, simulation, or hybrid components.
• When the team is tempted to choose a model before clarifying the task type.

Preconditions

A validated problem parse should exist and include:

• subquestions
• goals
• objects
• constraints
• data inventory
• required outputs
• preliminary variables or relationships if available
• ambiguity and risk notes

If the problem parse is missing or incomplete, hand back to problem-parser.

Inputs

Use or request:

• workspace/problem/problem-parser/problem_parse.json, if available.
• Parsed subquestions from problem-parser.
• Goals, objects, constraints, data, and required outputs.
• Preliminary variables, controllable quantities, observable quantities, and relationships.
• Ambiguity and risk flags from the parsing stage.
• User notes about contest constraints or team implementation limits, if relevant.

Workflow

1. Read the parsed subquestions.

• Classify each subquestion separately.
• Do not assign one coarse type to the whole problem unless the problem truly has only one task.

1. Identify the main verb and expected output.

• Evaluation tasks often ask to evaluate, rank, compare, score, classify quality, or assess risk.
• Prediction tasks often ask to forecast, estimate, infer future values, fill unknown trends, or quantify uncertainty.
• Optimization tasks often ask to choose, allocate, schedule, route, maximize, minimize, or design a feasible plan.
• Mechanism tasks often ask to explain system behavior through equations, physical rules, dynamic processes, or causal structure.
• Classification or clustering tasks often ask to group, label, segment, identify categories, or detect abnormal samples.
• Graph or routing tasks often involve nodes, edges, paths, networks, flows, connectivity, matching, or traversal.
• Simulation tasks often require scenario generation, stochastic processes, agent behavior, Monte Carlo trials, or repeated process imitation.
• Hybrid tasks combine multiple task types and should be decomposed by subquestion or modeling layer.

1. Suggest the primary type — but do not finalize the framing.

• Emit the AI's pick as ai_suggested_type with an ai_suggestion_confidence, keeping it clearly the AI's suggestion.
• Use the required output as the main decision criterion and explain the reasoning, so the human has something concrete to ratify.
• Prefer the type that determines how results will be judged.
• The primary problem-type label is load-bearing framing — it steers method-selector. It is the human's call, not the AI's. Leave modeler_chosen_type and framing_rationale as [MODELER INPUT NEEDED: ...] sentinels for the modeler to author. Do NOT pre-fill them by copying ai_suggested_type.

1. Determine the secondary type if needed.

• Add a secondary type only when it materially affects method selection.
• Do not list many secondary types just to be comprehensive.

1. Identify candidate method families.

• List broad method families, not final models.
• Keep candidates tied to the classified task type.
• Mark candidate methods as tentative and subject to method-selector.

1. Flag unsuitable or risky directions.

• Mark methods that appear tempting but are unsupported by data, output requirements, interpretability needs, or contest constraints.
• Flag deep learning, black-box models, or complex heuristics when data volume, explainability, or implementation time is insufficient.

1. Produce a classification artifact.

• Keep the output structured and concise.
• Preserve ambiguity instead of forcing false certainty.
• Save the paired outputs under workspace/problem/problem-classifier/.
• Recommend related-paper-analyzer as the next skill if classification is complete.

Outputs

Produce a problem classification artifact as paired outputs:

• workspace/problem/problem-classifier/problem_classification.json
• workspace/problem/problem-classifier/problem_classification.md

The artifacts should contain:

• classification_summary
• subquestion_classifications
• global_structure
• candidate_method_families
• unsuitable_directions
• classification_risks
• ambiguities
• recommended_next_skill

Output format

Prefer this JSON-compatible structure for workspace/problem/problem-classifier/problem_classification.json:

{
  "classification_summary": {
    "overall_pattern": "hybrid",
    "reason": "The problem combines evaluation, prediction, and optimization across different subquestions."
  },
  "subquestion_classifications": [
    {
      "id": "Q1",
      "ai_suggested_type": "evaluation",
      "ai_suggestion_confidence": "high",
      "modeler_chosen_type": "[MODELER INPUT NEEDED: confirm or override the primary type — the AI suggests 'evaluation']",
      "framing_rationale": "[MODELER INPUT NEEDED: which type, and why this framing over the alternative — e.g. Q2 is evaluation not prediction because the graded output is a ranking, not a future value]",
      "secondary_type": "data_analysis",
      "classification_reason": "The subquestion asks for comparable scores or rankings based on multiple indicators.",
      "output_driver": [
        "ranking",
        "score",
        "comparative explanation"
      ],
      "candidate_method_families": [
        "indicator system construction",
        "weighting methods",
        "multi-criteria evaluation",
        "dimensionality reduction"
      ],
      "unsuitable_directions": [
        {
          "direction": "time series forecasting",
          "reason": "The required output is a ranking or score, not a future value."
        }
      ],
      "risk_flags": [
        "weight source must be justified",
        "positive and negative indicators must be normalized consistently"
      ]
    }
  ],
  "global_structure": {
    "is_hybrid": true,
    "dependency_pattern": [
      {
        "from": "Q1",
        "to": "Q2",
        "reason": "Q2 may use Q1 scores as explanatory variables or inputs."
      }
    ],
    "suggested_workflow_order": [
      "Q1",
      "Q2",
      "Q3"
    ]
  },
  "classification_risks": [
    "Do not force the whole problem into one type if subquestions differ."
  ],
  "ambiguities": [
    "Ambiguity inherited from the problem parse, if any."
  ],
  "recommended_next_skill": "related-paper-analyzer"
}

Also produce workspace/problem/problem-classifier/problem_classification.md with the same fields in readable Markdown form.

B-layer human-confirmation field (load-bearing framing). The primary problem-type label steers method selection, so the AI suggests but the human decides. For every subquestion:

• ai_suggested_type — the AI's pick (the old primary_type). The AI authors this, with ai_suggestion_confidence and a classification_reason.
• modeler_chosen_type — the confirmed primary type. Emit it as [MODELER INPUT NEEDED: confirm or override the primary type — the AI suggests '']. The AI must NOT fill this in.
• framing_rationale — emit as [MODELER INPUT NEEDED: which type, and why this framing over the alternative — e.g. Q2 is evaluation not prediction because…]. The AI must NOT fill this in.

A surviving [MODELER INPUT NEEDED (or [AI-DRAFT) sentinel in a finalized classification artifact is a Gate G1 FAIL — completeness-auditor already treats these sentinels as "not done", exactly like the C-layer >> decision sentinel. The human must replace both sentinels before classification is "ready". Carry ai_suggested_type forward in every example below; never replace it with a finalized primary_type.

Standard problem types

Use these labels consistently:

• evaluation
• prediction
• optimization
• mechanism
• classification-clustering
• graph-routing
• simulation
• data-analysis
• hybrid

Classification guide

Evaluation

Use when the main output is:

• score
• ranking
• comparison
• grade
• risk level
• comprehensive assessment
• priority order

Common cues:

• evaluate
• rank
• compare
• assess
• measure quality
• determine importance
• build an index system

Common risks:

• indicators are not justified
• positive and negative indicators are mixed incorrectly
• weights are arbitrary
• repeated indicators inflate importance
• ranking lacks sensitivity analysis

Candidate method families:

• indicator system construction
• normalization
• weighting
• multi-criteria decision analysis
• dimensionality reduction
• grey relational analysis
• fuzzy evaluation

Prediction

Use when the main output is:

• future value
• unknown value estimate
• trend
• forecast interval
• error or uncertainty description

Common cues:

• predict
• forecast
• estimate
• infer future
• trend
• extrapolate
• fill unknown values

Common risks:

• training fit is mistaken for future generalization
• no test or validation split
• no error metric
• no explanation of failure cases
• long-term extrapolation is overclaimed

Candidate method families:

• regression
• time series analysis
• grey prediction
• machine learning regression
• ensemble prediction
• uncertainty estimation

Optimization

Use when the main output is:

• decision plan
• allocation scheme
• schedule
• route
• maximum or minimum value
• feasible strategy under constraints

Common cues:

• choose
• allocate
• schedule
• assign
• route
• maximize
• minimize
• optimize
• design a plan

Common risks:

• decision variables are not separated from state variables
• objective function is vague
• constraints are incomplete
• feasibility is not checked
• final result gives a number but not an implementable plan

Candidate method families:

• linear programming
• integer programming
• nonlinear programming
• dynamic programming
• multi-objective optimization
• heuristic search
• network optimization

Mechanism

Use when the main output is:

• equation-based explanation
• dynamic process model
• causal structure
• physical or biological mechanism
• interpretable system evolution

Common cues:

• explain mechanism
• describe process
• derive relationship
• simulate dynamics from rules
• model spread, motion, flow, growth, or decay

Common risks:

• assumptions are too strong
• parameters have no source
• units are inconsistent
• model is not validated against data or common sense

Candidate method families:

• differential equations
• difference equations
• compartment models
• conservation laws
• physical constraints
• system dynamics

Classification-clustering

Use when the main output is:

• category label
• group assignment
• segment
• anomaly label
• sample type

Common cues:

• classify
• cluster
• group
• identify category
• segment
• detect abnormal samples

Common risks:

• class labels are unclear
• number of clusters is arbitrary
• feature scaling is ignored
• validation metric is missing

Candidate method families:

• supervised classification
• unsupervised clustering
• anomaly detection
• feature engineering
• dimensionality reduction

Graph-routing

Use when the main output is:

• path
• network structure
• connectivity
• route plan
• matching
• flow allocation
• node importance

Common cues:

• network
• path
• route
• nodes
• edges
• connection
• shortest path
• flow
• matching

Common risks:

• graph abstraction loses important constraints
• edge weights are not justified
• route feasibility is not checked
• static network assumptions hide dynamic constraints

Candidate method families:

• shortest path
• minimum spanning tree
• network flow
• matching
• vehicle routing
• graph centrality
• graph search

Simulation

Use when the main output is:

• scenario result
• stochastic outcome distribution
• repeated trial behavior
• process imitation
• policy comparison under uncertainty

Common cues:

• simulate
• scenario
• random
• probability distribution
• Monte Carlo
• dynamic process
• agent behavior

Common risks:

• random seed is not fixed
• number of trials is insufficient
• simulation assumptions are hidden
• outputs are not statistically summarized

Candidate method families:

• Monte Carlo simulation
• discrete-event simulation
• agent-based simulation
• stochastic process modeling
• scenario analysis

Data-analysis

Use when the main output is:

• descriptive finding
• correlation pattern
• feature relationship
• distribution summary
• data insight before modeling

Common cues:

• analyze data
• describe pattern
• explore relationship
• identify influencing factors
• summarize characteristics

Common risks:

• correlation is overstated as causation
• figures are decorative rather than explanatory
• no connection to later modeling steps

Candidate method families:

• descriptive statistics
• correlation analysis
• hypothesis testing
• exploratory data analysis
• factor analysis

Hybrid

Use when:

• different subquestions require different task types
• one stage produces inputs for another stage
• the solution combines evaluation, prediction, optimization, simulation, or mechanism modeling

Common risks:

• treating the whole problem as one type
• skipping dependencies between subquestions
• using one model to answer all tasks poorly

Candidate method families:

• staged modeling workflow
• modular pipeline
• evaluation-then-prediction
• prediction-then-optimization
• mechanism-plus-data fitting
• simulation-plus-optimization

Rules

• Classify by subquestion, not by the entire problem title.
• Use the required output to determine the primary type.
• The primary problem-type label is load-bearing framing that steers method-selector. The AI suggests it (ai_suggested_type + confidence + reason); the human owns the final framing. Emit modeler_chosen_type and framing_rationale as [MODELER INPUT NEEDED: ...] sentinels and let the modeler author them.
• Do not author, pre-fill, or copy ai_suggested_type into modeler_chosen_type or framing_rationale on the human's behalf.
• A surviving [MODELER INPUT NEEDED or [AI-DRAFT sentinel in the finalized classification artifact is a Gate G1 FAIL — treat it exactly like the C-layer >> sentinel; classification is not "ready" until the human replaces it.
• Do not select the final model.
• Do not generate code.
• Do not write paper text.
• Do not over-list candidate methods.
• Do not recommend complex or black-box methods without data and interpretability support.
• Do not hide classification uncertainty.
• Do not override ambiguities inherited from problem-parser.
• Do not move directly to model-code-analyzer.

Verification

Before handing off, verify:

• Every parsed subquestion has an ai_suggested_type (the AI's suggested primary type) with a confidence and reason.
• Every parsed subquestion still carries the [MODELER INPUT NEEDED: ...] sentinels for modeler_chosen_type and framing_rationale — the AI must not have authored or copied them. A surviving sentinel is a Gate G1 FAIL the human must clear (it confirms the framing has not yet been ratified); the AI hands off with these sentinels intact, not pre-filled.
• Secondary types are used only when necessary.
• Classification reasons refer to task wording, required output, and data conditions.
• Candidate

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: zhnnky329
• Source: zhnnky329/MathModeling-skills
• License: MIT

Install and usage instructions live in the source repository linked above.