arXiv CSopen access

Q-READY: Predictive Feasibility Assessment for Hybrid Quantum-Classical Applications

Q-READY : Predictive Feasibility Assessment for Hybrid Quantum-Classical Applications Tao Yue1 and Man Zhang1 1

Beihang University

arXiv:2606.16201v1 [cs.SE] 15 Jun 2026

Abstract Quantum computing is rapidly evolving into an emerging computational infrastructure and is increasingly being used to tackle real-world problems in domains such as chemistry, materials science, logistics, and finance, as well as software engineering problems such as test optimization and project scheduling. Hybrid quantum-classical applications are particularly important because they provide a practical path for integrating quantum capabilities into existing software systems under near-term hardware constraints. However, the engineering of hybrid quantum-classical applications remains largely ad hoc and constrained by hardware limitations including qubit scarcity, noise, and limited connectivity. In this paper, we propose Q-READY to address the lack of systematic methodologies for assessing the feasibility of hybrid solutions prior to costly implementation. Positioned as a Model-Based Systems Engineering (MBSE) approach grounded in Model-Driven Engineering (MDE) principles, Q-READY establishes a structured pipeline encompassing requirements modeling, problem formulation, workflow design, and hardware-aware feasibility assessment, enabling simulation-based evaluation and comparison of candidate solutions under realistic constraints through traceable system-level models and backend-aware abstractions. We illustrate the pipeline with a running credit-portfolio capital-assessment example, showing how requirements, problem structure, strategy choices, workflow behavior, backend assumptions, and feasibility evidence can be linked into a coherent engineering decision. Q-READY is envisioned as an environment that supports executable modeling, constraint evaluation, and predictive analysis. Its expected outcomes include a systematic methodology for hybrid quantum application design, a supporting software platform, benchmark datasets, and empirical design guidelines.

Keywords: Quantum Software Engineering, Hybrid Quantum-Classical Application, Feasibility Assessment

1

Introduction

Quantum computing is transitioning from a predominantly theoretical pursuit to an emerging computational infrastructure that is increasingly accessible and experimentally viable [8]. Although current devices remain within the Noisy Intermediate-Scale Quantum (NISQ) regime [61], characterized by limited qubit counts and significant noise, quantum processors have progressed from laboratory prototypes to programmable platforms that support practical, multidisciplinary experimentation across domains such as optimization, machine learning, and scientific computing [42], as well as software engineering [85]. Cloud-accessible platforms, including IBM Quantum1 , Origin Quantum2 , Amazon Braket3 , Microsoft Azure Quantum4 , and D-Wave Quantum5 , provide programmable access to both gate-based and annealingbased architectures, enabling the development and execution of quantum programs within classical computing environments [64, 24]. In parallel, heterogeneous computing architectures that integrate quantum processing units (QPUs) with classical central processing units (CPUs) and graphics processing units (GPUs) increasingly support hybrid quantum--classical workflows, where quantum components act as accelerators within larger computational pipelines [49, 3]. This hybridization is particularly important in the NISQ era because it offers a practical path for embedding limited quantum capabilities into existing software systems while relying on classical components to absorb the remaining workload. These advances, together with growing research and industrial ecosystems such as QuTech6 and Atos7 , have enabled practical experimentation with hybrid algorithms for optimization, machine learning, and scientific computing [13, 62, 9]. 1 See: https://www.ibm.com/quantum 2 See: https://qcloud.originqc.com.cn/en/services#hybrid 3 See: https://aws.amazon.com/braket/ 4 See: https://azure.microsoft.com/en-us/solutions/quantum-computing 5 See: https://www.dwavequantum.com/ 6 See: https://qutech.nl/. 7 See: https://atos.net/.

1

Different definitions of hybrid quantum–classical applications have been proposed in the literature, reflecting varying levels of abstraction. At the algorithmic level, hybrid approaches are typically defined by the tight coupling of parameterized quantum circuits with classical optimization loops, as seen in variational quantum algorithms such as Variational Quantum Eigensolver (VQE) and Quantum Approximate Optimization Algorithm (QAOA), where classical routines iteratively update quantum circuit parameters [15]. At a broader system level, hybrid applications are viewed as multi-stage computational workflows that integrate classical preprocessing, problem encoding, quantum execution, and classical post-processing, emphasizing end-to-end application structure rather than isolated algorithms [42, 77]. From an infrastructure perspective, hybrid quantum–classical computing refers to the co-execution of classical and quantum resources across heterogeneous platforms, often involving cloud-based orchestration and runtime environments [30]. Thought with these differences, a common theme across definitions is the iterative interaction between classical and quantum components under hardware constraints, highlighting the need for system-level abstractions and engineering methodologies. Despite ongoing advances in quantum hardware and algorithms, the systematic engineering of hybrid quantum–classical applications remains underdeveloped. Current practices largely rely on low-level software development kits (SDKs) and ad hoc experimentation, making it difficult to assess whether a proposed solution is feasible under realistic hardware constraints such as limited qubit counts, restricted connectivity, noise, and execution overhead. This limitation is rooted in the intrinsic complexity of hybrid quantum–classical systems, which integrate heterogeneous computational components operating under probabilistic semantics and strict physical constraints. As a result, many candidate applications remain speculative and costly to evaluate. Existing efforts predominantly focus on algorithm design and programming abstractions, with limited support for system-level reasoning, design-space exploration, and early-stage feasibility assessment [42, 76, 59]. To address this gap, this paper presents Q-READY , a vision for an MBSE-oriented framework that supports the systematic design and predictive feasibility assessment of hybrid quantum–classical applications. The core idea is to move beyond trial-and-error development toward a structured engineering process that enables early evaluation of candidate solutions. Q-READY adopts an MBSE perspective and uses MDE principles [31], together with Quantum Software Engineering (QSE) [59], to organize the development process into a pipeline that spans requirements modeling, guided problem structuring, strategy configuration, executable workflow modeling, and feasibility assessment. By leveraging simulation and resource estimation, the framework aims to support the analysis and comparison of alternative designs prior to deployment on quantum hardware. Rather than presenting a fully realized solution, Q-READY is intended as a research vision that highlights key challenges and outlines a potential direction for advancing the engineering foundations of quantum applications. To make the vision concrete, the paper develops a bank credit-portfolio capital-assessment example to illustarte the pipeline, from quantum-aware requirements to problem structuring, strategy instantiation, workflow modeling, and predictive feasibility decision-making. The example is not intended as a new financial-risk model or quantum algorithm, but to demonstrate how model-based traceability, supported by model-driven automation, can support early, evidence-based engineering decisions for a governed hybrid application. The remainder of this paper is organized as follows: Section 2 presents the required background. In Section 3, we present details of our vision Q-READY . We conclude the paper in Section 4.

2

Background

2.1

Hybrid Quantum-Classical Applications

In the past decade, quantum software infrastructures have matured significantly. Tool chains such as IBM Qiskit [6], Origin Quantum QPanda [19], and Microsoft Q# [71] provide high-level abstractions for developing variational and hybrid algorithms, while optimization-oriented platforms (e.g., QBoson and D-Wave) support Quadratic Unconstrained Binary Optimization (QUBO) modeling and annealing-based execution [85, 25]. In addition, cloud-based environments increasingly enable the orchestration of hybrid quantum–classical workflows across heterogeneous resources [24, 76]. These developments indicate that quantum computing is evolving into a practical computational resource embedded within broader software ecosystems. Nevertheless, progress in hardware capabilities and algorithmic techniques has outpaced the development of system-level engineering methodologies, particularly for managing the complexity of hybrid applications. Hybrid quantum–classical applications are inherently heterogeneous systems [21, 60]. They consist of multiple interacting components, such as classical preprocessing, problem encoding, quantum execution, feedback control loops, and post-processing. At the same time, these components operate under stringent constraints such as limited qubit resources, restricted connectivity, noise and decoherence, cloud latency, and stochastic measurement semantics. This combination of architectural heterogeneity and hardware-induced uncertainty makes it difficult to reason about system behavior and resource requirements at design time. Such challenges become particularly critical in application domains where hybrid quantum–classical approaches are expected to provide advantages, such as scientific simulation, cryptographic analysis, large-scale optimization,

2

and hybrid AI workflows [51, 42, 18, 39]. In these settings, practitioners must determine whether a given hybrid solution is feasible, scalable, and resource-efficient under realistic hardware constraints. However, due to the lack of systematic engineering support, such feasibility assessment remains largely ad hoc and difficult to perform prior to implementation. This motivates the need of Q-READY .

2.2

Quantum Software Engineering (QSE)

QSE adapts established software engineering principles to the development of quantum and hybrid quantumclassical systems [5, 59]. While it draws on decades of classical software engineering experience, it must also account for distinctive quantum characteristics such as superposition and entanglement, as well as the practical limitations of NISQ hardware [61]. Together, these features make system behavior harder to reason about at design time and strengthen the need for systematic engineering approaches that support early-stage feasibility reasoning and design-space exploration under realistic conditions. As defined in [59], QSE is ‘‘an interdisciplinary field that focuses on the principles, methodologies, standards, and tools for designing, developing, testing, maintaining, and managing quantum software systems, including hybrid quantum-classic systems that run on quantum computers or quantum simulators’’, and QSE ‘‘involves the application of quantum-based techniques, including quantum algorithms such as quantum annealing, to solve complex problems in both classic and quantum software engineering’’. Over the past few years, QSE has established its community and started to grow, marked by international conferences and workshops, dedicated journal special issues, and collaborative research initiatives. The QSE community has proposed various approaches tailored to deal with unique challenges in engineering quantum algorithms and applications. These methodologies span a broad spectrum, covering requirements engineering [69, 82, 65], quantum software architecture [4, 22, 76, 77], validating and verifying quantum software [43, 48, 50, 53, 40], etc. As the field continues to mature, the foundational work undertaken by the QSE community will undoubtedly play a pivotal role in shaping the future of quantum computing and real-world quantum applications.

2.3

Model-Based Systems Engineering, Model-Driven Engineering, and SysML

Model-Based Systems Engineering (MBSE) has been widely adopted in classical domains to manage system complexity, support requirement traceability, and enable early validation [31]. Its emphasis on abstraction, formalization, and traceability makes it a promising foundation for addressing the engineering challenges of hybrid quantum–classical systems. Model-Driven Engineering (MDE) complements this perspective by providing transformation, automation, and analysis techniques over structured model artifacts. However, existing MBSE and MDE practices have largely been developed for classical systems and do not directly capture key characteristics of quantum applications, such as probabilistic execution semantics, hardware heterogeneity across quantum backends, topology-constrained qubit interactions, and encoding transformations from domain problems to quantum representations. Consequently, a significant methodological gap persists: there is currently no unified MBSE approach, supported by MDE techniques, that integrates requirements engineering, hybrid architecture modeling, and hardwareaware feasibility analysis within a coherent systems engineering framework. This paper addresses this gap by proposing Q-READY , an MBSE-oriented approach that applies MDE principles to hybrid quantum–classical systems and enables executable, backend-aware system modeling for predictive feasibility assessment. The Systems Modeling Language (SysML) has long served as a standard modeling language in MBSE, widely adopted across domains such as aerospace, automotive, and cyber-physical systems. Standardized by the Object Management Group (OMG), it provides a general-purpose notation for representing system requirements, structure, and behavior within a unified framework. SysML v2 is the new generation of this systems modeling language for MBSE and a strong foundation for MDE-style automation over system models. It introduces a more rigorous semantic foundation, grounded in the Kernel Modeling Language (KerML), and improves modularity, reuse, variability, and constraint specification [1, 2]. Importantly, SysML v2 is no longer only a diagramoriented notation: its concrete syntax includes both textual and graphical forms, enabling the same model to be manipulated as structured text and inspected through stakeholder-oriented views. Industrial tool support is also emerging; for example, Dassault Systèmes provides CATIA SysML v2 within the CATIA Magic/No Magic tooling ecosystem, with support for synchronization between textual and graphical representations [16]. These characteristics make SysML v2 particularly suitable for Q-READY . The textual notation provides machine-readable model artifacts that can be parsed, transformed, versioned, checked, and used as context for large language model (LLM)-based modeling assistance. The graphical notation complements this by supporting human comprehension, communication, and review of requirements, architectures, workflows, and feasibility evidence. This dual representation is important because Q-READY aims to support both automated reasoning and human-in-the-loop engineering decisions. More broadly, the potential of integrating LLMs into MDE has already been recognized by the MDE community [83], further motivating an MBSE foundation in SysML v2 that exposes models in forms usable by both engineers and AI-assisted tooling. 3

