From an Open Problem to a Governed Workflow
For MathModelAgent, the decisive design question is what happens between a user pasting a competition problem and receiving a paper. This chapter focuses on the skills-driven path that governs those transitions. Its value is practical: once readers can see what each stage must hand to the next, they can tell whether a modeling run is building evidence or merely accumulating fluent intermediate text.
A mathematical-modeling problem begins in an inconvenient form. It may contain several numbered questions, ambiguous wording, mixed data, physical constraints, and a submission format. None of those elements arrives as a ready-made software interface. The project’s entry skill therefore treats planning as a control surface. It asks for the choices that materially change downstream work, records a plan and checklist, and assigns responsibilities to later stages instead of asking one general-purpose agent to improvise the entire task.
Planning is a control surface, not a formality
The entry point establishes a lifecycle. A problem is not sent directly to a writer. It first becomes a planned sequence: analysis and modeling, executable coding and visualization, conceptual diagrams when needed, paper writing, and verification. Each stage has a declared output and a boundary. This creates a useful condition for inspection: when a later result looks wrong, a reader can ask which transition first lost the necessary information.
The restriction to workflow-changing choices is important. If a preference does not alter a template, a language, a computational path, or another downstream decision, asking for it adds friction without improving control. Conversely, a choice that changes the document engine or the expected structure belongs at the beginning because changing it later can invalidate work already written. The entry skill’s plan and checklist make these consequences visible before long model conversations consume time or tokens.
The plan also establishes ownership. Analysis is responsible for interpreting the problem and designing a model. Coding is responsible for implementing the model, running experiments, checking constraints, and preserving results. Diagram work is responsible for non-data explanations of structure and process. Writing is responsible for turning the evidence into a contest-appropriate document. Verification is responsible for detecting structural, numerical, and presentation failures. This is not bureaucracy for its own sake. It is a way to prevent a stage from quietly taking credit for work that another stage never performed.
A lifecycle becomes useful only when something persists across its transitions. In MathModelAgent’s skills contract, the planning record persists the intended route; later reports, code, figures, and paper sections become the working artifacts. What should not persist as authority is an unsupported assumption hidden in a conversational exchange. A stage can inherit a previous result, but it must inherit it in a form that makes its meaning and limits clear.
This persistence also creates a way to assign responsibility when the final paper is disappointing. If the question was split incorrectly, the problem lies before model selection. If the model report omits a boundary or a measurable target, the coder cannot be expected to recover the full intent from context. If the computation produces a number but not the parameters or checks behind it, the writer has no safe basis for a precise conclusion. If all of those artifacts are present but the compiled paper drops a figure or changes a value, the failure belongs to the publication transition. A staged workflow does not prevent error; it narrows the search for where meaning was lost.
The sequence is also a sequence of commitments. The analysis stage commits to an interpretation of the problem. The coding stage commits to an executable reading of that interpretation. The visualization stage commits to a particular way of making results visible. The writing stage commits to a reader-facing claim. Verification asks whether each commitment is still recognizable in the final artifact. This is why the skills layer’s stage boundaries matter more than a simple checklist of tasks: they define when a decision becomes an input to someone else’s work.
There is a practical trade-off. More explicit artifacts require more time and more discipline than passing a conversation from one model to another. They can feel slower at the beginning, especially when the problem seems easy. Their value appears when the task is ambiguous, when a solver fails, when a result needs revision, or when another person must review the work later. At those moments, a report or notebook can be inspected and corrected; an undocumented conversational assumption may be impossible to reconstruct.
The workflow is not strictly one-way, either. The analysis rules allow later-question behavior to expose a bad earlier interpretation. The coding stage can reveal that a proposed method is infeasible or that an input does not support the intended calculation. Verification can reveal a numerical or structural mismatch that requires returning to an earlier artifact. Governance therefore means making backtracking legible, not pretending that a modeling problem can be solved in a single pass.
Analysis decides what code is allowed to mean
The analysis stage is where an unstructured prompt becomes a modeling problem. It requires the top-level questions to be identified, rather than treating every sub-clause or data note as a separate problem. It asks for inputs, outputs, variables or prediction targets, objectives or evaluation measures, constraints, dependencies among questions, and planned tables or figures. That list is not valuable because it is long. It is valuable because each item determines what a later computation would count as a valid answer.
The stage also requires an assumption and ambiguity pre-check. When a phrase can support more than one interpretation, the analyst is expected to state the alternatives and use logic, quick checks, or the progression of later questions to choose an interpretation. This protects the rest of the pipeline from a common failure: writing an elegant solution to the wrong problem. If a later question adds a resource, a constraint, or a new scenario but the chosen interpretation makes that addition irrelevant, the earlier assumption must be reconsidered.
The resulting model description is meant to be executable. It should define variables and symbols, state objectives and constraints, describe the solving method, specify inputs and outputs, identify implementation points, and explain how results will be checked. That requirement changes the relationship between modeler and coder. The coder is not being asked to guess what a vague mathematical idea might mean. The coder receives an interface, even if the interface is expressed in a report rather than an API schema.
This is also where the repository’s modeling guidance resists algorithm shopping. The modeler prompt classifies questions as prediction, evaluation, classification, optimization, statistical analysis, text analysis, or simulation, then ties each category to candidate methods and validation strategies. It explicitly emphasizes physical bounds for optimization variables and warns that an unconstrained mathematical optimum may be physically impossible. The deeper principle is model fit: complexity is justified by the problem’s structure, not by the prestige of the algorithm’s name.
The boundary is worth stating. A detailed analysis report is a strong contract for the next stage, but it is not proof that the chosen model is correct. It remains a prompt and a human-readable design. A model can still misunderstand a variable, omit a constraint, or select a method that fits the data poorly. The workflow makes those mistakes easier to locate; it does not make them impossible.
Coding turns a proposed model into evidence
The coding and visualization stage changes the status of the work. It is no longer enough to say what a model should do. The stage must read the required data, implement the method, verify constraints, produce core results, generate figures that answer clear questions, and record the method, key numbers, checks, and reproducible run instructions. The result report is therefore more than a summary for the writer. It is the evidence ledger that later prose is supposed to use.
This requirement is especially important for different problem families. An optimization problem needs a feasible solution before it needs a better objective value. A prediction problem needs a training and validation design or another credible error assessment. An evaluation problem needs consistent indicator direction, normalization, and a defensible source for weights. The same code pattern cannot safely serve all three. By making these distinctions explicit, the stage turns “run the model” into a set of conditions that can be examined.
The project’s norms also treat intermediate data as part of reproducibility. Cleaned-data summaries, model parameters, iteration history, constraint checks, sensitivity calculations, chart data, and run logs should be retained where possible. This matters because a final number is often not enough to diagnose a disagreement. If a chart looks surprising, a reader needs to know whether the surprise came from the input, a transformation, a parameter, a solver, or a plotting choice.
The coding prompt reinforces this evidence role with practical rules. It distinguishes genuine data sets from physical problems whose inputs are fixed constants. It warns against data leakage in time-series features and against fitting preprocessing steps on the test set. It requires parameter sources and asks code to print the data characteristics of generated figures because a later writer may not be able to see the image directly. These are mundane controls, but they address a real interface problem: the Writer receives a textual description of computation and may otherwise fill gaps with plausible-sounding interpretation.
The same stage also defines a boundary around failure. A program that completes is evidence that the supplied code executed under the supplied environment. It is not, by itself, evidence that the target was defined properly or that every constraint was enforced. The skill’s insistence on explicit checks is therefore more important than the mere presence of a code interpreter. Execution becomes useful when it produces records that another person can inspect.
Visuals and documents are separate evidence channels
MathModelAgent’s workflow distinguishes data-driven figures from non-data diagrams. A trend line, error distribution, ranking chart, or sensitivity curve is meant to communicate something computed from data or model runs. A technical roadmap, data pipeline, model structure, or solving flow explains relationships among stages or concepts. The distinction prevents a conceptual picture from being mistaken for empirical support and prevents a chart from being forced to carry architectural meaning it cannot express.
The DrawIO stage makes this boundary operational. It asks for an editable source, a PDF export when the environment supports it, a reason when a diagram is omitted, and checks for overlap, unclear arrows, inconsistent styles, and duplication of data plots. The figure-template skill follows a related principle by supplying reproducible recipes and multiple export formats while warning that bundled simulated data must not be presented as reproducing a source study exactly. Reuse is valuable, but reuse does not transfer evidentiary authority.
The writing stage then places those channels into a contest-specific document. Its Typst and LaTeX contracts require real references, direct figure insertion, and numerical conclusions that come from result records or generated figures. That requirement is a safeguard against a familiar late-stage failure: the writer remembers the shape of a result but changes its value, rounding, or interpretation while turning notes into prose.
Verification adds a final transition. The writing check can identify missing included files, wrong section order, placeholders, leaked internal workflow terms, broken image paths, missing captions, and some signs that result metrics or citation markers are absent. The broader acceptance guidance also expects compilation and visual inspection of the PDF. These checks catch problems that are easy to overlook when attention is focused on the model itself.
They do not all answer the same question. A structural gate asks whether the document is assembled correctly. A numerical consistency check asks whether selected claims agree with recorded results. A visual check asks whether the compiled artifact is legible. A mathematical review asks whether the assumptions, equations, constraints, and interpretation make sense. The workflow becomes more credible when these layers remain distinct instead of allowing a successful compilation to stand in for scientific validation.
The governed path can be summarized as follows:
The transition from one box to the next is not automatic evidence of success. It is a place where information can be lost or transformed. If the analysis report does not define a constraint, the coder cannot reliably check it. If the result record does not preserve a parameter source, the writer cannot honestly explain the number. If the diagram does not distinguish a proposed flow from an observed result, the reader may infer more than the project established.
MathModelAgent’s skills layer is therefore best understood as a governance attempt: it tells each stage what must be made explicit before the next stage can rely on it. That attempt is valuable even where implementation remains incomplete, because it gives users a standard against which to inspect the actual run. But stage order alone does not supply substantive judgment. The next question is how a modeling system should decide what its assumptions and models mean before execution begins.