{"id":"8cdf5dd2-a311-4656-9c26-47f2b86a367f","arxiv_id":"2608.09659","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A new DSL lets users encode problem-dependent choices between quantum and classical solvers and execute them through the ProvideQ orchestrator.","lead":"This paper introduces a text-based domain-specific language for writing hybrid quantum-classical problem-solving strategies, plus a framework that executes those strategies through the ProvideQ toolbox. It matters because it targets a practical bottleneck: encoding expert decisions about when to use quantum versus classical solvers in a form that can be shared and reused.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"DSL cannot define new problem types or property schemas; its 'wide range of problems' claim is bounded by what ProvideQ already exposes, so the universal-representation claim is under-supported.","rationale":"I took the paper's central deliverable to be a working DSL plus execution framework. The two-instance VRP case study and the open-source repository are genuine evidence that the pipeline executes as claimed for those instances. However, the strongest claim is stated at the level of 'a wide range of problems' and 'universal representation'; the weakest point is not the threshold values themselves but the language's inability to define the problem types on which decisions are based. The reader's weakest assumption about typed instance properties is closely related, and I partially agree; my concern adds that those typed properties are not definable within the DSL, which makes generality depend on an external registry. I therefore do not move the verdict: CONDITIONAL remains appropriate, since the concern is about overclaimed scope rather than a defect in the demonstrated artifact. The Rigoletto novelty issue noted by the reader is real but secondary; it affects the 'first DSL' framing, not the correctness of the artifact.","tokens_in":8980,"tokens_out":5849,"duration_ms":54642,"concrete_test":"Check the repository's Langium grammar (e.g., in meta-solver-strategy-lang) for any user-facing construct that defines problem types or property schemas. Then attempt to write and execute a strategy for a problem family not already in ProvideQ, such as Max-Cut, using only DSL syntax. If the grammar has no type-definition construct, or if adding Max-Cut requires modifying ProvideQ's service or type registry outside the DSL, the 'wide range of problems' claim is not supported by the artifact as described.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that the DSL lets experts encode strategies for 'a wide range of problems' in a universal, technically independent representation. For that to hold, a user must be able to express a strategy for a previously unsupported problem family. The language as specified in Section 3.2 contains only `solve <Type> <instance>`, solver calls, if/else, foreach, and strategy composition; there is no grammar construct for declaring a new problem type or its instance properties. Section 4.1 confirms that problem-type and solver definitions are fetched from the ProvideQ toolbox. Thus every problem family the DSL can address must already be registered in ProvideQ, and the DSL cannot introduce new domains on its own. The case study only exercises VRP, TSP, and QUBO, all pre-existing in ProvideQ, so it does not demonstrate the claimed breadth. The authors' own future-work list (additional execution environments, benchmarking support) also indicates that portability and evaluation across domains are not yet delivered. This is not an internal contradiction, but it makes the 'wide range of problems' claim an extrapolation beyond the presented artifact.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a domain-specific language (DSL) for expressing hybrid quantum-classical meta-solver strategies, together with an editor, an execution framework, and an integration with the ProvideQ toolbox. The DSL uses typed problem instances, solver calls, if-else decisions, foreach loops, and strategy composition to encode expert knowledge about when to use quantum or classical solvers. The authors demonstrate the approach on a VRP case study with two instances, showing that the same strategy takes different solution paths depending on problem dimension. The implementation is claimed to be open source, and the paper positions the contribution as a universal, technology-independent representation for sharing meta-solver strategies.","tokens_in":9156,"tokens_out":4893,"duration_ms":44257,"significance":"If the claims are substantiated, the contribution is useful: it provides a text-based, shareable representation for an important class of hybrid quantum-classical workflows, it abstracts from backend details, and it could enable benchmarking and reuse of expert strategies across problem domains. Strengths of the paper include a concrete implementation built on established components (Langium, ProvideQ, Qiskit, LKH-3), a clear running example, and a narrow execution trace showing that strategies can be interpreted and executed. The main weakness is that the 'wide range of problems' and 'universal representation' claims are not backed by the presented artifact: the language has no mechanism for adding new problem types or property schemas, and the case study covers only VRP/TSP/QUBO, all of which are already registered in ProvideQ. The firstness claim also conflicts with the authors' own citation of Rigoletto. These issues are fixable, but they require substantive revision rather than copy editing.","major_comments":[{"comment":"The language as described in Section 3.2 contains no grammar construct for declaring a new problem type or its instance-property schema; Section 4.1 states that problem-type and solver definitions are fetched from the ProvideQ toolbox. As a result, the DSL can only express strategies for problem families already registered in ProvideQ, and the abstract's claim of supporting 'a wide range of problems' is an extrapolation beyond the presented artifact. The case study exercises only VRP, TSP, and QUBO, all pre-existing in ProvideQ, so it does not demonstrate the claimed breadth. Please either add a language-level extension mechanism and demonstrate it on a previously unsupported problem family, or explicitly scope the claim to problem types exposed by ProvideQ.","section":"§3.2 and §4.1"},{"comment":"No formal grammar or semantics for the DSL is given. Section 4.1 mentions a context-free grammar generated by Langium, but the paper does not include the grammar or a complete specification of the language; therefore a reader cannot determine the exact set of accepted programs, the typing rules for problem instances, or the meaning of nested solve/foreach/if-else constructs. For a DSL paper this is a load-bearing omission. Please include the grammar (or a precise reference to it in the repository with a pinned commit) and define the semantics of strategy composition.","section":"§4.1 and §3.2"},{"comment":"The case-study description is internally inconsistent: the text first introduces 'a constructed VRP with dimension 3 that we call P-n3-k1' and later states that 'P-n3-k1, our constructed problem with a dimension of 2, is executed directly using the Qrisp quantum solver.' The branch outcome is the same for either value, so this does not invalidate the demonstrated path, but it undermines the precision of the only empirical validation. Please correct the dimension and, ideally, report the actual solver outputs or a machine-readable execution trace rather than only the intended path.","section":"§5"},{"comment":"The sentence 'we are the first to pursue a workflow specification and execution mechanism that is based on a Domain-Specific Language' is contradicted by the immediately preceding discussion, which cites Rigoletto [DBB24] as a workflow definition language using a JSON format. Unless the authors can articulate a precise distinction (for example, that Rigoletto is not a full DSL or does not provide execution), the firstness claim should be qualified or removed.","section":"§2.1"}],"minor_comments":[{"comment":"The GitHub repository is identified by URL only; please include a version tag or commit hash and, if possible, a short reproducibility note describing how to re-run the two-instance case study, including any required credentials or configuration for the ProvideQ services.","section":"§4 and §5"},{"comment":"The DSL examples are helpful, but the syntax for comments, string literals, and the exact form of key-value parameters is not specified; a short appendix listing these lexical details would make the language description self-contained.","section":"§3.2"},{"comment":"The figure caption for Figure 4 lists repeated labels such as 'TSP ₁' and 'QUBO ₁' without fully explaining the correspondence between the labels and the subproblems; consider annotating the figure with the actual dimensions of each cluster.","section":"§5"},{"comment":"The distinction between the DSL and the ProvideQ toolbox could be stated more explicitly earlier: the DSL is the notation, while ProvideQ supplies the problem definitions and orchestrates the backends. This would help readers assess the portability claim.","section":"§2.2"}],"recommendation":"major_revision","confidential_remarks":"The paper fits the quantum-software scope of the journal, but the authors should be asked to reconcile the DSL claim with Rigoletto and to provide a grammar or a pinned grammar reference, a corrected and reproducible case study, and a scoped statement of the language's coverage. The current evidence supports only the narrow claim that strategies can be expressed and executed for problem types already present in ProvideQ; the broader 'wide range of problems' claim needs either a demonstration or a clear limitation statement."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a genuine engineering contribution. The authors built a text-based DSL for expressing hybrid quantum-classical solver-selection strategies, with a Langium-based editor and an execution framework on top of their own ProvideQ toolbox. The core claim — that strategies can be written in this language and executed — holds. For the quantum software engineering crowd, that is useful.\n\nWhat is new: a concrete grammar covering solve, if/else, foreach, and strategy composition, plus an editor with syntax highlighting and auto-completion. The running example in Figure 1 is readable, and the two-instance case study (P-n19-k2 and P-n3-k1) shows the strategy routing to different solvers based on dimension thresholds. That is honest evidence that the artifact works as described. Open-sourcing the code is a plus.\n\nThe soft spots, in proportion. The stress-test note is correct: the grammar has no construct for declaring a new problem type or instance-property schema. Problem types and solvers are fetched from ProvideQ. So the DSL can only express strategies over domains that ProvideQ already knows. The case study stays inside VRP, TSP, and QUBO — all pre-existing in the toolbox. That is fine for a scoped claim, but 'wide range of problems' and 'universal representation' overreach. The paper should say 'the range of problem types offered by ProvideQ.'\n\nThe firstness claim also needs a softer edge. Rigoletto is a workflow definition language, albeit JSON-based; the authors' own related work says so. One can argue Rigoletto is not a DSL in the same sense, but that argument is not made. Either engage with Rigoletto directly or drop 'first.'\n\nEvaluation is minimal: two instances, no automated tests, no commit hash, no runtime or solution-quality metrics. The paper explicitly says performance is not the point, which is an acceptable scope for a language paper; but the usability and scalability claims are then plausibility arguments, not results. That is fine as a start, not as a conclusion.\n\nBottom line: the artifact is real, and the load-bearing engineering claim holds. The gaps are in the size of the claims, not in the mechanism. I would send this to peer review — it deserves referee time — but the authors should be asked to narrow the claims, compare directly with Rigoletto, and ideally show more than one problem family.","headline":"A real, working DSL for hybrid meta-solver strategies, but the 'wide range of problems' claim reaches beyond what the language itself can express.","tokens_in":9699,"tokens_out":2174,"would_cite":true,"duration_ms":20657,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A domain-specific language lets experts encode hybrid quantum-classical workflows as portable text with typed problem instances and if-else decisions, and an execution framework runs the strategies through a companion quantum-optimization…","keywords":["domain-specific language","hybrid quantum-classical workflows","meta-solver strategies","quantum candidate identification","solver selection","quantum computing","problem types and instances","vehicle routing problem"],"falsifier":"Take a second problem family, such as Max-Cut, where the right solver choice depends on both graph size and edge density, write a DSL strategy with hand-written thresholds on both properties, and run it over a benchmark spanning those two dimensions. If the DSL cannot express the combined decision, or if the strategy's chosen paths are consistently slower or lower-quality than an always-classical baseline, the claim that the DSL automates sound decisions for a wide range of problems is falsified.","tokens_in":8748,"feed_emoji":"⚛️","tokens_out":12840,"duration_ms":111073,"temperature":0.7,"pith_summary":"The paper sets out to make expert knowledge about when to use quantum versus classical solvers something that can be written down, shared, and executed rather than held in a specialist's head. It proposes a domain-specific language in which a hybrid workflow is a text file: a problem type is declared, a concrete instance is given properties, solver calls look like method calls, and if-else decisions choose among solvers based on instance properties. The language also supports nesting and composition, so a strategy can cluster a large problem, solve subproblems recursively, and reuse existing strategies as subroutines. The authors build an execution framework that interprets these texts through a companion quantum-optimization toolbox, and they demonstrate it on two vehicle-routing instances that follow different solver paths as intended. The case study is framed as a demonstration of execution rather than of solver quality, so the paper's claim is that the language works, not that its example strategy performs better than existing solvers.","feed_headline":"A new language lets experts script when to call a quantum solver","feed_subtitle":"The same portable strategy runs on changing backends; a VRP case study shows different instances take different paths.","key_machinery":"The load-bearing mechanism is the type/instance model combined with mandatory decisions: a strategy text declares problem types, gives each problem instance typed properties, invokes solvers with key-value parameters, and branches on Boolean formulas over instance properties. This makes solver selection a routine step that an execution framework can traverse automatically. The second mechanism is composition: a Meta-Solver Strategy is itself callable as a solver, so hierarchical workflows such as VRP, cluster, TSP, and QUBO are expressed by nesting solve statements and invoking existing strategies as subroutines. The implementation parses the strategy into an abstract syntax tree and dispatches each solver call to the toolbox's service layer.","core_discovery":"The central claim is that a Meta-Solver Strategy—a hybrid workflow that decomposes a problem into subproblems and chooses a solver for each subproblem based on problem characteristics—can be expressed in a compact, technology-independent DSL and executed automatically. The language models problem types and instances with properties, solvers as parameterized calls, mandatory if-else decisions, and strategy composition through nested solve and foreach blocks. The authors substantiate the claim with a vehicle-routing strategy: a three-node instance is sent directly to a quantum solver, while a 19-node instance is clustered into three TSPs, with dimensions 11 and 8 handled by a classical solver and a dimension-2 TSP converted to a QUBO (quadratic unconstrained binary optimization) problem solved by a quantum approximate optimizer. The same strategy text thereby yields different solution paths for different instances, which the paper takes as evidence that the DSL works as intended.","pith_inferences":["A natural next step, not taken in the paper, would be to let the DSL's decision thresholds be learned from measured solver performance rather than written by hand.","The same portable strategy format could serve as a benchmarking substrate, because if execution frameworks automatically recorded runtime and solution quality, strategies written in the DSL could be compared across quantum and classical backends.","The mandatory else branch is a design trade-off worth watching: it guarantees every strategy returns a solution, but it may pressure authors into choosing a classical fallback even when no good fallback is known."],"forward_implications":["Strategy files become portable and durable: the same text can be saved, shared, and re-run when quantum APIs or hardware change, as long as a framework that interprets the DSL exists.","Problem-specific quantum candidate identification can be automated with simple threshold rules, so domain experts' heuristics can be encoded once and reused.","Because strategies compose as solvers, reusable strategy libraries can be built: a validated sub-strategy for one problem type can be embedded in many larger workflows.","Execution is traceable path-by-path, so a strategy's behavior can be checked by observing which solver each instance chose, supporting debugging and verification of hybrid decisions.","The DSL decouples strategy semantics from backend details, meaning the same strategy can later target new classical and quantum backends without modification."],"supporting_citations":[{"why":"It supplies the problem type definitions, solver services, and orchestration layer that the DSL execution framework calls into.","marker":"[Ei25]"},{"why":"It defines the Hybrid Meta-Solving paradigm that the DSL is built to express.","marker":"[Ei24]"},{"why":"It is the JSON-based workflow language the paper contrasts when positioning the DSL as a new specification style.","marker":"[DBB24]"},{"why":"It supplies the empirical finding that DSL programs are easier to comprehend than general-purpose code, motivating the language design.","marker":"[KMC12]"},{"why":"It provides the Qrisp quantum solver used for the small VRP instance and the small TSP clusters in the case study.","marker":"[Se22]"},{"why":"It provides the LKH-3 classical solver used for the larger TSP clusters in the case study.","marker":"[He17]"},{"why":"It defines the quantum approximate optimization algorithm that the QUBO solver applies to small clusters.","marker":"[FGG14]"},{"why":"It supplies the P-n19-k2 VRP instance used to demonstrate the strategy's clustering path.","marker":"[Au95]"},{"why":"It supplies the two-phase clustering approach the example strategy uses to decompose VRP into TSPs.","marker":"[Fe19]"}],"fun_headline_variants":["A DSL for deciding when quantum beats classical","Domain-specific language for hybrid solver strategies","Script which subproblems go to quantum with this DSL","Portable strategies: one script, many solver choices","Meta-solver language automates quantum-classical workflow"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The approach assumes that the problem characteristics relevant to solver choice can be captured by a few typed properties, such as dimension, and by hand-written threshold conditions on those properties, yet the paper only demonstrates this on one problem family, vehicle routing.","fun_headline_variants_meta":{"raw":{"variants":["A DSL for deciding when quantum beats classical","Domain-specific language for hybrid solver strategies","Script which subproblems go to quantum with this DSL","Portable strategies: one script, many solver choices","Meta-solver language automates quantum-classical workflow"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000191,"raw_usage":{"total_tokens":1318,"prompt_tokens":893,"completion_tokens":425,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":509,"completion_tokens_details":{"reasoning_tokens":354}},"tokens_in":509,"tokens_out":425,"duration_ms":4986,"temperature":1.0,"reasoning_tokens":354,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T13:15:22.959745+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a second problem family, such as Max-Cut, where the right solver choice depends on both graph size and edge density, write a DSL strategy with hand-written thresholds on both properties, and run it over a benchmark spanning those two dimensions. If the DSL cannot express the combined decision, or if the strategy's chosen paths are consistently slower or lower-quality than an always-classical baseline, the claim that the DSL automates sound decisions for a wide range of problems is falsified.","supporting_citations":[],"review_version":1}