3

Q-READY

In this section, we present our vision Q-READY in detail. Section 3.1 gives an overview of the framework, and Section 3.2 introduces the running credit-portfolio example used throughout the paper. Sections 3.3--3.7 then present the main Q-READY components one by one. For each component, we discuss the research rationale, summarize the relevant state of the art, outline the research roadmap, and illustrate the component through the running example. Finally, Section 3.8 synthesizes the running example across the complete Q-READY pipeline.

3.1

Overview

As shown in Figure 1, the Q-READY framework is organized into five tightly connected components that together form a coherent engineering pipeline. The pipeline begins with Quantum-aware Requirements Modeling (QRE), which establishes a structured requirements foundation for later analysis. It then proceeds to Guided Problem Structuring, which transforms formalized requirements into computational problem models suitable for hybrid quantum-classical solution design, and to Strategy Configuration & Instantiation, which defines mechanisms for generating alternative hybrid solution strategies from those abstractions through variation points, parameter spaces, and constraint rules. Next, Hybrid Executable Workflow Modeling converts strategy instances into formally defined executable workflows that can be directly analyzed. Finally, Predictive Feasibility Assessment evaluates candidate workflows using backend abstractions, simulation techniques, and analytical estimators, producing structured feasibility results that support comparison and iterative refinement. Q-READY is envisioned to contribute in four main ways: (1) framing hybrid quantum-classical applications from an MBSE perspective; (2) providing a unified MBSE-based framework for configuration and predictive feasibility assessment, grounded in MDE principles; (3) enabling traceable system-level models that span strategies, workflows, backend constraints, and data dependencies; and (4) supporting hardware-aware predictive analysis through backend abstractions and noise-aware modeling. Together, these contributions define the methodological direction of the vision and aim to strengthen the foundations of QSE for hybrid quantum-classical applications. Note that Q-READY does not rely on the availability of specific quantum devices. Instead, it provides structured modeling, configuration, execution emulation, and quantitative assessment capabilities that remain adaptable to evolving hardware landscapes. When quantum hardware becomes accessible, workflows can be deployed for empirical validation. The core value of the framework lies in enabling informed, evidence-based feasibility reasoning before deployment decisions are made. Across the pipeline, LLM-assisted modeling can support elicitation, guidance, model completion, and explanation [83]. However, Q-READY treats SysML v2 models, explicit constraints, and quantitative feasibility checks as the authoritative artifacts used for validation and decision-making. This division of roles allows LLMs to assist users without displacing formal model semantics or evidence-based feasibility reasoning.

3.2

Running Example: Bank Credit-Portfolio Capital Assessment

We use a bank’s credit-portfolio risk system as a running example. The system supports a concrete business decision: determining how much financial reserve the bank should hold to remain solvent if an unusually large number of borrowers fail to repay their loans over the next year. Every quarter, risk analysts execute an approved software workflow that reads the bank’s loan portfolio, simulates many possible economic scenarios, estimates the resulting credit losses, and submits the results for independent model-risk review. Capital planners then use the approved outputs to set financial reserves and lending limits. Each loan record provides three principal inputs. Exposure at default (EAD) is the amount still owed to the bank if the borrower defaults. Probability of default (PD) estimates the likelihood that the borrower will default within one year. Loss given default (LGD) is the fraction of the EAD that the bank does not expect to recover after taking into account collateral, repayments, and other recoveries. For example, if a $1 million loan has an LGD of 40%, it produces a $400,000 loss in the event of default. In the remainder of this example, we use the term facility to refer to an individual loan or credit agreement, and segment to refer to a group of facilities with similar risk characteristics. Table 1: Synthetic credit portfolio used in the running example Portfolio segment

Loans

Amount owed ($m)

Default chance

Loss share

Large corporate Mid-market SME Commercial real estate Retail secured Retail unsecured

600 1,400 3,000 500 2,500 2,000

300 250 180 120 100 50

0.8% 1.5% 2.5% 1.2% 1.0% 4.0%

45% 40% 35% 30% 20% 65%

Total

10,000

1,000

4

Hybrid Quantum-Classical Application Scenarios Scientific Discovery & Simulation

Security and Cryptography

Optimization of Complex Systems

Advanced Computation & AI

Quantum-aware Requirements Modeling Domain Context

Business Goals

Operational Constraints

Structure & Pattern Insight

Guided Reformulation and Encoding

Feasibility Feedback

Success Criteria Requirements Models

Strategy Configuration & Instantiation

Guided Problem Structuring Problem Structuring

Resource Constraints

Problem Models

Control-flow & Execution Semantics

Iterative & Configurable Workflow Patterns

Classical & Quantum Node Composition

Data Dependencies & Interface Binding

Select Paradigm & Alg. Family (Classical / Quantum / Hybrid) Configure Partition ClassicalParameters Quantum

Generate Strategy Instance

Strategy Instances

Hybrid Executable Workflow Modeling Executable Workflow Models

Predictive Feasibility Assessment for Hybrid Quantum-Classical Workflows Backend Abstraction 1. Qubit Count Model 2. Noise Model 3. Connectivity Model 4. Gate Timing Model

Execution Simulation 1. Quantum Circuit Simulation 2. Classical Optimizer Emulation 3. Hybrid Loop Emulation

Resource & Performance Estimation

Feasibility Reporting

1. Qubit Count, Circuit Depth, Gate Count 2. Runtime, Cost 3. Success Probability 4. Memory footprint

1. QPU/GPU/CPU Usage 2. Noise Robustness 3. Scalability 4. Execution Feasibility

Feasibility Reports

Figure 1: Overview of the Q-READY framework. The pipeline starts with quantum-aware requirements modeling, transforms requirements into structured computational problem models, derives validated hybrid strategy instances, converts them into executable workflow models, and evaluates candidate workflows through predictive feasibility assessment. Feedback links support iterative refinement when constraints, backend assumptions, or feasibility results change.

5

The concrete context is a quarterly assessment of the synthetic 10,000-loan, $1 billion portfolio summarized in Table 1. Defaults cannot be modeled as unrelated events because an economic downturn can cause many borrowers to default together. The approved classical system therefore generates correlated default scenarios and calculates the total loss in each scenario. From the resulting loss distribution, it reports: (1) expected loss, the average loss across scenarios; (2) 99.9% Value-at-Risk (VaR), a loss threshold exceeded in approximately one out of every 1,000 modeled years; and (3) economic capital, the additional reserve between expected loss and that severe-loss threshold. The computationally expensive step is repeatedly estimating rare-event probabilities from a large number of simulated scenarios. Quantum amplitude estimation (QAE) is a family of quantum algorithms proposed for estimating such probabilities using fewer model evaluations than classical Monte Carlo under suitable assumptions [79, 20]. In software-engineering terms, the candidate quantum component would replace one performance-critical probability-estimation service inside an existing governed workflow; it would not replace the complete risk system. The engineering question for Q-READY is whether this substitution can satisfy accuracy, runtime, security, auditability, and hardware constraints. Although the portfolio data are synthetic, the actors, workflow, inputs, outputs, and governance concerns reflect a real banking application. The example is not intended to contribute a new financial-risk model or quantum algorithm; it demonstrates the softwareengineering challenges of introducing a probabilistic, hardware-constrained quantum service into an existing governed software system.

3.3

Quantum Requirements Modeling

3.3.1

Research Rationale

MBSE languages and notations such as SysML provide established mechanisms for specifying system boundaries, stakeholder goals, constraints, and verification relations. However, a hybrid quantum--classical application introduces an additional requirements-engineering question: not only what the system must achieve, but also which obligations belong to the classical part, the quantum part, or their interaction. This allocation matters because system-level qualities such as accuracy and runtime may depend on quantum-specific quantities including logical and physical qubit demand, circuit depth, gate count, sampling budget, noise, and backend availability. These concerns must be represented before algorithm and backend selection. Otherwise, an attractive system-level goal can remain disconnected from the resource assumptions that determine whether it is realizable. Prior QSE research similarly emphasizes portability across heterogeneous quantum platforms, robustness under noise, scalability under constrained qubit resources, and explicit quantum--classical separation [68, 29]. We therefore treat quantum requirements modeling as the creation of a traceable argument from stakeholder intent to measurable hybrid, classical, and quantum obligations that can guide design-space exploration and later feasibility assessment. 3.3.2

State of the Art

Saraiva et al. [65] showed that quality and constraint concerns such as performance, reliability, scalability, and maintainability are central, hardware-dependent concerns for quantum programs rather than secondary considerations. Spoletini [69] examined how established requirements-engineering activities, including elicitation, analysis, specification, and validation, need to be adapted for quantum software. Pérez-Castillo and Piattini [58] proposed unified modeling language (UML) stereotypes to explicitly capture quantum-related concerns in use case diagrams. Specifically, they introduced the «Quantum» stereotype to identify use cases involving quantum computation (e.g., quantum chemistry), defined a «Quantum Computer» actor to represent quantum execution resources, and used the «Quantum Request» stereotype on include relationships to denote invocations of quantum software components. Yue et al. [82] proposed a SysML requirements diagram for credit-risk analysis that uses «cReq», «qReq», and «hReq» to identify classical, quantum, and hybrid responsibility. Importantly, the diagram also relates high-level performance expectations to estimable quantities such as required gates and ancilla qubits, and then to hardware constraints such as available qubits and circuit depth. This illustrates that quantum-aware requirements modeling is not merely the addition of quantum labels: it must expose decomposition, dependency, and allocation relations that make feasibility assumptions analyzable. Existing proposals establish useful notations, but they remain preliminary and provide limited methodological and tool support for maintaining these relations through later engineering phases. In particular, a requirements model must support systematic refinement from stakeholder goals to measurable acceptance criteria, allocation to hybrid components, explicit assumptions about candidate backends, and traceability to the evidence used for verification.

6

3.3.3

Research Roadmap

First, Q-READY introduces hybrid-specific extensions to SysML v2 requirements notations to support the structured specification of hybrid quantum-classical applications. Building on [82], each requirement can be marked as cReq, qReq, or hReq to indicate whether responsibility lies with the classical part, the quantum part, or the hybrid system. A high-level hybrid requirement can therefore be decomposed into classical and quantum subrequirements without losing its original stakeholder rationale. The library also defines typed relations for decomposition, satisfaction, constraint, dependency, and verification. Second, Q-READY supports the structured elicitation of domain context, stakeholders, system boundaries, goals, operational assumptions, and the potential value of quantum integration. Guided templates of Q-READY should clarify the task to be achieved, why a quantum component is being considered, which classical baseline remains authoritative, and under which conditions the hybrid system operates. At this stage, the objective is to establish the problem and its acceptance conditions, not to commit prematurely to a particular mathematical formulation, quantum algorithm, or backend. Third, Q-READY refines stakeholder goals into measurable requirements and exposes their feasibility dependencies. System-level success criteria, such as an accuracy or runtime target, are related to quantum resource obligations such as estimated qubits, gates, circuit depth, shots, and error budget, as well as to backend constraints and classical orchestration costs. These values may initially be unknown; the requirements model records them as quantities to be estimated and binds them to explicit verification methods and evidence. This allows later phases to populate the estimates and determine whether a candidate strategy satisfies the original requirements. Finally, the requirements model serves as a live traceability backbone for the remaining Q-READY pipeline. Problem formulations trace to the requirements they refine; strategy configurations are rejected when they violate allocation or resource constraints; executable workflows identify the components that satisfy each requirement; and feasibility results provide verification evidence. This continuity turns the requirements diagram from descriptive documentation into an analyzable contract for design and assessment. 3.3.4

Running Example

