C2|Q>: Classical-to-Quantum Framework

• C2|Q> is a modular, hardware-agnostic quantum software development framework that automatically translates classical problem specifications into quantum programs.
• It uses an encoder–deployment–decoder architecture, leveraging both a CodeBERT-based Python parser and schema-driven JSON inputs to match problem types and select quantum algorithms.
• Empirical evaluations demonstrate high parser accuracy (98.85%), increased efficiency with up to 40× code reduction, and robust backend recommendations for NISQ devices.

C2$|Q\rangle$—also rendered as $\mathrm{C2}\ket{\mathrm{Q}}$ and described as “Classical-to-Quantum”—is a modular, hardware-agnostic quantum software development framework intended to translate classical problem specifications into executable quantum programs and then decode quantum outputs back into classical, human-readable solutions. Its stated purpose is to reduce the expertise barrier in quantum software development by automating several steps that otherwise require specialized knowledge: problem encoding, algorithm selection, circuit construction, backend selection, transpilation, execution, and output interpretation. The framework accepts either classical Python code snippets or structured JSON specifications, supports ten problem families, and is accompanied by both a main research paper and a reproducibility-oriented Replicated Computational Results report (Ye et al., 3 Oct 2025, Ye et al., 5 Apr 2026).

1. Definition, motivation, and research context

C2$|Q\rangle$ is situated in Quantum Software Engineering (QSE) rather than in the design of a single quantum algorithm. Its central claim is that current quantum development environments still expose too much of the low-level stack to classical software engineers: a developer must typically identify a quantum-suitable formulation, encode the problem, choose and configure an algorithm, construct circuits, target specific hardware, and interpret raw measurement outcomes. C2$|Q\rangle$ addresses that gap by introducing an automated translation and deployment layer between a classical problem description and a quantum execution environment (Ye et al., 3 Oct 2025).

The framework is explicitly organized around three research questions. RQ1 asks how classical code snippets can be analysed and transformed into Quantum-Compatible Formats (QCFs), and how suitable quantum algorithms can then be selected and configured. RQ2 asks how quantum hardware can be automatically recommended and deployed while hiding platform-specific complexity. RQ3 asks how effective and generalizable the complete framework is. These research questions map directly onto three experiments: encoder evaluation, hardware-recommender evaluation, and end-to-end workflow validation (Ye et al., 5 Apr 2026).

A further distinction is necessary between the two associated papers. The main paper presents the framework’s architectural and empirical claims, including completion rates, hardware-recommendation results, and implementation-effort comparisons. The RCR report is narrower: it documents the released artifact, setup process, execution routes, expected outputs, and reproducibility status. This distinction matters because several core scientific results are reported in the main paper, whereas the RCR report focuses on what can be independently regenerated and how.

2. Architectural organization and execution pipeline

The framework follows an encoder–deployment–decoder architecture. At the highest level, it begins from a classical specification, constructs an intermediate representation, generates and transpiles circuits, recommends a backend, executes the selected quantum program, and decodes the result. In the formal notation of the main paper, the parser maps an input specification $C$ to a problem type and structured data,

$$\text{Parser:} \quad C \mapsto (\mathcal{P}, \mathcal{D}),$$

which is then converted into a QCF,

$$Q = \langle \mathcal{T}, \mathcal{D}, \epsilon \rangle,$$

where $\mathcal{T}$ is the task tag, $\mathcal{D}$ is the extracted data, and $\epsilon$ is the encoding type. The generator and recommender are then expressed as

$\mathrm{C2}\ket{\mathrm{Q}}$0

$\mathrm{C2}\ket{\mathrm{Q}}$1

followed by execution and decoding (Ye et al., 3 Oct 2025).

The encoder is responsible for understanding the classical specification. For Python inputs, this path is model-backed: the system uses a pretrained CodeBERT-based parser for classification and data extraction. For JSON inputs, the route is schema-based and model-free. This distinction is operationally important. Python-input runs require a separately distributed pretrained parser model, whereas JSON specifications bypass machine learning entirely and constitute the simplest reproducibility path (Ye et al., 5 Apr 2026).

The deployment module performs the quantum-side operational work. It constructs circuits, transpiles them, evaluates candidate backend–circuit pairs, and executes the selected program. The decoder then maps backend outputs—bitstrings or distributions—into domain-specific classical solutions. For optimization problems this includes candidate-assignment interpretation and feasibility checks; for oracle-based search it includes marked-state selection; for arithmetic it includes direct register interpretation; and for factorization it includes the classical post-processing associated with Shor-style outputs (Ye et al., 3 Oct 2025).

