## 4 Automatic Constraint Model Generator (ACMG)
### ACMG Architecture  
The overall system architecture is shown in Figure 10. The main components of the Automatic Constraint Model Generator engine are as follows:  
Orchestrator (OR): The OR is responsible for controlling the flow from the user's input to the given output. The OR fetches relevant control prompts from the Memory Controller and invokes different components depending on which stage of the process it is in. This module orchestrates the generation of semantic entities, the MiniZinc model, model evaluation, regeneration, and solving. Memory Controller (MC): The MC consists of a model database and a table of help prompts. The model database consists of unique models that can be fetched by a unique identifier, the model's name. The table of help prompts has the following prompts: prompt for assessing user message content; prompt for extracting the constraint task and the model; prompt for classifying the model; prompt for naming the model; prompt for extracting relevant semantic entities; prompt for generating the MiniZinc model; prompt for checking if the generated model validated using MiniZinc is OK or has warnings and/or errors; prompt for transforming warnings and errors into an acceptable format for model and constraint task regeneration; and a prompt for assigning values from the constraint task given in natural language to the model variables that can be solved using the MiniZinc solver (all of these prompts are provided in [46]). Parser (P): The Parser is responsible for separating the model and the constraint task from the input/user message. The Parser is a fine-tuned, pre-trained foundational LLM. We prepared high-quality data with manual annotations to train the Recognizer [19]. MiniZinc solver (MCS): The MiniZinc solver has a Python interface called the MiniZinc Python API. This lets the ACMG interact directly with MiniZinc models and solvers from Python code. MiniZinc is used to model problems with constraints and aims to find solutions that satisfy them. A typical MiniZinc model consists of decision variables representing the unknown quantities in the problem to be solved, constraints that restrict the possible values for the decision variables, and an objective function (optional) that evaluates the quality of each solution. An objective function is applied when a user is attempting to minimize or maximize a variable (e.g., minimize cost, maximize profit). However, as we are interested in constraint satisfaction problems and not constraint optimization, we did not use an objective function; instead, we used parameters to narrow down configurations, i.e., the instantiation of a CSP. MiniZinc is solver-agnostic, meaning it can work with various back-end solvers (such as Gecode, CPLEX, CBC, etc.). The user can choose the solver  
Figure 10: Architecture overview of the Automatic Constraint Model Generator (ACMG). depending on the type of problem and the efficiency required (e.g., for CSP, Gecode [47; 48; 49] or OR-Tools [50] are best suited). Recognizer (R): The Recognizer is responsible for extracting semantic entities from the user message using a control prompt written for this task [46]. The authors of study [17] use the NER method [38] as a specialized framework trained for entity tagging in an optimization context. This can be applied to linear programming and constraint optimization problems, not constraint satisfaction problems. We fine-tuned and instruction-tuned a pre-trained foundational LLM. We prepared high-quality data with manual annotations to train the Recognizer [19]. Figure 9 (top left box) shows the relevant semantic entities extracted, i.e., the decision variables, domains of those variables, and constraints between decision variables. Generator (G): The Generator is responsible for generating MiniZinc code based on the output from the Recognizer and the model described in natural language. LLM foundational models have parameter knowledge related to the generation of MiniZinc models.