The QRE component of Q-READY organizes the running example as the SysML v2 requirements model shown in Figure 2. The model introduces a reusable SystemRequirement requirement definition whose subject is a Bank Credit-Portfolio Capital Assessment System. Within this subject, the model defines a PortfolioAssessmentRun action with a runtimeHours duration attribute, and instantiates the system action assessPortfolio. The same reusable requirement definition also declares the two key stakeholders, creditRiskAnalyst and modelRiskCommittee. The five Q-READY requirement-model elements are then defined as specializations of SystemRequirement: DomainContext, BusinessGoal, OperationalConstraint, ResourceConstraint, and SuccessCriterion. The projectContext instance of DomainContext records the quarterly assessment of a synthetic 10,000loan, $1 billion portfolio, the validated classical capital-assessment workflow, and the candidate quantum probability-estimation service for risk-measure estimation. From this context, the businessGoal instance states the stakeholder value to be delivered: reliably report expected loss, 99.9% VaR, and economic capital while assessing whether the candidate quantum service is viable for future use in the capital-assessment workflow. The operationalConstraints requirement contains hybrid operational obligations, including completion of each quarterly assessment within 4 hours, repeatable reruns for audit and investigation, and compatibility with the existing classical reporting workflow. Its runtimePerformance constraint formalizes the runtime requirement as system.assessPortfolio.runtimeHours <= 4.0 [SI::h]. The resourceConstraints requirement captures both classical and quantum resource limits: protected credit data must not be transferred to a public quantum backend, quantum execution must fit the selected private or approved backend, and required qubits, circuit depth, gate count, shots, latency, and error budget must remain within backend limits. The successCriteria requirement specifies measurable acceptance conditions: expected-loss error below 1% and VaR99.9 error below 2% against the validated classical benchmark, with quantum-service viability supported only when accuracy, runtime, and backend-resource constraints are all satisfied. Within these five Q-READY model elements, we adopt the notation introduced in [82] to distinguish responsibility across the hybrid system. The stereotypes «cReq», «qReq», and «hReq» indicate requirements for the classical part, quantum part, and hybrid system, respectively. Thus, the business goal, runtime obligation, compatibility obligation, and accuracy thresholds are hReqs; the validation oracle and protected-data restriction include cReq responsibilities; and backend-capacity and quantum-service viability obligations are qReqs. These elements make feasibility reasoning explicit already at the requirements level. Figure 2, for example, does not leave the runtime obligation as informal prose; it formalizes it as the runtimePerformance constraint over system.assessPortfolio.runtimeHours. More generally, the same requirements model keeps accuracy thresholds, validation baselines, protected-data restrictions, and backend-capacity limits explicit, so that later

7

Figure 2: SysML v2 requirements diagram for the credit-risk example. The pink elements define five specialized types of SystemRequirement: DomainContext, BusinessGoal, OperationalConstraint, ResourceConstraint, and SuccessCriterion. The diagram also defines the subject of SystemRequirement, namely the Bank Credit-Portfolio Capital Assessment System, including its assessPortfolio action and the runtimeHours attribute used for runtime reasoning. The requirement definition is associated with two stakeholder types, creditRiskAnalyst and modelRiskCommittee. The blue elements illustrate that a textual requirement can be formalized as an executable constraint: the first <<hReq>> in operationalConstraints is represented by the runtimePerformance constraint over system.assessPortfolio.runtimeHours.

8

strategy configuration can reject inadmissible candidates before implementation. In this way, the requirements model serves not only as documentation of stakeholder intent but also as a typed basis for downstream feasibility assessment.

3.4

Guided Problem Structuring

3.4.1

Research Rationale

Computational structuring forms the critical bridge between formalized requirements (Section 3.3) and systematic strategy configuration (Section 3.5). Optimization theory provides mature foundations for transforming domain problems into well-established solver-oriented formulations, such as linear programming models and quadratic binary formulations, including Quadratic Unconstrained Binary Optimization (QUBO) [25] and Ising models [45]. Computational complexity theory further supports the characterization of these formulations in terms of problem classes, reductions, and expected computational difficulty. Nevertheless, the translation from domain-level descriptions to problem models suitable for hybrid quantum-classical workflows remains largely expert-driven [10]. Beyond optimization, recent discussions in QSE also highlight the absence of systematic methods for earlystage problem structuring, structural pattern recognition, and guided reformulation that preserve domain semantics while preparing problems for quantum suitability analysis [51, 76]. In practice, domain experts must manually interpret whether a problem is combinatorial, sampling-based, linear-algebraic, or variational in nature, and whether its structure aligns with qubit-based representations or hybrid decomposition strategies. This reliance on tacit expertise creates a significant barrier to adoption and limits reproducibility [10, 51, 76]. Although algorithmic paradigms such as variational quantum algorithms and hybrid optimization loops are now well established [15, 13], mainstream software platforms still focus primarily on circuit construction, execution, and algorithm libraries, with comparatively limited support for structured, traceable reformulation from high-level problem descriptions [22, 51, 76]. 3.4.2

State of the Art

Zhang et al. in their recent survey [85, 84] analyzed quantum, quantum-inspired, and hybrid optimization, identifying recurring structural types (primarily QUBO and Ising models) alongside gaps in formulation rigor and standardized practices. While emerging tools like LLM-QUBO [55] attempt to automate the mathematical transformation from natural language to QUBO matrices, bridging the gap from high-level application (domain) requirements to structured problem models remains largely infeasible without manual expert intervention. Furthermore, QUBO/Ising represent only one paradigm; other critical models, such as gate-based circuits and variational quantum circuits (VQCs), require entirely different formalization and execution semantics. These findings directly motivate guided problem structuring, which replaces today’s ad hoc, expert-driven translations with a systematic, education-oriented MBSE environment that leverages a curated computational pattern library and MDE-style guided reformulation to help users transform requirement-level descriptions into explicit, hybrid-aware problem models. In this setting, LLM assistance can help interpret domain descriptions, suggest candidate structural patterns, and explain reformulation alternatives, while the resulting problem model remains a typed and reviewable artifact rather than an unconstrained natural-language output. 3.4.3

Research Roadmap

First, guided templates help clarify decision objectives (e.g., optimization, estimation, simulation), variable types (binary, integer, continuous), constraint categories, system scale, and expected outputs, instead of requiring formal mathematical derivations. Importantly, the problem structuring process captures problem-domain characteristics that influence potential quantum realizability, without yet committing to specific algorithms or circuits. For example, it identifies whether the problem is predominantly discrete (suggesting natural qubit-based representations), whether it exhibits strong combinatorial coupling between variables (which may translate into multi-qubit interactions), and how the underlying dependency structure can be represented as a graph (e.g., sparse, clustered, or densely connected). The intent is to remain at the level of problem semantics while encoding information that guides encoding choices and hybrid decomposition. Second, a compact and well-structured computational pattern library captures recurring structural patterns relevant to hybrid quantum-classical applications. These patterns are systematically collected and distilled from the scientific literature, including established quantum algorithm classes, hybrid variational schemes, and commonly studied optimization and simulation formulations. The library organizes stable problem forms such as combinatorial optimization, quadratic binary models (e.g., QUBO/Ising-type structures), sampling tasks, linear-algebraic kernels, and variational optimization loops. Each pattern is characterized by its defining structural properties, interaction topology, scaling tendencies, and typical computational implications. Based on this curated body of knowledge, the system generates structure pattern insights for end users by matching

9

their structured problem models to relevant archetypes. The feedback provides interpretable explanations of structural similarities, expected scaling behavior, coupling density, and indicative computational hardness. Third, guided reformulation mechanisms assist users in progressively mapping structured problem models toward computationally explicit representations. Building on the outputs of the previous tasks, modeling templates and stepwise guidance support the exploration of alternative reformulation pathways, including classical formulations and hybrid-compatible encodings. The process is explicitly human-in-the-loop and explanatory: proposed transformations are presented as structured alternatives, accompanied by rationale and implications, rather than enforced or automatically optimized conversions. LLM-generated explanations can make these alternatives easier to inspect, but admissibility and traceability are determined by the structured model and its constraints. To support these choices, the framework also provides approximate indicators of representation size, structural growth, variable expansion, and resource implications, such as potential qubit scaling or interaction amplification. These indicators help users compare reformulation alternatives in a transparent and traceable way, while keeping the focus on guided transformation rather than automated encoding generation. 3.4.4

Running Example

Guided problem structuring starts from the QRE model in Section 3.3, rather than from an informal problem statement, and produces the structured problem model consumed by Strategy Configuration and Instantiation (Section 3.5). In the credit-risk example, the QRE elements provide the input boundary: projectContext identifies the target portfolio, validated classical benchmark, and candidate quantum probability-estimation service; businessGoal identifies the risk measures to preserve; and operationalConstraints, resourceConstraints, and successCriteria define the runtime, backend, data-protection, and accuracy obligations that later strategy choices must satisfy. Problem Structuring. Q-READY first extracts the computational task, inputs, outputs, and acceptance obligations from the QRE model. It creates CreditRiskProblem_01 and classifies it as a probabilistic riskestimation task, because expected loss, VaR99.9, and economic capital are derived from the portfolio loss distribution rather than from an optimization objective. The structured data flow is recorded as approved facility records → conditional default probabilities → loss distribution → cumulative distribution FL (x) = P [L ≤ x] → bisection search for the smallest x with FL (x) ≥ 0.999. This step preserves traceability to the QRE businessGoal and successCriteria: the problem model must produce expected loss and VaR99.9, and the resulting approximation error must later be checked against the 1% and 2% thresholds. Structure and Pattern Insight. Q-READY then characterizes the structural properties that influence downstream strategy selection. The model records that borrower defaults are correlated, that the central computational object is the portfolio loss distribution together with a rare-tail probability query for VaR estimation, that the input scale is 10,000 loans over a $1 billion portfolio, and that direct facility-level encoding may create a large binary state space. These descriptors characterize the problem as a probabilistic portfolio-loss estimation task rather than an optimization task. They also indicate that classical Monte Carlo simulation is the natural benchmark for estimating the loss distribution, while the rare-tail probability query provides a plausible entry point for a quantum amplitude-estimation strategy, subject to state-preparation and encoding feasibility. Concretely, the problem requires simulating uncertain and correlated borrower defaults, constructing or approximating the resulting portfolio loss distribution, and repeatedly estimating probabilities for candidate VaR thresholds, either in cumulative form FL (x) = P [L ≤ x] or equivalently in tail form P [L > x]. In this sense, the natural computational structure is probability estimation over a loss distribution, not binary objective-function minimization. This explains why a premature QUBO reformulation would obscure the actual credit-risk analysis task. Guided Reformulation and Encoding. Finally, Q-READY explores a small set of candidate reformulations for the same structured problem model rather than committing directly to a quantum algorithm. Here, CreditRiskProblem_01 remains the stable problem-level artifact, while F1-FacilityLevel, F2-SegmentAggregated, and F3-HardwarePilot represent alternative formulation paths attached to that problem model. These three candidates are not arbitrary: they are produced by guided transformations over the same portfolio-loss model, namely preserving the original facility-level granularity, aggregating facilities into the six business segments already present in the input model, and restricting the model to a small representative subset for hardwareoriented feasibility exploration. Rather than expressing the outcome as a detailed formulation listing, Q-READY can present the decision as a compact evaluation template that compares candidate formulations along a small set of selection criteria. In this template, fidelity denotes how closely a formulation preserves the original domain semantics, abstraction captures the degree of aggregation introduced during modeling, traceability indicates how directly modeling decisions can be linked back to the QRE, and resource fit summarizes expected compatibility with the stated execution constraints. This should be read only as a running example: in the full Q-READY approach, richer templates with additional aspects are expected to support a broader range of problem-modeling situations. Table 2 shows this template for the running example. 10

Table 2: Comparison of reformulation alternatives for the running example Formulation

Fidelity Abstraction Traceability Resource fit Selected

F1-FacilityLevel High F2-SegmentAggregated Medium F3-HardwarePilot Low

Low Medium High

High Medium Low

Low High High

No Yes No

For the running example, the template marks F2-SegmentAggregated as the selected option because it provides the best balance between domain fidelity, manageable abstraction, retained traceability, and resource fit under the stated constraints. In this presentation style, the handoff to Section 3.5 is captured as a structured selection summary: one formulation is retained for the next phase, while the remaining candidates stay documented as rejected but traceable alternatives.

3.5

Strategy Configuration and Instantiation

3.5.1