This modularization has two consequences. First, the framework is not monolithic: encoder, deployment, and decoder can be validated independently. Second, “hardware-agnostic” does not mean hardware-independent; rather, it means that hardware-specific decisions are deferred to the deployment stage instead of being embedded in the classical-to-quantum translation itself.

3. Inputs, QCFs, supported problem families, and algorithm mappings

C2$\mathrm{C2}\ket{\mathrm{Q}}$2 supports two principal input forms: Python code snippets and structured JSON specifications. The JSON route is deterministic and model-free; the Python route uses the pretrained parser to infer the problem family and extract structured data. The RCR report gives a minimal MIS JSON example with fields such as "family": "MIS", "goal": "find a maximum independent set of the graph", and an "instance" object containing an edge-list graph representation, illustrating the intended schema-driven workflow (Ye et al., 5 Apr 2026).

The supported domain is limited but explicitly enumerated. The framework currently covers ten problem families: six combinatorial optimization problems—MaxCut, MIS, TSP, Clique, K-Coloring, and Vertex Cover—plus integer factorization and three arithmetic operations: addition, subtraction, and multiplication. These families are the range over which the encoder classifies, the QCF translator encodes, and the generator knows how to produce executable quantum programs (Ye et al., 3 Oct 2025).

QCFs are the central abstraction that separates classical specification syntax from downstream quantum realization. The main paper defines the encoding type set as

$\mathrm{C2}\ket{\mathrm{Q}}$3

For combinatorial optimization, QUBO is the principal representation, with objective

$\mathrm{C2}\ket{\mathrm{Q}}$4

which is then mapped to an Ising Hamiltonian and finally to a quantum cost Hamiltonian. For oracle-based tasks, the oracle acts as

$\mathrm{C2}\ket{\mathrm{Q}}$5

For arithmetic, the semantics are stated directly as register transformations: $\mathrm{C2}\ket{\mathrm{Q}}$6

$\mathrm{C2}\ket{\mathrm{Q}}$7

$\mathrm{C2}\ket{\mathrm{Q}}$8

The generator maps these QCFs to algorithm families including QAOA, VQE, Grover, QFT-based arithmetic, reversible arithmetic circuits, and Shor’s algorithm (Ye et al., 3 Oct 2025).

A representative example is MIS. The main paper states that MIS may be expressed either as an oracle encoding or as a QUBO,

$\mathrm{C2}\ket{\mathrm{Q}}$9

with $|Q\rangle$0, specifically $|Q\rangle$1 and $|Q\rangle$2. In this formulation $|Q\rangle$3 penalizes adjacent selected vertices and $|Q\rangle$4 rewards larger independent sets. This suggests that QCF functions not merely as an interchange format, but as the locus at which classical problem semantics are bound to quantum-compatible optimization or oracle structures.

4. Deployment logic, backend abstraction, and hardware recommendation

The deployment layer is where C2$|Q\rangle$5 realizes its hardware-agnostic claim. The main paper states support for devices from Azure Quantum, IBM Quantum, and Amazon Braket, with concrete provider references including IBM, IonQ, IQM, Rigetti, and Quantinuum. The RCR report further notes simulator execution using Qiskit Aer and real-hardware validation on IBM Brisbane and Finland’s Helmi (Ye et al., 3 Oct 2025, Ye et al., 5 Apr 2026).

Backend recommendation is scoring-based rather than learned. Candidate device–circuit pairs are first filtered by a feasibility threshold $|Q\rangle$6, interpreted as an estimated minimum fidelity requirement. Total circuit error is approximated by

$|Q\rangle$7

with fidelity defined as $|Q\rangle$8. Execution time is estimated as

$|Q\rangle$9

and the final score uses normalized error, time, and cost with default weights $|Q\rangle$0, $|Q\rangle$1, and $|Q\rangle$2. Under fidelity-dominant settings or for workloads requiring more than 10 qubits, the score includes a small trapped-ion preference term $|Q\rangle$3 (Ye et al., 3 Oct 2025).

Experiment 2 isolates this deployment layer by running MaxCut QAOA circuits on 3-regular graphs across nine quantum devices from five providers. The reported quantities include estimated error rates, execution times, and costs as functions of qubit count up to 56 qubits, along with the device selected under default and varied weights. Under default weights, the RCR report states that the passing indicator is a winners.csv file selecting Quantinuum H1/H2, and the main paper states that feasible recommendations extend from H1 at smaller sizes to H2 for 22–56 qubits, with no feasible device beyond 56 qubits (Ye et al., 5 Apr 2026, Ye et al., 3 Oct 2025).

The framework therefore treats backend choice as a multi-objective deployment problem rather than a fixed target. This suggests that its principal hardware abstraction lies not in a universal circuit IR alone, but in the explicit separation between problem translation and backend optimization.

