LLMxCPG: LLMs Coupled with Structured Systems
- LLMxCPG is a family of hybrid systems that integrate large language models with external structured substrates, enforcing semantics on generation and control.
- They are applied in areas like industrial motion control, constraint propagation in decoding, code vulnerability detection, and formal synthesis for cyber-physical systems.
- The architectures leverage modular pipelines where the LLM proposes candidate solutions and external mechanisms verify correctness, highlighting trade-offs between performance and reliability.
LLMxCPG is a polysemous label in recent arXiv usage for systems that couple LLMs with structured mechanisms that impose external semantics on generation, analysis, or control. In the papers currently associated with the term, the “CPG” component refers variously to control-program generation for industrial motion control, constraint propagation inside constrained decoding, Code Property Graph-guided vulnerability detection, and cyber-physical games with formal verification and synthesis; adjacent work further frames LLM-based planning through model predictive control, while robotics literature preserves the older CPG abbreviation for central pattern generators (Li et al., 2024, Bonlarron et al., 29 May 2025, Lekssays et al., 22 Jul 2025, Kabra et al., 28 Feb 2026, Maher, 5 Jan 2025, Campanaro et al., 2021).
1. Terminological scope and acronymic divergence
Across these papers, no single expansion of “LLMxCPG” is standardized. Instead, the term denotes a family of hybrids in which an LLM is paired with a second substrate that enforces structure the LLM does not natively guarantee.
| Use of “CPG” | Structured substrate | Representative paper |
|---|---|---|
| Control-program generation | Soft-motion controller, private motion API library, simulator, trajectory logs | "MCCoder: Streamlining Motion Control with LLM-Assisted Code Generation and Rigorous Verification" (Li et al., 2024) |
| Constraint propagation | Dynamic CSP, propagators, backtracking, MLM preview | "LLM Meets Constraint Propagation" (Bonlarron et al., 29 May 2025) |
| Code Property Graph-guided | Joern CPG, execution-path extraction, backward slicing | "LLMxCPG: Context-Aware Vulnerability Detection Through Code Property Graph-Guided LLMs" (Lekssays et al., 22 Jul 2025) |
| Cyber-physical games | Differential game logic, KeYmaera X, tactic synthesis | "LLM-Powered Automatic Theorem Proving and Synthesis for Hybrid Systems and Game" (Kabra et al., 28 Feb 2026) |
This multiplicity matters because the technical commitments differ sharply. In one usage, the core problem is translating natural-language automation instructions into Python that correctly invokes a private motion library with more than 1,000 APIs, up to 128 axes, and 256 independent task channels. In another, it is treating constrained generation as a CSP with variables, domains, and constraints. In another, it is reducing large codebases to vulnerability-focused slices before LLM classification. In another, it is automating proof search and synthesis for hybrid systems and games in . A plausible implication is that “LLMxCPG” is best treated as an architectural family rather than a single method.
Acronym collision is further compounded by the older control-theoretic and robotics usage of CPG for central pattern generators. "CPG-ACTOR: Reinforcement Learning for Central Pattern Generators" is not an LLM paper, but it illustrates that CPG already had an established meaning in locomotion and rhythmic control before these newer LLM-centered usages (Campanaro et al., 2021).
2. Control-program generation in industrial motion control
In the motion-control literature, LLMxCPG denotes LLM-based generation of executable controller code for a cyber-physical software stack in which correctness is behavioral and safety-critical rather than merely syntactic. MCCoder takes as input a natural-language motion-control task and generates Python code that invokes APIs from a private motion library used by a soft-motion controller. The target programs may include initialization, movement commands, interpolation, synchronization, I/O operations, waiting, and shutdown or close procedures. The library supports fieldbus communication, digital and analog I/O, position, velocity, and current control, interpolation, compensation, splines, short-segment look-ahead, event-driven axis and I/O interactions, and more (Li et al., 2024).
The pipeline has six named modules: task decomposition, retrieval, code generation, soft-motion, self-correction, and data verification. A user instruction is first decomposed into sub-tasks by an LLM. Each sub-task is then handled by a hybrid retrieval module that searches uniformly formatted API descriptions and expert-created sample codes using BM25, embedding-based dense retrieval, and a reranker with top-. Code generation is hierarchical: the model produces sub-code for each sub-task, then synthesizes a final integrated program from the original instruction and the sub-codes. The generated code is executed through a DLL interface to a PC-based soft-motion controller that includes a real-time engine for actual machines and a simulation engine for testing.
Verification is multi-layered. If simulation returns syntax or API errors, MCCoder enters a self-correction loop driven by controller error messages such as “type object ProfileType has no attribute scurve. Did you mean: SCurve?” If execution succeeds, the controller logs process data every $1$ ms, and a 3D simulator can display machine movement in real time. The result is not only source code but also sub-tasks, retrieved snippets, sub-codes, final code, error reports, time-series log files, plots, and simulator animations.
The benchmark introduced for this setting, MCEVAL, comprises 116 tasks, each with a TaskId, Instruction, CanonicalCode, and Difficulty. Difficulty level 1 changes numerical arguments while keeping API patterns close to sample codes. Difficulty level 2 requires arguments not shown in the samples. Difficulty level 3 combines up to 8 different motion tasks in one instruction. Evaluation uses First Time Pass Rate,
computed as both FTPR(MatchEndPoints) and FTPR(DTW), where the latter compares full trajectories via Dynamic Time Warping. The failure distribution is especially revealing: argument errors dominate at 79%, versus 15.8% syntax errors and 5.2% API errors, indicating that the central challenge is often semantic parameterization rather than API name selection.
Empirically, MCCoder improves performance over naive RAG, but the provided material contains an internal discrepancy. One summary states an overall performance gain of 33.09% and a 131.77% improvement on complex tasks, whereas the detailed results summary reports 11.61% overall and 66.12% on level-3 complex tasks relative to base models with naive RAG. Model-wise results include GPT-4o improving in FTPR(DTW) from 43.97 overall with naive RAG to 69.57 with MCCoder, and DeepSeek-Coder-v2 reaching 75.86 overall FTPR(MatchEndPoints) and 61.21 overall FTPR(DTW). Ablation indicates that prompt engineering is the largest contributor, with removal causing a 20.51% drop in FTPR(DTW) for GPT-4o and 15.79% for GPT-4o-mini; removing task decomposition causes roughly a 13% drop; self-correction contributes around 1–5% and is limited by ambiguous soft-motion error messages (Li et al., 2024).
3. Constraint propagation as a decoding substrate
A second meaning of LLMxCPG is the tight coupling of autoregressive generation with constraint programming. In "LLM Meets Constraint Propagation," constrained text generation is formulated as a CSP
where variables correspond to textual decision points, domains are candidate tokens or token groups, and constraints encode admissible structure. GenCP constructs this CSP dynamically during generation through three generative procedures: GenV for variable creation, GenD for domain generation, and GenC for constraint addition. The solver performs depth-first backtracking search with propagation, while the LLM supplies candidate values and their ordering (Bonlarron et al., 29 May 2025).
The main innovation is MLM-based domain preview. Baseline GenCP is unidirectional because an autoregressive LLM provides domains for using only the prefix . The extension adds a masked LLM to preview candidate domains for a look-ahead window such as , enabling bidirectional propagation. The paper describes this as giving CP approximate future domains so that global constraints can prune current choices earlier. The MLM objective is recalled as
and the resulting preview is used procedurally rather than through a formal probabilistic fusion with autoregressive scores.
The representational bridge between word-level reasoning and tokenized LLMs is the meta-variable. A meta-variable can contain one or several token-level decisions, so a word such as “Using” may be realized as “Us” and “ing.” This avoids the mismatch between word-level CP formulations and subword tokenization. Search remains LLM-guided: candidate domains are typically top- tokens, values are tried in LLM likelihood order, and CP propagators prune infeasible values. The canonical constraint example is exact character-length satisfaction,
0
with propagated bounds such as
1
The experimental setup uses Java 17 on Windows 10, OpenAI’s babbage-002 at temperature 0.8 as the autoregressive LLM, bert-base-cased as the MLM, and solver-centric metrics: number of LLM calls, number of MLM calls, number of backtracks, and number of solutions found. The previewMLM variant with depth 2 is consistently the strongest reported preview configuration. On sent-1, vanilla GenCP required 444 LLM calls, 375 backtracks, and found 3 solutions; the meta-variable version required 456 LLM calls, 211 backtracks, and found 4 solutions; previewMLM reduced LLM calls to 359, added 32 MLM calls, reduced backtracks to 170, and found 10 solutions. On para-4, the meta-variable version found 0 solutions with 466 LLM calls and 447 backtracks, whereas previewMLM found 2 solutions with 422 LLM calls, 12 MLM calls, and 258 backtracks. The paper also reports that deeper preview 3 or 4 worsened performance for equal runtime, with the most useful setting being shallow preview over the last two variables of a sentence (Bonlarron et al., 29 May 2025).
4. Code Property Graph-guided vulnerability detection
The paper explicitly titled "LLMxCPG" defines the acronym as Code Property Graph-guided LLMs for vulnerability detection. Its architecture is two-model and two-phase. LLMxCPG-Q generates Joern CPGQL queries that identify vulnerability-relevant execution paths from a CPG, and LLMxCPG-D classifies the reconstructed slice as VULNERABLE or [SAFE](https://www.emergentmind.com/topics/surrogate-assisted-and-fine-tuning-enhanced-safe). The pipeline parses source code into a CPG with Joern, uses LLMxCPG-Q to generate a query, extracts path nodes, identifies interacting identifiers by line-number overlap, applies backward slicing over the PDG using reachableByFlows, reconstructs a concise code snippet, and feeds that slice to the detector (Lekssays et al., 22 Jul 2025).
A central shift is from criterion-point slicing to execution-path-centered slicing. Instead of anchoring on a single dangerous API call or patch-diff location, the method extracts a candidate vulnerable execution path, expands it with “interacters,” and then performs backward slicing to recover all data and control dependencies needed to understand the path. This is intended to preserve enough semantic context to analyze vulnerabilities that span multiple functions or files while removing irrelevant code. The paper gives a concrete example in which an 85-line function is reduced to an 18-line slice containing the computation of len, the bounds check against ring->rx_buffersize, the loop affecting that logic, and the sink skb_put(skb, len + ring->frameoffset).
The code reduction ratios are central: 78.70% on FormAI, 67.84% on PrimeVul, 70.22% on SVEN, and 90.93% on ReposVul. Query-generation quality is also striking. Out of 1278 test samples, DeepSeek-v3 produced 132 valid queries, Qwen2.5-Coder-32B-Instruct produced 19, and the fine-tuned LLMxCPG-Q produced 1278. A human semantic audit by three security experts over 50 generated queries found that 76% of queries for true positive or true negative samples semantically matched the intended vulnerability pattern and yielded meaningful paths, with Fleiss’ Kappa of 0.6429. Among false positive or false negative samples, 28% of queries were semantically correct but final classification was still wrong, 40% targeted the wrong CWE, and 32% identified the right CWE but missed critical context.
The detection model uses a reduced binary classification head. If 5 is the input slice and 6 the model representation, the vulnerable and safe logits are
7
followed by a softmax and thresholded prediction with dataset-specific 8. The thresholds reported after sampling 20 validation points are 9 for PrimeVul, $1$0 for FormAI, $1$1 for SVEN, and $1$2 for ReposVul. On SVEN, LLMxCPG achieves Accuracy 0.6020, Precision 0.5590, Recall 0.9534, and F1 0.7048, outperforming VulSim, ReGVD, VulBERTA-CNN, and VulBERTA-MLP. On ReposVul, it reports Accuracy 0.634, Precision 0.542, Recall 0.700, and F1 0.610, despite not being trained on project-level real-world data. The appendix ablation that removes slicing and feeds full code directly to LLMxCPG-D shows substantial degradation: FormAI accuracy drops from 0.8146 to 0.6762, PrimeVul from 0.7250 to 0.4875, and SVEN from 0.6020 to 0.5078. Robustness testing under semantics-preserving transformations further shows that comment removal has no effect, while moving function code into a separate function tends to be the most disruptive transformation (Lekssays et al., 22 Jul 2025).
5. Cyber-physical games, theorem proving, and controller synthesis
A more formally grounded interpretation of LLMxCPG appears in work on hybrid systems and games, where the “CPG” component is cyber-physical games and controller synthesis. "LLM-Powered Automatic Theorem Proving and Synthesis for Hybrid Systems and Game" uses LLMs to automate reasoning in differential game logic for CPS with discrete control, continuous nonlinear dynamics, symbolic parameters, unbounded time horizons, and adversarial nondeterminism. The key modal formula is $1$3, meaning that Angel has a strategy in game $1$4 to achieve $1$5 regardless of how Demon plays. The formal substrate includes deterministic assignment, angelic and demonic choice, repetition, ODE evolution, and duality, all checked by KeYmaera X rather than by the LLM itself (Kabra et al., 28 Feb 2026).
The verification architecture has three stages: analyze game, propose tactic, and summarize or reflect. The LLM, specifically OpenAI GPT-5 in all experiments, proposes Bellerophon tactics, loop invariants, differential cuts, existential witnesses, and high-level proof decompositions. KeYmaera X checks each proposal, and failures are fed back into a summarization stage that condenses the proof state and likely next steps. This summarization mechanism is not an incidental engineering detail: traditional proof automation solves 0/5 case studies, an agent with full history solves 2/5, and the summarization-based agent solves 5/5. Verification succeeds on all five case studies—Lotka–Volterra population control, train control with air brakes, chemical reaction control, coolant control, and coupled Van der Pol oscillators—while synthesis succeeds on four of the five.
The paper is explicit that soundness comes from formal checking, not from the LLM. For verification, candidate tactics are checked against the $1$6 calculus by KeYmaera X, with arithmetic obligations discharged by Z3 where appropriate. For synthesis, the LLM guesses subvalue map entries that constrain Angel’s legal choices so that subsequent subgames begin in states satisfying required formulas; these guesses are retrospectively checked by Z3 and KeYmaera X. The synthesis table reports that previous work solves 0/5 case studies, an ablation without recovery and LLM-assisted proving solves 2/5, and the full pipeline solves 4/5. The success criteria are explicit: proof within eight runs and total LLM budget of \$1$710 total LLM budget for synthesis (Kabra et al., 28 Feb 2026).
This line of work is formally richer than the other senses of LLMxCPG because it treats the LLM as a heuristic search layer over a proof calculus rather than as the final decision-maker. It is therefore the clearest instance in which symbolic guarantees survive the inclusion of an LLM: accepted proofs and checked synthesized envelopes are sound by inheritance from the trusted theorem-proving infrastructure.
6. Shared design patterns, adjacent frameworks, and persistent limitations
Taken together, these papers converge on a common systems pattern: the LLM is a proposal mechanism, while a non-neural substrate enforces feasibility. In motion control that substrate is the soft-motion controller, simulator, and $1$8 ms trajectory logs. In constrained decoding it is CP propagation and backtracking over explicit domains. In vulnerability detection it is Joern-based path extraction and backward slicing. In hybrid games it is $1$9, Bellerophon, KeYmaera X, and Z3. A plausible implication is that the central technical move in LLMxCPG is not merely “using an LLM,” but relocating correctness checks into an external execution, graph, solver, or proof environment.
This pattern is made explicit by LLMPC, which reframes prompted planning as approximate model predictive control. There the LLM is a proposal model for candidate action sequences, an external transition model $FTPR = \frac{NPassed}{NTotal} * 100,$0 simulates resulting trajectories, and an explicit cost function $FTPR = \frac{NPassed}{NTotal} * 100,$1 selects the best plan through
$FTPR = \frac{NPassed}{NTotal} * 100,$2
The paper’s decomposition $FTPR = \frac{NPassed}{NTotal} * 100,$3, $FTPR = \frac{NPassed}{NTotal} * 100,$4, and $FTPR = \frac{NPassed}{NTotal} * 100,$5 formalizes prompt construction, LLM generation, and text-to-action mapping, and it argues that systems such as ReAct and Tree-of-Thoughts can be interpreted through this MPC lens. This suggests a unifying control-theoretic reading for several LLMxCPG instantiations: the LLM proposes, an explicit model evaluates, and the system replans or repairs under receding horizon (Maher, 5 Jan 2025).
A related methodological thread appears in CGPO, which is not a CPG paper but is relevant to the refinement of LLM-guided code and reasoning systems. CGPO identifies the model’s lowest-confidence point,
$FTPR = \frac{NPassed}{NTotal} * 100,$6
branches locally from that point using top-$FTPR = \frac{NPassed}{NTotal} * 100,$7 candidate tokens, ranks branches with a fine-grained reward model, and trains with a DPO-like objective. On code generation, it reports absolute gains from 19.3 to 19.7 on LiveCodeBench and from 12.7 to 13.2 on the LeetCodeDataset test set. The paper’s pilot study further reports that in approximately 75% of analyzed incorrect cases, the first erroneous step occurs after the lowest-confidence point. A plausible implication is that uncertainty-triggered intervention could be transplanted into graph-guided or controller-guided LLMxCPG pipelines, although the paper itself stays in plain token sequences and does not use ASTs, CFGs, DFGs, or CPGs (Lu et al., 13 Oct 2025).
The older locomotion literature also remains relevant because it preserves a distinct meaning of CPG. In "CPG-ACTOR," a central pattern generator becomes the actor in an actor-critic RL pipeline, with an MLP injecting nonlinear sensory feedback into Hopf oscillator dynamics. The result on a single-leg hopper is roughly 6x more reward after 20 million timesteps compared with previous approaches. This does not instantiate LLMxCPG, but it shows that “CPG” already names a structured dynamical substrate with interpretable latent state, known recurrence, and tight coupling to control, which helps explain why the acronym now attracts multiple LLM-centered reinterpretations (Campanaro et al., 2021).
Across all senses of the term, several limitations recur. MCCoder remains empirical and human-supervised rather than formally safe, with ambiguous error messages weakening self-correction. GenCP improves feasibility under strict hard constraints but depends on the quality of neural domain proposals and shallow preview works better than deep preview. LLMxCPG for vulnerability detection is limited to vulnerability classes that static CPG analysis models well and degrades on very high nesting depth. The hybrid-games framework is sound once checked, but it is heuristic, incomplete, and sensitive to prompt and context management. The recurring misconception is therefore that LLMxCPG denotes autonomous end-to-end reasoning. In the literature surveyed here, it more often denotes a checked, sliced, propagated, simulated, or formally verified workflow in which the LLM remains only one component of a larger semantics-preserving stack.