Research Rationale

Current practice in selecting classical, quantum, or hybrid computational strategies remains largely heuristic and expert-driven. Paradigm selection, algorithm choice, hybrid partitioning, and parameter tuning are typically performed manually, often guided by informal reasoning or tool-specific defaults, with limited formal linkage to the structural characteristics of the underlying problem model [42, 13, 15]. Even when configuration tools are available, they frequently operate as menu-based selectors without explicit semantic constraints, compatibility validation, or traceable justification [38]. This lack of structured configuration logic reduces reproducibility, complicates systematic exploration of alternatives, and weakens continuity toward executable workflow generation (Section 3.6) and feasibility analysis (Section 3.7). 3.5.2

State of the Art

Extensive experience in classical domains demonstrates that formal specification techniques, such as the Object Constraint Language (OCL), are effective in capturing complex domain constraints in an executable and analyzable form, while automation (e.g., with search-based methods) enables systematic exploration of configuration spaces [44, 66, 70]. These approaches rely fundamentally on appropriate abstractions and modeling support, suggesting that established principles from classical software engineering can inform systematic modeling, configuration, and validation in hybrid quantum–classical systems. In this context, classical software engineering has accumulated decades of experience in modeling and metamodeling, resulting in a rich ecosystem of languages and tools. Widely adopted notations such as UML, SysML, and Business Process Model and Notation (BPMN), together with platforms such as Papyrus, Eclipse Modeling Framework (EMF), and PlantUML, provide mature foundations for abstraction, analysis, and modeldriven development. Building on these foundations, recent work has begun to extend modeling techniques to the quantum domain. For example, Pérez-Castillo and Piattini [58] introduce UML stereotypes to capture quantum-related concerns at the requirements level, while Guo et al. [27] propose QuanUML, which incorporates constructs such as qubits and quantum gates into UML-based models. Beyond UML-based extensions, a range of representations has been explored for quantum software, including cause–effect graphs for testing [52], quantum flowcharts for algorithm-level control and data flow [67], and quantum decision diagrams for representing and analyzing quantum states and circuits [78]. At a lower level of abstraction, quantum circuit diagrams remain the dominant representation, describing sequences of quantum gates applied to qubits and supporting various optimizations such as circuit depth reduction and noise-aware transformations [37, 54, 11]. However, these representations primarily operate at the level of notation or algorithmic structure and provide limited support for system-level abstraction. Although tools such as Qiskit, Microsoft’s Quantum Development Kit (QDK), and PennyLane enable modeling and simulation of quantum circuits, and frameworks such as the MQT DD Package [86] support decision-diagram-based representations, they largely focus on execution and analysis rather than enabling higher-level reasoning about alternative system designs. As a result, the abstraction level remains insufficient for supporting early-stage modeling, design-space exploration, and feasibility analysis of hybrid quantum–classical applications. Therefore, modeling notations and tools alone are insufficient to support effective abstraction. Each abstraction must serve a well-defined analytical or engineering purpose. In particular, there is currently a lack of methodologies that systematically scope and constrain the strategy configuration space of hybrid quantum–classical applications, limiting the ability to reason about feasible design alternatives in a principled manner.

11

3.5.3

Research Roadmap

Q-READY addresses this gap through an MBSE-oriented, hence structured configuration space for hybrid computational strategies, grounded in SysML v2 and supported by MDE-style transformations. Strategy selection is treated not as ad hoc option picking, but as a constrained configuration process defined over a structured metamodel. SysML v2 provides typed relationships, variability mechanisms, and integrated constraint support, enabling strategy elements such as computational paradigm, algorithm family, partitioning structure, and parameters, to be explicitly modeled and semantically connected to the problem structures (Section 3.4). Metamodel constraints encode compatibility and dependency rules derived from algorithmic assumptions, hardware constraints, and emerging best practices. Overall, the enriched problem models produced in the Guided Problem Structuring phase are transformed into validated strategy instances represented as SysML v2 artifacts. Each strategy instance captures a coherent and constraint-validated configuration of paradigm, algorithmic approach, hybrid structure, and parameters, with explicit traceability to the originating problem structure, thereby establishing a rigorous bridge between problem abstraction and executable workflow modeling (Section 3.6). The first task establishes a strategy configuration metamodel, implemented as an extension library within SysML v2, to ensure integration with the existing modeling environment. The full library may contain many reusable strategy options, while Listing 1 presents only the core excerpt needed to explain the running example. In this excerpt, a StrategyInstance links back to a structured ProblemModel, binds the main variation points considered here, namely paradigm, algorithm, encoding, and backend, and stores the feasibility quantities used for validation. The enumerations are included because they define the controlled value spaces referenced by the compatibility rules. The omitted parts of the metamodel define concrete option elements, such as HybridQuantumClassical and ClassicalOnly for execution paradigms, IterativeAmplitudeEstimation and QAOA for algorithmic choices, and CreditLossDistributionEncoding and QUBOProblemEncoding for encoding choices. These elements are treated as members of an option library rather than as the conceptual core of the metamodel. The aim is to establish a controlled and analyzable variability backbone that captures the admissible configuration space while remaining natively embedded within SysML v2. package QREADY_StrategyConfigurationMetamodel { part def ProblemModel { attribute problemId : String ; attribute problemType : ProblemType ; attribute structuringObjective : String ; }

part def StrategyInstance { attribute strategyId : String ; attribute status : ValidationStatus ; ref problem : ProblemModel ; part paradigm : ComputationalParadigm ; part algorithm : AlgorithmFamily ; part encoding : ProblemEncoding ; part backend : BackendProfile ; part evaluation : FeasibilityEvaluation ; constraint validProbabilityStrategy { problem . problemType == ProblemType :: ProbabilisticRiskEstimation implies algorithm . supportsProbabilityEstimation == true }

constraint problemModelEncodingIncompatibility { problem . problemType == ProblemType :: ProbabilisticRiskEstimation implies encoding . encodingType != EncodingType :: QUBOEncoding } }

part def ComputationalParadigm { attribute name : String ; attribute isQuantumEnabled : Boolean ; attribute isHybrid : Boolean ; }

part def AlgorithmFamily { attribute name : String ; attribute algorithmPattern : AlgorithmPattern ; attribute supportsProbabilityEstimation : Boolean ; attribute supportsOptimization : Boolean ; attribute requiresStatePreparation : Boolean ; }

part def ProblemEncoding { attribute encodingType : EncodingType ; attribute requiresLossDistribution : Boolean ; attribute requiresTailProbability : Boolean ; attribute requiresObjectiveFunction : Boolean ; }

part def BackendProfile { attribute backendName : String ; attribute isPrivate : Boolean ;

12

attribute maxQubits : Integer ; attribute maxCircuitDepth : Integer ; attribute maxShots : Integer ; }

part def FeasibilityEvaluation { attribute requiredQubits : Integer ; attribute estimatedCircuitDepth : Integer ; attribute estimatedShots : Integer ; attribute estimatedRuntimeHours : Real ; attribute expectedLossError : Real ; attribute varError : Real ; }

enum def ProblemType { enum ProbabilisticRiskEstimation ; enum CombinatorialOptimization ; enum EnergySimulation ; enum LinearAlgebra ; }

enum def AlgorithmPattern { enum ProbabilityEstimation ; enum Optimization ; enum Variational ; enum Sampling ; }

enum def EncodingType { enum LossDistributionEncoding ; enum QUBOEncoding ; enum HamiltonianEncoding ; enum LinearSystemEncoding ; }

enum def ValidationStatus { enum Candidate ; enum Rejected ; enum Validated ; } }

Listing 1: Textual SysML v2 excerpt of the core strategy-configuration metamodel The second task formalizes compatibility and dependency constraints directly in the strategy-configuration metamodel. The constraints embedded in StrategyInstance in Listing 1 define metamodel-level validity rules rather than application-instance checks: if the structured problem is classified as ProbabilisticRiskEstimation, then the selected algorithm must support probability estimation, and explicitly incompatible encodings such as QUBOEncoding are excluded. Additional metamodel constraints are derived from algorithmic assumptions in the literature, hardware specifications, emerging standards, and quantum software repositories. By embedding these rules directly in the SysML v2 model layer, Q-READY ’s implementation can automatically validate configurations and prune invalid combinations early in the modeling process. For the credit-risk example, the problem model created in Section 3.4 is therefore constrained toward a probability-estimation strategy and away from optimization-oriented encodings before any concrete backend or feasibility values are instantiated. The third task supports assisted strategy configuration. Building on the structured problem models obtained in the problem structuring phase (Section 3.4) and the metamodel-constrained variability structure, Q-READY performs constrained model completion by identifying admissible configuration paths, proposing candidate strategies aligned with detected structural patterns, and preventing semantically invalid selections. Rule-based reasoning grounded in model semantics provides the primary validation mechanism, while language-modelassisted guidance can complement it when explanatory or exploratory support is useful. This combination separates enforceable semantic constraints from advisory modeling assistance, which is important for reliable and explainable strategy configuration. The final task generates a validated strategy instance that conforms to the metamodel in Listing 1. Such strategy instances encapsulate all selected configuration elements under enforced constraints, maintain links to the originating problem model, and record the feasibility values used during validation. They constitute the formal output of this phase and serve as structured input to the hybrid executable workflow modeling phase (Section 3.6), ensuring methodological continuity across the MBSE pipeline. 3.5.4

Running Example

Listing 2 shows a compact instance model for the credit-risk example. The instance links the strategy back to CreditRiskProblem_01, which was produced by guided problem structuring as a probabilistic risk-estimation problem. More specifically, the listing should be read as the strategy-level continuation of the selected F2-SegmentAggregated reformulation path from Section 3.4. That is why the instance binds an iterative amplitude-estimation algorithm, a CreditLossDistributionEncoding corresponding to the bucketed segmentaggregated formulation, a private backend, and feasibility estimates. The strategy is marked Validated at the strategy-configuration level because the evaluation values satisfy the technical QRE constraints: the backend is private, required qubits and circuit depth fit the backend profile, estimated runtime is below four hours,

13

expected-loss error is below 1%, and VaR error is below 2%. This status does not by itself imply production approval; governance approval is assessed later in the predictive feasibility phase. package CreditRisk_StrategyInstance { public import QREADY_StrategyConfigurationMetamodel ::*; part creditRiskProblem_01 : ProblemModel { attribute problemId = " CreditRiskProblem_01 "; attribute problemType = ProblemType :: ProbabilisticRiskEstimation ; attribute structuringObjective = " Correlated probabilistic simulation plus tail - risk estimation "; }

part approvedPrivateBackend_01 : BackendProfile { attribute backendName = " Approved private quantum backend "; attribute isPrivate = true ; attribute maxQubits = 80; attribute maxCircuitDepth = 5000; attribute maxShots = 100000; }

part qaeFeasibility_01 : FeasibilityEvaluation { attribute requiredQubits = 64; attribute estimatedCircuitDepth = 3200; attribute estimatedShots = 50000; attribute estimatedRuntimeHours = 3.5; attribute expectedLossError = 0.008; attribute varError = 0.015; }

part creditRiskStrategy_01 : StrategyInstance { attribute strategyId = " CreditRiskStrategy_01 "; attribute status = ValidationStatus :: Validated ; ref problem = creditRiskProblem_01 ; part paradigm : HybridQuantumClassical ; part algorithm : IterativeAmplitudeEstimation ; part encoding : CreditLossDistributionEncoding ; part backend = approvedPrivateBackend_01 ; part evaluation = qaeFeasibility_01 ; } }

Listing 2: Validated strategy instance for the credit-risk running example

3.6

Hybrid Executable Workflow Modeling

3.6.1

Research Rationale