5. Empirical evaluation, artifact structure, and reproducibility

The empirical evaluation is organized into three experiments. The main paper reports parser evaluation loss $|Q\rangle$4, evaluation accuracy $|Q\rangle$5, weighted-average F1 $|Q\rangle$6 on the Python dataset, encoder completion $|Q\rangle$7 on 434 Python programs, and full-workflow completion rates of $|Q\rangle$8 for those Python inputs and $|Q\rangle$9 for 100 JSON inputs. It further states that the hardware recommendation module selected suitable devices for workloads scaling up to 56 qubits, and that in an MIS case study the framework reduced handwritten implementation effort from 120–150 lines of code in manual Qiskit to 3–5 lines, described as nearly $C$0 (Ye et al., 3 Oct 2025).

The RCR report organizes the corresponding reproducibility claims more cautiously. It states that Experiment 1 is available through inspection and partial validation rather than a one-command retraining workflow; Experiment 2 is fully executable; and Experiment 3 is fully executable on simulators, whereas the real-hardware portion is access-dependent and documented through archived outputs rather than independently repeatable execution (Ye et al., 5 Apr 2026).

Experiment	Focus	Reproducibility mode
1	Encoder evaluation for RQ1	Inspection / partial validation
2	Deployment and hardware recommendation for RQ2	Fully executable
3	Full workflow validation for RQ3	Fully executable (simulator); real-hardware not independently replicable

The artifact channels are correspondingly differentiated. GitHub is the primary executable artifact and supports source checkout, notebooks, tests, and make targets. The parser model is archived separately on Zenodo and mirrored on GitHub release and Hugging Face. Evaluation data and archived outputs are preserved on Zenodo, and a lightweight PyPI package, c2q-framework, supports CLI/API use but is explicitly not the route for reproducing the paper’s make-based experiments. The report also specifies that the framework and model are under Apache-2.0, while the evaluation data are under CC-BY-4.0 (Ye et al., 5 Apr 2026).

Reproducibility details are unusually concrete. The source-checkout route requires Python 3.12; Python 3.13 and newer are unsupported. make doctor validates Python, pdflatex, and the parser model. make smoke writes artifacts/smoke/summary.json, whose expected content is a MaxCut instance with a $C$1 QUBO matrix and a 4-qubit QAOA circuit. Model-free reproduction routes include make reproduce-json-smoke, make reproduce-json-paper, and make recommender-maxcut; model-dependent routes include make reproduce-smoke, make reproduce-paper, and make validate-dataset. On the reference Apple M1 Max machine, make reproduce-paper takes approximately ten hours and make reproduce-json-paper around two hours (Ye et al., 5 Apr 2026).

6. Scope, limitations, and significance within QSE

The framework’s scope is deliberately bounded. It supports ten problem families, not arbitrary classical programs, and its empirical real-device runs are limited to small- and medium-sized instances consistent with current NISQ capabilities. The main paper also notes fixed default algorithm parameters, such as standard QAOA and VQE defaults, which means that automation should not be conflated with instance-optimal tuning. The parser is Python-focused, partly rule-based, and trained on synthetic code; the paper states that it may be brittle on dynamic constructs, helper functions, object wrappers, file I/O, or unconventional code styles (Ye et al., 3 Oct 2025).

The RCR report adds narrower reproducibility limitations. Experiment 1 is not fully packaged for one-step regeneration; the parser model must be installed separately; and real-hardware validation depends on access to devices such as IBM Brisbane and Helmi. The report also notes that the PyPI package is model-free out of the box only for JSON-based workflows, is Python 3.12 only, and does not support the make-based paper reproduction workflow (Ye et al., 5 Apr 2026).

Two common misconceptions are explicitly addressed by the papers’ structure. First, C2$C$2 is not a new quantum algorithm; it is a workflow framework that orchestrates classification, encoding, algorithm selection, deployment, and decoding. Second, “hardware-agnostic” does not mean the system ignores hardware properties; on the contrary, hardware choice is formalized in the recommender, but postponed until after classical-to-quantum translation.

Within QSE, the framework’s importance lies in its software-engineering abstractions. The encoder–deployment–decoder split, the QCF intermediate representation, and the separation between model-backed Python parsing and model-free JSON processing all target maintainability, extensibility, and reproducibility. This suggests that the distinctive contribution of C2$C$3 is less the introduction of new variational or oracle constructions than the provision of an integrated engineering layer that renders existing quantum methods accessible from familiar classical specifications. In that sense, the framework exemplifies an infrastructural approach to QSE: the central research problem is not only how to design quantum algorithms, but how to package problem analysis, deployment, and interpretation into a coherent software pipeline for non-specialist developers.