While the strategy configuration and instantiation phase (Section 3.5) enables the derivation of formally valid strategy instances, it does not by itself ensure that these configurations can be realized as executable hybrid solutions. In current practice, hybrid quantum–classical applications are typically implemented directly within SDK-specific environments such as Qiskit or D-Wave toolchains, where orchestration logic, backend invocation, iteration control, and data exchange are encoded procedurally [81]. As a result, key aspects such as control-flow semantics, convergence behavior, and hybrid partitioning remain implicit, tightly coupled to specific platforms, and weakly traceable to higher-level design decisions [77]. This disconnect highlights a fundamental limitation: there is no explicit representation that bridges strategylevel configurations and their executable realization. Without such a representation, it is difficult to systematically analyze workflow behavior, reason about alternative execution strategies, or perform feasibility assessment prior to implementation. This gap motivates the need for an explicit workflow modeling layer that captures control flow, component interactions, and data propagation in a structured and analyzable form. By elevating hybrid workflows to first-class modeling artifacts, it becomes possible to ensure consistency between design and execution, while enabling downstream analysis such as predictive feasibility assessment (Section 3.7). 3.6.2

State of the Art

As discussed earlier, classical software engineering provides a rich set of modeling notations (e.g., UML, SysML) to support abstraction and analysis. In particular, executable behavior modeling has been extensively studied, supported by well-established notations such as BPMN and state machines, which enable the explicit specification of control flow, data dependencies, and system interactions [83]. These notations, together with associated execution and analysis techniques, provide a solid foundation for modeling and reasoning about executable workflows in classical systems. In the quantum software engineering context, workflow-based approaches have become an important direction for orchestrating hybrid quantum--classical applications. QuantME extends BPMN with quantum-specific modeling constructs and transformations for executable quantum workflows [77]. Building on this line of work, Beisel et al. [12] present a pattern-based approach for generating and adapting quantum workflows from selected quantum computing patterns. Their approach combines a quantum computing pattern language, solution 14

repositories, QuantME modeling constructs, workflow rewriting, packaging, deployment, and execution support, and evaluates the prototype through use cases, runtime measurements, and a user study. This work provides strong evidence that reusable workflow patterns and automation can reduce the complexity of constructing hybrid quantum applications. The focus of Q-READY is complementary. Existing workflow-generation approaches primarily start from selected quantum patterns or available implementations and automate their realization as executable workflows. Q-READY instead places the workflow layer inside a broader MBSE traceability chain, supported by MDE transformations: workflow models are derived from quantum-aware requirements, structured problem models, and validated strategy instances, and then become the basis for predictive feasibility assessment. Thus, QSE workflow automation provides an important foundation, while Q-READY addresses the upstream and downstream links needed for early, requirements-driven feasibility reasoning. Simulation plays a central role in MBSE, and MDE techniques are often used to operationalize model execution and analysis for validating design decisions and supporting early-stage feasibility assessment [31]. In classical systems, a variety of model execution and simulation techniques have been developed to enable reasoning about workflows, performance, and resource constraints at the system level [17, 28, 36]. In contrast, such capabilities remain largely absent for hybrid quantum–classical systems. Although simulation is extensively used in quantum computing, existing approaches primarily operate at the level of quantum algorithms and circuits. Current techniques include state vector simulation, which provides exact representations of quantum states but scales poorly with increasing qubit counts; density matrix simulation, which supports modeling noise and decoherence at higher computational cost; and hardware-aware simulation, which incorporates device-specific noise models to approximate real execution environments. However, these techniques focus on the behavior of isolated quantum components rather than the execution of end-to-end hybrid workflows. As a result, they provide limited support for analyzing system-level properties such as cross-component interactions, resource allocation, and architectural trade-offs, which are essential for feasibility assessment of hybrid quantum–classical applications. A range of platforms support quantum software modeling and simulation, spanning both hardware-specific and general-purpose environments. For instance, Qiskit is tailored for IBM quantum platforms, while more general tools provide broader modeling and integration capabilities. The MATLAB Quantum Computing Toolbox8 supports the construction, simulation, and execution of quantum algorithms, with connectivity to external hardware and simulators, leveraging MATLAB’s extensive ecosystem for cross-domain integration. QuTiP [33, 34, 63] focuses on simulating open quantum systems, offering abstractions such as density matrices, noise modeling, and quantum trajectory methods, and integrates with scientific computing libraries in Python. PennyLane [57] targets hybrid quantum machine learning, enabling integration with classical ML frameworks (e.g., TensorFlow, PyTorch) and providing reusable templates for variational circuits across multiple quantum backends. While these platforms provide essential capabilities for circuit construction, simulation, and hybrid algorithm development, their abstractions remain largely centered on quantum operations and algorithmic workflows. They offer limited support for modeling executable hybrid workflows at the system level, particularly in representing cross-component interactions, control flow, and design alternatives. Consequently, they are insufficient for enabling systematic design-space exploration and predictive feasibility analysis. 3.6.3

Research Roadmap

Q-READY addresses this limitation through a structured workflow modeling layer that systematically transforms validated strategy instances into executable hybrid workflows. The core objective is to make orchestration logic explicit, analyzable, and reusable. Instead of encoding hybrid coordination in scripts, Q-READY models sequencing, branching, iteration, synchronization, and quantum-classical invocation boundaries as first-class elements with well-defined semantics. Similarly, recurrent orchestration structures observed in hybrid quantumclassical implementations such as classical outer-loop optimization with quantum evaluation (e.g., VQE/QAOAstyle loops) [41], preprocessing followed by quantum core execution [46], or sampling-driven iterative refinement as in quantum annealing [73] can be systematically abstracted into reusable workflow patterns. Formalizing these patterns within SysML v2 enables disciplined composition of heterogeneous computational nodes and early validation of interface compatibility, data dependencies, and partitioning constraints before execution, thereby extending MBSE practice with MDE-style automation for hybrid quantum workflows. To achieve the above objective, the first concern is explicit control-flow and execution semantics for hybrid workflows at the modeling layer. These hybrid workflow models capture sequencing, branching, iteration, synchronization, and well-defined invocation boundaries between classical and quantum components. In the credit-risk case, this means making explicit that a classical controller constructs the governed loss model, invokes quantum probability estimation repeatedly inside a VaR search, computes tail metrics, and validates the result against acceptance criteria. Execution configurations, such as precision, confidence, backend selection, and fallback behavior, are therefore modeled as explicit workflow parameters rather than left implicit in SDK scripts. 8 https://jp.mathworks.com/products/quantum-computing.html, accessed June 13, 2026.

15

Similarly, a D-Wave–based workflow may define a boundary where a QUBO formulation is submitted to an annealer, returning sampled solutions and associated energy values to a classical post-processing stage. These invocation boundaries are modeled explicitly to distinguish local classical computation from remote quantum service calls, including data encoding and decoding steps. Further, iterative structures are specified declaratively based on convergence criteria rather than embedded in procedural code. For instance, a quantum annealing workflow may repeat sampling until a stable minimum energy distribution or solution frequency is observed. By modeling such convergence conditions and evaluation feedback explicitly at the workflow level, hybrid orchestration logic becomes transparent, analyzable, and traceable to the strategy instance, instead of being hidden in imperative scripts. In Q-READY , hybrid workflows are modeled graphically to support clearer configuration and improved stakeholder comprehension, and SysML v2 behavioral constructs (e.g., actions) are extended with domain-specific notations for quantum execution boundaries, Hamiltonian evaluation, energy estimation, sampling operations, hybrid feedback control, etc. Second, interactive and configurable workflow patterns are derived through systematic analysis. Reusable orchestration templates are identified and abstracted from multiple sources: 1) empirical studies and published hybrid algorithm implementations (e.g., VQE, QAOA, quantum annealing workflows), 2) open-source repositories such as Qiskit and D-Wave application examples, 3) SDK documentation and reference architectures, and 4) internally developed experimental prototypes. Through structured mining and analysis of these artifacts, recurring observations (e.g., preprocessing followed by quantum core execution and classical refinement) are formalized as parameterized workflow patterns. These patterns are then configurable according to the selected strategy instance, enabling systematic reuse. Third, structured composition of classical and quantum computational nodes is supported through targeted extensions of SysML v2. Specific domain notations extend SysML v2 behavioral and structural constructs, enabling explicit representation of classical computation modules, quantum execution units, Hamiltonian evaluation components, sampling blocks, and hardware interaction nodes. Each node type is defined with well-typed interfaces and clearly specified execution roles. Formal composition rules ensure that nodes can only be connected when interface compatibility, data-type alignment, and structural preconditions are satisfied. By extending SysML v2 with these hybrid-specific modeling elements, modularity is preserved and classical–quantum partitioning decisions become explicit, analyzable, and traceable within the workflow model. Fourth, data dependencies and interface binding are formalized to ensure full executability of the modeled workflows, which is essential for the feasibility analysis. Executable hybrid workflows require precise specification of data flow, parameter propagation, encoding and decoding steps, and intermediate transformation artifacts. QREADY therefore introduces explicit modeling constructs to represent inputs, outputs, intermediate results, and binding relationships between classical and quantum components. Type compatibility, dimensional consistency, data format alignment, and strict separation between classical and quantum data domains are validated at the model level prior to execution. By enforcing these constraints, the resulting workflow is not only structurally coherent but also executable in practice, enabling systematic feasibility assessment, performance evaluation, and backend-specific validation. 3.6.4

Running Example

The validated strategy instance in Listing 2 is transformed into the planned executable workflow model CreditRiskWorkflow_v1. This handoff is explicit: the workflow inherits the CreditRiskProblem_01 problem definition, the HybridQuantumClassical paradigm, the IterativeAmplitudeEstimation algorithm choice, the CreditLossDistributionEncoding selected for the bucketed formulation, the approvedPrivateBackend_01 backend profile, and the preliminary feasibility bounds recorded in qaeFeasibility_01. Figure 3 is an illustrative workflow view of that model, not a SysML v2 diagram. The dedicated SysML v2-based hybrid workflow notation, including graphical notations for quantum execution boundaries, hybrid loops, and evidence flows, is part of the future implementation of Q-READY . Even so, the illustrative view is consistent with the strategy instance and earlier artifacts: it realizes the probabilistic risk-estimation problem, embeds the selected probability-estimation strategy into executable control flow, uses the selected loss-distribution encoding, invokes probability-estimation actions on the approved private backend, and carries forward the QRE runtime, backend, data-protection, accuracy, and evidence-retention constraints as explicit workflow checks. The workflow first performs preparation and configuration: it loads the 10,000-loan portfolio, preprocesses the classical loss model, instantiates the CreditLossDistributionEncoding, enforces the protected-data constraint, binds the validated strategy instance, and checks whether approvedPrivateBackend_01 can satisfy the qubit, depth, shot, and runtime limits already estimated in qaeFeasibility_01. If these checks fail, the workflow rejects quantum execution or falls back to the classical benchmark. If they pass, the hybrid execution phase realizes the IterativeAmplitudeEstimation choice from Listing 2: it initializes the VaR search interval and repeatedly invokes quantum probability estimation for tail-probability queries until the VaR loop converges. The evaluation phase computes expected loss, VaR99.9, and economic capital, compares them against the classical 16

1. Load Portfolio Data

10,000 loans $1B portfolio

2. Classical Preprocessing

3. Check Protected Data Constraint

Clean data, calibrate PD/LGD/EAD, construct governed loss model

Ensure private execution requirement

4. Configure Strategy Instance

5. Check Backend Feasibility

Check qubits, depth, shots, runtime against limits

Algorithm: Iterative AE Encoding: Loss Distribution Backend: Private QPU

Expected loss, VaR99.9, Economic Capital

infeasible

not satisfied Reject Quantum Execution

10. Compute Risk Measures

feasible

Fallback to Classical Workflow

converged

VaR Search Loop (Repeat Until VaR Threshold Converges) 6. Set Initial VaR Search Bounds

Set x_low and x_high for VaR

7. Select Candidate VaR Threshold x

Classical controller selects current threshold

8. Quantum Probability Estimation Estimate exceedance probability P(Loss > x)

8a. Encode Loss Distribution into Quantum State

8b. Estimate P(Loss > x)

Input: loss distribution + threshold x

Run iterative AE on quantum backend

9. Update VaR Search Bounds

Adjust x_low / x_high using estimated P(Loss > x)

not converged

Figure 3: Illustrative Q-READY workflow view for the credit-risk running example. This is not a SysML v2 diagram; it is a reader-oriented visualization of the intended executable workflow before the dedicated SysML v2 hybrid workflow notation is implemented. Action boxes show the planned workflow steps; arrows show control, iteration, and evidence flows; and the highlighted quantum-execution region marks where encoded aggregate inputs are submitted to the quantum probability-estimation service. The workflow is aligned with the earlier artifacts: CreditRiskProblem_01 motivates probabilistic risk estimation, CreditRiskStrategy_01 provides the selected strategy configuration, and the QRE constraints reappear as protected-data, backend-feasibility, runtime, accuracy, approval, and evidence-retention checks. benchmark, and validates the 1% expected-loss error, 2% VaR error, and four-hour runtime thresholds. The governance phase records evidence for audit and reproducibility and routes the result to model-risk review, governed production use, shadow-mode use, or rejection. Thus, Figure 3 clarifies how the problem, strategy, backend, and preliminary feasibility information from Listing 2 are realized as first-class workflow behavior in the envisioned SysML v2-based notation.

3.7

Predictive Feasibility Assessment for Hybrid Quantum Workflows

3.7.1

Research Rationale

Our overall goal is to support the predictive feasibility assessment for hybrid quantum workflows, i.g., determining whether strategy instances and executable workflow models can meet resource, performance, and scalability requirements before committing to physical infrastructure or costly experimentation. Early feasibility analysis has been recognized as essential in quantum application research, where hardware access is limited and device characteristics evolve rapidly [22, 35, 32]. Studies on variational algorithms and quantum annealing have shown that performance is highly sensitive to qubit count, connectivity structure, noise levels, and circuit depth, often leading to discrepancies between theoretical promise and practical realizability [14, 56]. Hybrid computational workflows are particularly sensitive to backend characteristics such as qubit availability, coupling topology, gate duration, and stochastic noise behavior, as well as to classical optimization overhead and iterative execution dynamics reported in the literature on VQE, QAOA, and annealing-based optimization [77, 56, 47]. Q-READY addresses these challenges through a layered assessment approach that combines backend abstraction, executable workflow simulation, lightweight scaling estimation, and structured feasibility reporting. Rather than developing new simulation engines, Q-READY leverages established simulation techniques and calibrated noise models through a unified abstraction interface. This approach ensures methodological transparency, comparability across backend scenarios, and informed decision support grounded in documented challenges identified in contemporary quantum computing research. Feasibility assessment thus serves as the analytical validation layer of Q-READY . It converts executable hybrid workflows into structured, quantitative feasibility evidence using controlled simulation and lightweight scaling estimation. By separating feasibility assessment from immediate hardware availability while remaining 17

compatible with future empirical benchmarking, we ensure pragmatic evaluation and architectural adaptability. Moreover, the explicit modeling of assumptions, metrics, and constraint evaluations promotes methodological transparency, which supports educational use, knowledge transfer, and clearer communication of hybrid quantumclassical system behavior to both technical and non-expert stakeholders. 3.7.2

State of the Art

Recent years have seen increasing attention to hybrid quantum workflows as a means to structure, orchestrate, and optimize quantum–classical applications. Prior work has explored multiple dimensions of this paradigm, including workflow optimization and rewriting to improve execution efficiency [75], middleware abstraction for cross-platform deployment and reduced vendor lock-in [74], and the definition of execution patterns that guide the design and selection of workflow strategies across heterogeneous platforms [23]. In addition, pattern-driven automation has been proposed to generate and adapt workflows [12], as well as techniques to automatically derive workflow models from script-based implementations [72]. Despite these advances, existing approaches largely focus on modeling, generation, and execution optimization, while feasibility analysis remains under-explored. In particular, current works do not systematically account for critical factors such as hardware resource constraints, noise characteristics, and execution uncertainty, nor do they tightly connect workflow design to end-to-end application requirements. 3.7.3

Research Roadmap

The first task defines parametric backend abstraction models. Hardware characteristics such as qubit capacity, connectivity topology, gate durations, coherence times, error rates, and calibrated noise parameters are represented as typed properties of backend definitions. Existing noise models from platforms such as Qiskit are systematically incorporated, embedding device-level noise characterization directly into the backend abstraction rather than treating it as an external simulator setting. Parametric constraints capture relationships among these properties (e.g., qubit availability, coupling compatibility, latency and error accumulation bounds), and binding connectors relate backend parameters to workflow metrics such as circuit depth and execution time. Backend scenarios (ranging from idealized simulators to conservative near-term devices) are instantiated as concrete SysML v2 model instances with different property configurations. By separating backend specifications from workflow definitions at the model layer, this approach enables structured, technology-agnostic yet noise-aware feasibility reasoning and comparative analysis across alternative backend configurations. The second task performs predictive execution emulation directly on the executable workflow models generated in the hybrid executable workflow modeling phase (Section 3.6). The workflow engine is executed in a simulation mode, where classical control logic (iteration, branching, optimizer updates) runs as defined, while quantum execution nodes are redirected to appropriate simulators instead of physical hardware. Depending on fidelity and scale requirements, circuit evaluation may use statevector simulation for small problem instances [26], shot-based noisy simulation (e.g., calibrated noise profiles derived from Qiskit Aer [7]) for realistic device approximation, or annealing simulators for QUBO-based strategies [80]. Workflow-level metrics (e.g., circuit depth, gate counts, execution time, sampling variance, and hybrid loop convergence) are collected during emulation and bound to backend abstraction parameters defined in the first task. Doing so enables noise-aware, resource-aware predictive feasibility analysis while preserving a pluggable simulation architecture that allows different simulation engines to be incorporated without modifying the surrounding assessment pipeline. The third task focuses on deriving a small, well-defined set of resource and performance indicators directly from executable workflow simulations. During predictive execution, the workflow engine records basic metrics such as qubit count required, circuit depth, total gate count, number of circuit evaluations (shots × iterations), and total runtime per hybrid loop. These values are combined with backend parameters (e.g., gate duration and error rate) to estimate approximate execution time and cumulative error likelihood. For larger instances that cannot be fully simulated, simple scaling extrapolations based on observed trends (e.g., linear or quadratic growth with problem size) are applied. The objective is not full performance modeling, but to produce transparent, comparable feasibility indicators that support early decision-making. The final task consolidates simulation results and derived metrics into concise predictive feasibility reports. Each report summarizes key indicators such as required qubit capacity, circuit depth, estimated execution time, cumulative error exposure under calibrated noise assumptions, and observed convergence behavior. Identified constraints (e.g., qubit shortages, excessive depth, or instability under noise) are explicitly linked to corresponding strategy or workflow elements, enabling targeted refinement of configuration parameters or structural adjustments. This establishes a clear feedback loop to earlier components, supporting iterative improvement without requiring direct access to experimental hardware.

18

Table 3: Backend abstraction for the running credit-risk example

Backend property

Example value

Role in feasibility assessment

Backend type Private execution Maximum qubits Maximum circuit depth Maximum shots Connectivity model

Approved private backend Yes 80 5000 100000 Limited device connectivity Gate and readout noise Backend-specific duration Estimated / bounded latency

Defines the execution environment for probability estimation. Satisfies the protected-data restriction. Caps the encoding size for loss and comparison registers. Caps the transpiled amplitude-estimation circuit depth. Caps repeated probability-estimation calls. Affects routing overhead and effective depth.

Noise model Gate timing model Queue latency

Supports robustness and error estimation. Supports quantum execution-time estimation. Included in end-to-end runtime prediction.

Table 4: Predictive feasibility evaluation for the running credit-risk example Feasibility item

3.7.4

Predicted value

Threshold

Result

Private backend Required qubits Estimated circuit depth Estimated shots Estimated runtime Expected-loss error VaR99.9 error Noise robustness

Yes 64 3200 50000 3.5 hours 0.8% 1.5% Marginal

Pass Pass Pass Pass Pass Pass Pass Warning

Governance approval

Not yet approved

Required ≤ 80 ≤ 5000 ≤ 100000 ≤ 4 hours ≤ 1% ≤ 2% Acceptable robustness required Production approval required

Shadow mode

Running Example

Backend Abstraction. The predictive assessment starts by instantiating a backend abstraction for approvedPrivateBackend_01, the backend selected in CreditRiskStrategy_01. Table 3 makes the relevant backend assumptions explicit. The numeric limits are consistent with the strategy instance in Listing 2: private execution is required, the backend provides up to 80 qubits, supports circuit depth up to 5000, and permits up to 100000 shots for the modeled workflow. Workflow-Level Execution Simulation. The executable workflow from Section 3.6 is then evaluated in simulation mode. Consistent with the selected F2-SegmentAggregated reformulation path and the CreditLossDistributionEncoding bound in CreditRiskStrategy_01, classical actions load and preprocess the portfolio, construct the bucketed loss model, and control the VaR search loop. Quantum execution nodes on approvedPrivateBackend_01 realize the IterativeAmplitudeEstimation choice from Listing 2: one branch estimates expected loss, while the VaR loop repeatedly evaluates tail probabilities for candidate thresholds until the interval converges. The simulation records the number of calls, shots, circuit depth, runtime, and uncertainty associated with the probability estimates. Resource and Performance Estimation. Table 4 summarizes the resulting predictive evidence. The values are illustrative, but they are interpreted here as workflow-level assessment results that remain consistent with the preliminary estimates recorded earlier in qaeFeasibility_01: the workflow requires 64 qubits, estimated depth 3200, 50000 shots, 3.5 hours of runtime, 0.8% expected-loss error, and 1.5% VaR error. In other words, predictive assessment confirms that the selected F2-SegmentAggregated formulation, algorithm choice, and backend profile still satisfy the technical QRE thresholds at the workflow level, while robustness remains marked as a warning because the modeled noise margin is narrow. Feasibility Decision. The decision rule separates strategy-level validation, workflow-level technical feasibility, and production approval. In the running example, CreditRiskStrategy_01 had already been validated at the configuration stage, and the predictive assessment now confirms that the resulting workflow still satisfies the modeled resource, runtime, privacy, and accuracy constraints under the selected backend assumptions. The marginal robustness result is retained as a technical warning flag, but it does not by itself determine the operational disposition. However, the workflow is not yet approved for production because model-risk governance approval has not been granted. The resulting operational decision is therefore shadow mode: the quantum workflow may be retained as a governed research workflow and compared against the classical benchmark, while the classical result remains authoritative for reporting.

19

Table 5: Cross-phase traceability of the running credit-risk example. Phase

Primary artifact

Selected running-example content

Carried forward

Quantum Requirements Modeling

QRE model

Runtime, privacy, backend, and accuracy obligations that constrain later design choices

Guided Problem Structuring

CreditRiskProblem_01

Strategy Configuration & Instantiation

CreditRiskStrategy_01

Hybrid Executable Workflow Modeling

CreditRiskWorkflow_v1

Predictive Feasibility Assessment

Feasibility evidence and governance outcome

projectContext, businessGoal, operational/resource constraints, success criteria for quarterly credit-portfolio capital assessment Probabilistic risk-estimation problem with selected F2-SegmentAggregated bucketed reformulation; F1-FacilityLevel and F3-HardwarePilot retained as alternatives HybridQuantumClassical paradigm, IterativeAmplitudeEstimation, CreditLossDistributionEncoding, approvedPrivateBackend_01, qaeFeasibility_01 Workflow view with protected-data checks, backend-feasibility checks, repeated probability-estimation calls in the VaR loop, benchmark comparison, fallback, and evidence retention Backend abstraction, workflow-level metrics, resource/performance table, robustness warning, shadow-mode decision

Problem type, structuring objective, and chosen bucketed lossdistribution path

Selected algorithm, encoding, backend, and preliminary feasibility bounds

Executable control flow and measurable workflow-level behavior for assessment

Early governed decision on technical feasibility versus production approval

Table 6: Feasibility decision outcomes for hybrid quantum-classical workflow assessment

Outcome

Decision condition

Approved for production

Hard constraints pass, robustness is acceptable, and model-risk governance approval is granted. Hard constraints pass, but production approval is still pending. This is the runningexample outcome. At least one hard constraint fails, such as privacy, qubits, depth, shots, runtime, or estimation error. Robustness is marginal under the selected backend or noise model and may accompany shadow mode.

Shadow mode Rejected / reconfigure Technical warning flag

3.8

Running Example Synthesis

The running example illustrates how Q-READY maintains continuity across requirements, problem structuring, strategy configuration, workflow modeling, and feasibility assessment. Table 5 makes these connections explicit by showing how each phase contributes one concrete artifact to the next. The QRE model first captures the domain context, business goal, operational constraints, resource constraints, and success criteria for the quarterly 10,000-loan, $1 billion credit-portfolio assessment. Guided problem structuring then turns these requirements into CreditRiskProblem_01, a probabilistic risk-estimation problem whose objective is correlated probabilistic simulation plus tail-risk estimation, rather than generic optimization. The reformulation step identifies F2-SegmentAggregated as the selected candidate while keeping F1-FacilityLevel and F3-HardwarePilot explicit as alternatives. Strategy configuration then creates CreditRiskStrategy_01, which binds the structured problem to a hybrid quantum-classical paradigm, iterative amplitude estimation, CreditLossDistributionEncoding, approvedPrivateBackend_01, and the feasibility estimates recorded in qaeFeasibility_01. The workflow step sketches the intended CreditRiskWorkflow_v1 as an illustrative workflow view rather than as a finalized SysML v2 workflow diagram; it shows the behavior that the future hybrid workflow notation must capture, including protected-data handling, backend feasibility checks, repeated VaR-loop probability-estimation calls, benchmark comparison, fallback, and evidence retention. Predictive feasibility assessment then evaluates the workflow against the same QRE thresholds and backend limits. The resulting decision is deliberately more precise than saying that quantum risk analysis is simply promising. The bucketed hybrid workflow satisfies the modeled hard constraints: private execution, 64 required qubits against an 80-qubit limit, circuit depth 3200 against a 5000-depth limit, 50000 shots against a 100000-shot limit, 3.5 hours against the four-hour runtime target, 0.8% expected-loss error, and 1.5% VaR99.9 error. However, the noise robustness margin remains a warning and model-risk governance approval has not yet been granted. The workflow is therefore retained in shadow mode while the classical benchmark remains authoritative for production reporting. Table 6 summarizes the decision outcomes used in this final assessment step. In the running credit-risk example, the shadow-mode path applies: resource, runtime, accuracy, and privacy checks pass, but robustness remains a warning and model-risk20 governance approval is still pending. This is the kind of early, traceable engineering decision that Q-READY aims to support before a bank commits governed data, infrastructure, and validation effort.

4

Conclusion

Q-READY represents a forward-looking vision for engineering hybrid quantum–classical applications through predictive feasibility assessment. Grounded in established MBSE practice and supported by MDE techniques, including mature standards, tools, and best practices, it aims to systematically bridge requirements, system design, and execution considerations within a unified modeling framework. By leveraging proven methodologies from classical software and systems engineering, incorporating emerging knowledge from Quantum Software Engineering (QSE), and integrating quantum computing foundations such as noise models, backend characterization, and quantum simulation, Q-READY seeks to enable informed decision-making prior to implementation. The running credit-portfolio example illustrates why this traceability matters. The same application concern is carried from quantum-aware requirements, to a probabilistic risk-estimation problem model, to a validated strategy instance, to an illustrative workflow view, and finally to predictive feasibility evidence. The resulting decision is not a generic claim of quantum advantage, but a governed engineering outcome: the bucketed hybrid workflow is technically feasible under the modeled resource, runtime, privacy, and accuracy constraints, yet remains in shadow mode because robustness is marginal and model-risk approval is pending. This example shows how Q-READY can support early, auditable decisions before organizations commit sensitive data, infrastructure, and validation effort. Ultimately, Q-READY aspires to support the development of robust, scalable, and resource-aware hybrid quantum applications in the NISQ era and beyond.

References [1] 2025. Kernel Modeling Language (KerML), Version 1.0. OMG Specification. Object Management Group. https://www.omg.org/spec/KerML/1.0 [2] 2025. OMG Systems Modeling Language (SysML), Version 2.0. OMG Specification. Object Management Group. https://www.omg.org/spec/SysML/2.0 [3] Amira Abbas, David Sutter, Christa Zoufal, Aurelien Lucchi, Alessio Figalli, and Stefan Woerner. 2021. The Power of Quantum Neural Networks. Nature Computational Science 1 (2021), 403--409. [4] Shaukat Ali and Tao Yue. 2020. Modeling Quantum Programs: Challenges, Initial Results, and Research Directions. In Proceedings of the 1st ACM SIGSOFT International Workshop on Architectures and Paradigms for Engineering Quantum Software. 14--21. [5] Shaukat Ali, Tao Yue, and Rui Abreu. 2022. When Software Engineering Meets Quantum Computing. Commun. ACM 65, 4 (2022), 84--88. [6] Matthew S. Anis et al. 2021. Qiskit: An Open-source Framework for Quantum Computing. (2021). doi:10.5281/zenodo.2573505 [7] Petr S Anisimov et al. 2021. Qiskit Aer: A High Performance Simulator Framework for Quantum Circuits. arXiv preprint arXiv:2101.11065 (2021). arXiv:2101.11065 [8] Frank Arute et al. 2019. Quantum Supremacy Using a Programmable Superconducting Processor. Nature 574 (2019), 505--510. doi:10.1038/s41586-019-1666-5 [9] Atos. 2026. Atos Quantum Learning Machine (QLM). https://atos.net/en/solutions/quantum-computing. [10] Ryan Babbush, Robbie King, Sergio Boixo, William Huggins, Tanuj Khattar, Guang Hao Low, Jarrod R McClean, Thomas O’Brien, and Nicholas C Rubin. 2025. The Grand Challenge of Quantum Applications. arXiv preprint arXiv:2511.09124 (2025). arXiv:2511.09124 [11] Saikat Basu, Amit Saha, Amlan Chakrabarti, and Susmita Sur-Kolay. 2022. I-QER: An Intelligent Approach Towards Quantum Error Reduction. ACM Transactions on Quantum Computing 3, 4, Article 23 (jul 2022), 18 pages. doi:10.1145/3539613 [12] Martin Beisel, Johanna Barzen, Frank Leymann, Lavinia Stiliadou, Daniel Vietz, and Benjamin Weder. 2025. Pattern-based Generation and Adaptation of Quantum Workflows. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 3072--3084. doi:10.1109/ICSE55347.2025.00196 [13] Kishor Bharti et al. 2022. Noisy Intermediate-Scale Quantum Algorithms. Reviews of Modern Physics 94, 1 (2022), 015004. doi:10.1103/RevModPhys.94.015004

21

[14] Giuseppe Buonaiuto, Francesco Gargiulo, Giuseppe De Pietro, Massimo Esposito, and Marco Pota. 2024. The Effects of Quantum Hardware Properties on the Performances of Variational Quantum Learning Algorithms. Quantum Machine Intelligence 6, 1 (2024), 9. [15] Marco Cerezo et al. 2021. Variational Quantum Algorithms. Nature Reviews Physics 3, 9 (2021), 625--644. [16] Dassault Systèmes. 2026. CATIA SysML v2. https://www.3ds.com/products/catia/catia-sysml-v2 Accessed: 2026-06-07. [17] Pierre De Saqui-Sannes, Rob A Vingerhoeds, Christophe Garion, and Xavier Thirioux. 2022. A taxonomy of MBSE approaches by languages, tools and methods. IEEE Access 10 (2022), 120936--120950. [18] Felice De Stefano et al. 2023. Software Engineering for Quantum Computing: Theoretical and Industrial Perspectives. ACM Transactions on Software Engineering and Methodology (2023). doi:10.1145/3593450 [19] Menghan Dou, Tianrui Zou, Yuan Fang, Jing Wang, Dongyi Zhao, Lei Yu, Boying Chen, Wenbo Guo, Ye Li, Zhaoyun Chen, et al. 2022. QPanda: High-Performance Quantum Computing Framework for Multiple Application Scenarios. arXiv preprint arXiv:2212.14201 (2022). arXiv:2212.14201 [20] Daniel J. Egger, Ricardo García Gutiérrez, Jordi Cahué Mestre, and Stefan Woerner. 2021. Credit Risk Analysis Using Quantum Computers. IEEE Trans. Comput. 70, 12 (2021), 2136--2145. doi:10.1109/TC.2 020.3038063 [21] Xiang Fu, Jintao Yu, Xing Su, Hanru Jiang, Hua Wu, Fucheng Cheng, Xi Deng, Jinrong Zhang, Lei Jin, Yihang Yang, et al. 2021. Quingo: A Programming Framework for Heterogeneous Quantum-Classical Computing with NISQ Features. ACM Transactions on Quantum Computing 2, 4 (2021), 1--37. [22] Felix Gemeinhardt, Antonio Garmendia, and Manuel Wimmer. 2021. Towards Model-Driven Quantum Software Engineering. In 2021 IEEE/ACM 2nd International Workshop on Quantum Software Engineering (Q-SE). 13--15. doi:10.1109/Q-SE52541.2021.00010 [23] Daniel Georg, Johanna Barzen, Martin Beisel, Frank Leymann, Julian Obst, Daniel Vietz, Benjamin Weder, and Vladimir Yussupov. 2023. Execution Patterns for Quantum Applications.. In ICSOFT. 258--268. [24] Sukhpal Singh Gill et al. 2022. Quantum Cloud Computing: Issues, Challenges and Future Directions. Software: Practice and Experience 52, 10 (2022), 2111--2146. doi:10.1002/spe.3039 [25] Fred Glover et al. 2018. A Tutorial on Formulating and Using QUBO Models. arXiv:1811.11538 (2018). arXiv:1811.11538

arXiv preprint

[26] Gian Giacomo Guerreschi, Justin Hogaboam, Ferran Garcia-Saez, Alberto Peruzzo, and Rolando D Somma. 2020. Intel Quantum Simulator: A High-Performance Simulator for Quantum Circuits. Quantum Science and Technology 5, 3 (2020), 034007. [27] Xiaoyu Guo, Shinobu Saito, and Jianjun Zhao. 2025. QuanUML: Towards a modeling language for modeldriven quantum software development. In 2025 IEEE 49th Annual Computers, Software, and Applications Conference (COMPSAC). IEEE, 1344--1349. [28] Christian Habermehl, Gregor Höpfner, Jörg Berroth, Stephan Neumann, and Georg Jacobs. 2022. Optimization workflows for linking model-based systems engineering (MBSE) and multidisciplinary analysis and optimization (MDAO). Applied Sciences 12, 11 (2022), 5316. [29] Tuna Hacaloglu, Hassan Soubra, and Pierre Bourque. 2024. Exploratory Review of Quantum Computing Software Requirements Specification and Their Measurement. IWSM-Mensura (2024). [30] Thomas Häner and Damian S. Steiger. 2018. A Software Methodology for Compiling Quantum Programs. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC). IEEE, 1--10. [31] INCOSE. 2023. INCOSE Systems Engineering Handbook. John Wiley & Sons. [32] Ishraq Islam, Vinayak Jha, Alvir Nobel, David Levy, Manu Chaudhary, Dylan Kneidel, Audrey Facer, and Esam El-Araby. 2025. Evaluating Cost-Effective Reconfigurable Hardware for Quantum Simulation. In Grid, Cloud, and Cluster Computing; Quantum Technologies; and Modeling, Simulation and Visualization Methods, Hamid R. Arabnia, Masami Takata, Leonidas Deligiannidis, Pablo Rivas, Masahito Ohue, and Nobuaki Yasuo (Eds.). Springer Nature Switzerland, Cham, 57--68.

22

[33] J. R. Johansson, P. D. Nation, and Franco Nori. 2012. QuTiP: An open-source Python framework for the dynamics of open quantum systems. Computer Physics Communications 183, 8 (2012), 1760--1772. [34] J. R. Johansson, P. D. Nation, and Franco Nori. 2013. QuTiP 2: A Python framework for the dynamics of open quantum systems. Computer Physics Communications 184, 4 (2013), 1234--1240. [35] Srikar Kasi, Paul Warburton, John Kaewell, and Kyle Jamieson. 2023. A Cost and Power Feasibility Analysis of Quantum Annealing for NextG Cellular Wireless Networks. IEEE Transactions on Quantum Engineering 4 (2023), 1--17. doi:10.1109/TQE.2023.3326469 [36] Serdar Kinay, Ufuk Bolat, Buse Yakin Gökdemir, Kaan Babacan, Namik Zengin, and Erhan Özkaya. 2024. Advancing MBSE for ADAS/AD: automated scenario generation. In 2024 IEEE/SICE International Symposium on System Integration (SII). IEEE, 1583--1588. [37] Janusz Kusyk, Samah M. Saeed, and Muharrem Umit Uyar. 2021. Survey on Quantum Circuit Compilation for Noisy Intermediate-Scale Quantum Computers: Artificial Intelligence to Heuristics. IEEE Transactions on Quantum Engineering 2 (2021), 1--16. doi:10.1109/TQE.2021.3068355 [38] Ryan LaRose. 2019. Overview and Comparison of Gate Level Quantum Software Platforms. Quantum 3 (2019), 130. [39] Marco Lewis, Sadegh Soudjani, and Paolo Zuliani. 2023. Formal Verification of Quantum Programs: Theory, Tools, and Challenges. ACM Transactions on Quantum Computing 5, 1 (2023), 1--35. [40] Marco Lewis, Sadegh Soudjani, and Paolo Zuliani. 2023. Formal verification of quantum programs: Theory, tools, and challenges. ACM Transactions on Quantum Computing 5, 1 (2023), 1--35. [41] Frank Leymann. 2019. Towards a Pattern Language for Quantum Algorithms. In International Workshop on Quantum Technology and Optimization Problems. Springer, 218--230. [42] Frank Leymann and Johanna Linke. 2020. The Bitter Truth About Quantum Algorithms in the NISQ Era. Quantum Science and Technology (2020). [43] Yuechen Li, Kai-Yuan Cai, and Beibei Yin. 2026. A Dynamic Test Oracle for Quantum Programs with Separable Output States. IEEE Transactions on Software Engineering (2026). [44] Hong Lu, Shuai Wang, Tao Yue, Jan F Nygård, et al. 2017. Automated refactoring of OCL constraints with search. IEEE Transactions on Software Engineering 45, 2 (2017), 148--170. [45] Andrew Lucas. 2014. Ising Formulations of Many NP Problems. Frontiers in Physics 2 (2014), 5. doi:10.3389/fphy.2014.00005 [46] Javier Mancilla and Christophe Pere. 2022. A Preprocessing Perspective for Quantum Machine Learning Classification Advantage in Finance Using Nisq Algorithms. Entropy 24, 11 (2022), 1656. [47] Alexander J. McCaskey, Thien Nguyen, Dmitry Lyakh, et al. 2021. Composable Programming of Hybrid Workflows for Quantum Simulation. New Journal of Physics 23, 2 (2021), 023013. [48] Enaut Mendiluze, Shaukat Ali, Paolo Arcaini, and Tao Yue. 2021. Muskit: A Mutation Analysis Tool for Quantum Software Testing. In 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1266--1270. [49] Enrique Moguel, Javier Rojo, David Valencia, Javier Berrocal, Jose Garcia-Alonso, and Juan M Murillo. 2022. Quantum service-oriented computing: current landscape and challenges. Software Quality Journal 30, 4 (2022), 983--1002. [50] Asmar Muqeet, Tao Yue, Shaukat Ali, and Paolo Arcaini. 2024. Mitigating Noise in Quantum Software Testing Using Machine Learning. IEEE Transactions on Software Engineering 50, 11 (2024), 2947--2961. [51] Juan M Murillo, Jose Garcia-Alonso, Enrique Moguel, Johanna Barzen, Frank Leymann, Shaukat Ali, Tao Yue, Paolo Arcaini, et al. 2025. Quantum Software Engineering: Roadmap and Challenges Ahead. ACM Transactions on Software Engineering and Methodology 34, 5 (2025). [52] Noah Oldfield, Tao Yue, and Shaukat Ali. 2022. Investigating Quantum Cause-Effect Graphs. In Proceedings of the 3rd International Workshop on Quantum Software Engineering. 8--15. [53] Noah H Oldfield, Christoph Laaber, Tao Yue, and Shaukat Ali. 2025. Faster and Better Quantum Software Testing through Specification Reduction and Projective Measurements. ACM Transactions on Software Engineering and Methodology 34, 7 (2025), 1--39. 23

[54] Alexandru Paler, Lucian Sasu, Adrian-Cătălin Florea, and Răzvan Andonie. 2023. Machine Learning Optimization of Quantum Circuit Layouts. ACM Transactions on Quantum Computing 4, 2, Article 12 (feb 2023), 25 pages. doi:10.1145/3565271 [55] J. Pauckert et al. 2025. LLM-QUBO: An End-to-End Framework for Automated QUBO Transformation from Natural Language Problem Descriptions. In AAAI 2025 Spring Symposium Series. [56] Aidan Pellow-Jarman, Shane McFarthing, Ilya Sinayskiy, Daniel K Park, Anban Pillay, and Francesco Petruccione. 2024. The Effect of Classical Optimizers and Ansatz Depth on QAOA Performance in Noisy Devices. Scientific reports 14, 1 (2024), 16011. [57] PennyLane Developers. 2023. PennyLane: A cross-platform Python library for quantum machine learning. https://pennylane.ai/ [58] Ricardo Pérez-Castillo and Mario Piattini. 2022. Design of classical-quantum systems with UML. Computing 104, 11 (2022), 2375--2403. [59] Mauro Pezzè, Silvia Abrahão, Birgit Penzenstadler, Denys Poshyvanyk, Abhik Roychoudhury, and Tao Yue. 2025. A 2030 roadmap for software engineering. ACM Transactions on Software Engineering and Methodology 34, 5 (2025), 1--55. [60] Frank Phillipson, Niels Neumann, and Robert Wezeman. 2023. Classification of Hybrid Quantum-Classical Computing. In International Conference on Computational Science. Springer, 18--33. [61] John Preskill. 2018. Quantum Computing in the NISQ Era and Beyond. Quantum 2 (2018), 79. doi:10.2 2331/q-2018-08-06-79 [62] QuTech. 2026. Mission-Driven Quantum Research Ecosystem. https://qutech.nl/. [63] QuTiP Developers. 2023. QuTiP: Quantum Toolbox in Python. https://qutip.org/ [64] Stephen Resch and Ulya R. Karpuzcu. 2019. Quantum Computing in the Cloud: Now and Next. IEEE Cloud Computing 6, 3 (2019), 12--23. doi:10.1109/MCC.2019.2926715 [65] Lorenzo Saraiva, Edward Hermann Haeusler, Vaston G Costa, and Marcos Kalinowski. 2021. Non-Functional Requirements for Quantum Programs.. In Q-SET@ QCE. 89--73. [66] Hassan Sartaj, Muhammad Zohaib Iqbal, Atif Aftab Ahmed Jilani, and Muhammad Uzair Khan. 2025. Search-Based MC/DC Test Data Generation With OCL Constraints. Software Testing, Verification and Reliability 35, 1 (2025), e1906. [67] Peter Selinger. 2004. Towards a Quantum Programming Language. Mathematical. Structures in Comp. Sci. 14, 4 (aug 2004), 527–586. doi:10.1017/S0960129504004256 [68] Samuel Sepulveda, Ania Cravero, Guillermo Fonseca, and Leandro Antonelli. 2024. Systematic Review on Requirements Engineering in Quantum Computing: Insights and Future Directions. Electronics 13, 15 (2024), 2989. [69] Paola Spoletini. 2023. Towards quantum requirements engineering. In 2023 IEEE 31st International Requirements Engineering Conference Workshops (REW). IEEE, 371--374. [70] Friedrich Steimann, Robert Clarisó, and Martin Gogolla. 2025. Meet OCL#, a relational object constraint language. Software and Systems Modeling (2025), 1--25. [71] Krysta M. Svore et al. 2018. Q#: Enabling Scalable Quantum Computing and Development. arXiv preprint arXiv:1803.00652 (2018). arXiv:1803.00652 [72] Daniel Vietz, Johanna Barzen, Frank Leymann, and Benjamin Weder. 2022. Splitting quantum-classical scripts for the generation of quantum workflows. In International Conference on Enterprise Design, Operations, and Computing. Springer, 255--270. [73] Xinyi Wang, Asmar Muqeet, Tao Yue, Shaukat Ali, and Paolo Arcaini. 2024. Test Case Minimization with Quantum Annealers. ACM Transactions on Software Engineering and Methodology 34, 1 (2024), 1--24. [74] Benjamin Weder, Johanna Barzen, Martin Beisel, Fabian Bühler, Daniel Georg, Frank Leymann, and Lavinia Stiliadou. 2025. Qunicorn: a middleware for the unified execution across heterogeneous quantum cloud offerings. In 2025 IEEE/ACM International Workshop on Quantum Software Engineering (Q-SE). IEEE, 17--24. 24

[75] Benjamin Weder, Johanna Barzen, and Frank Leymann. 2022. Analysis and Rewrite of Quantum Workflows: Improving the Execution of Hybrid Quantum Algorithms. In Proceedings of the 19th International Conference on Quantum Physics and Logic (QPL) / or ICQSME depending on venue formatting. SciTePress, 1--12. https://www.scitepress.org/Papers/2022/110351/110351.pdf [76] Benjamin Weder, Johanna Barzen, Frank Leymann, and Daniel Vietz. 2022. Quantum Software Development Lifecycle. In Quantum Software Engineering. Springer, 61--83. doi:10.1007/978-3-031-05324-5_4 [77] Benjamin Weder, Johanna Barzen, Frank Leymann, and Michael Zimmermann. 2021. Hybrid Quantum Applications Need Two Orchestrations in Superposition: A Software Architecture Perspective. In 2021 IEEE International Conference on Web Services (ICWS). 1--13. doi:10.1109/ICWS53863.2021.00015 [78] Robert Wille, Stefan Hillmich, and Lukas Burgholzer. 2022. Decision diagrams for quantum computing. In Design Automation of Quantum Computers. Springer, 1--23. [79] Stefan Woerner and Daniel J. Egger. 2019. Quantum Risk Analysis. npj Quantum Information 5, 1 (2019), 15. doi:10.1038/s41534-019-0130-6 [80] Sheir Yarkoni, Elena Raponi, Thomas Bäck, and Sebastian Schmitt. 2022. Quantum Annealing for Industry Applications: Introduction and Review. Reports on Progress in Physics 85, 10 (2022), 104001. [81] Jun Ye and Jun Yong Khoo. 2026. EmuPlat: A Framework-Agnostic Platform for Quantum Hardware Emulation with Validated Transpiler-to-Pulse Pipeline. In Proceedings of the Supercomputing Asia and International Conference on High Performance Computing in Asia Pacific Region. 10--18. [82] Tao Yue, Shaukat Ali, and Paolo Arcaini. 2023. Towards Quantum Software Requirements Engineering. In 2023 IEEE International Conference on Quantum Computing and Engineering (QCE), Vol. 2. IEEE, 161--164. [83] Man Zhang, Yunyang Li, and Tao Yue. 2026. LLMs for Model-driven Engineering: A Survey. doi:10.528 1/zenodo.19387475 [84] Man Zhang, Yuechen Li, Tao Yue, and Kai-Yuan Cai. 2025. Empirical Studies on Quantum Optimization for Software Engineering: A Systematic Analysis. arXiv preprint arXiv:2510.27113 (2025). arXiv:2510.27113 [85] Man Zhang, Yuechen Li, Tao Yue, and Kai-Yuan Cai. 2026. Quantum Optimization for Software Engineering: A Survey. ACM Trans. Softw. Eng. Methodol. (May 2026). doi:10.1145/3816147 Just Accepted. [86] Alwin Zulehner, Stefan Hillmich, and Robert Wille. 2019. How to Efficiently Handle Complex Values? Implementing Decision Diagrams for Quantum Computing. International Conference on Computer Aided Design (ICCAD) (2019).

25

Related documents

• Experimental Settings in LLM-Based Program Repair: A Study of Inputs, Tool Access, Feedback, and Validation#965480
• A11yLTLNav: Automatic Detection of Accessibility Navigation Failures#965481
• Detecting Argument-Swap Bugs Using Context-Enhanced Code Representations#965482
• A Large-Scale Empirical Study of Quality Assurance Practices and Gaps in AI Agents#965483
• CARE: A Responsibility-Oriented Architecture for Domain-Scoped Resolution in Modular and Upgradeable Smart Contracts#965484