From e3352547455eb544aec17c4d1c32e076f8c41eea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Wed, 30 Jul 2025 11:08:34 +0200 Subject: [PATCH 01/23] Create 0023-low-level-sampler.md --- 0023-low-level-sampler.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 0023-low-level-sampler.md diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/0023-low-level-sampler.md @@ -0,0 +1 @@ + From 64054de190750ee24d5fff3afe183b1bc1a89141 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Wed, 30 Jul 2025 12:55:07 +0200 Subject: [PATCH 02/23] Update 0023-low-level-sampler.md Drafting the initial justification. --- 0023-low-level-sampler.md | 79 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index 8b13789..bf2bbc9 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -1 +1,80 @@ +# Low level sampler +| **Status** | **Proposed/Accepted/Deprecated** | +|:------------------|:---------------------------------------------| +| **RFC #** | 0023 | +| **Authors** | Salva de la Puente (salva@ibm.com), Antonio Corcole, Ian Hincks | +| **Deprecates** | TBD | +| **Submitted** | 2025-07-30 | +| **Updated** | YYYY-MM-DD | + +## Summary + +In Qiskit, the quantum computer interface is built around primitives, which are +the fundamental operations executable on a quantum circuit. Currently, Qiskit offers +two such primitives: the Sampler and the Estimator. The Estimator leverages advanced +error mitigation techniques to enhance the quality of results from noisy quantum +computers. On a noiseless quantum computer, the Estimator could instead be constructed +atop the Sampler, simplifying its role. However, given current noise levels, robust +error mitigation is essential, requiring extensive profiling through thousands or even +millions of circuit variations. Transmitting these variations across cloud environments +is inefficient, but this can be optimized using a "samplex" a domain-specific language +(DSL) program describing the way of producint these variations. The samplex enables +efficient server-side generation of variations, with results transmitted back as samples +accompanied by metadata, facilitating client-side implementation of error-mitigated +estimations. + +## Motivation +- Why are we doing this? + +We are pursuing this development to address the growing demand within the quantum information science community for advanced error mitigation techniques. Users and researchers seek finer control over these techniques to improve the reliability of quantum computations, especially on noisy quantum hardware. Vendors like IBM have identified that users desire capabilities for precise noise learning, twirling, and expectation value calculations. By optimizing the process with tools like the "samplex" DSL, we can enhance efficiency in generating circuit variations server-side, reduce data transmission overhead, and support robust client-side error-mitigated estimations. This approach ultimately aims to deliver higher-quality quantum computing results while meeting the sophisticated needs of the community. + +- What will this enable? +- What will be the outcome? +- Who will benefit? + +## User Benefit +- Who are the target users of this work? +- How will users or contributors benefit from the work proposed? + +## Design Proposal +This is the focus of the document. Explain the proposal from the perspective of +educating another user on the proposed features. + +This generally means: +- Introducing new concepts and nomenclature +- Using examples to introduce new features +- Implementation and Migration path with associated concerns +- Communication of features and changes to users + +Focus on giving an overview of impact of the proposed changes to the target +audience. + +Factors to consider: +- Performance +- Dependencies +- Maintenance +- Compatibility + +## Detailed Design +Technical reference level design. Elaborate on details such as: +- Implementation procedure + - If spans multiple projects cover these parts individually +- Interaction with other features +- Dissecting corner cases +- Reference definition, eg., formal definitions. + +## Alternative Approaches +Discuss other approaches to solving this problem and why these were not +selected. + +## Questions +Open questions for discussion and an opening for feedback. + +## Future Extensions +Consider what extensions might spawn from this RFC. Discuss the roadmap of +related projects and how these might interact. This section is also an opening +for discussions and a great place to dump ideas. + +If you do not have any future extensions in mind, state that you cannot think +of anything. This section should not be left blank. From bf0e26e5e4775e4ba75fa951f5be69b8512220dc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Sun, 3 Aug 2025 12:11:43 +0200 Subject: [PATCH 03/23] Complete non-technical sections --- 0023-low-level-sampler.md | 121 ++++++++++++++++++++++++++++++-------- 1 file changed, 95 insertions(+), 26 deletions(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index bf2bbc9..902127f 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -9,33 +9,69 @@ | **Updated** | YYYY-MM-DD | ## Summary - In Qiskit, the quantum computer interface is built around primitives, which are -the fundamental operations executable on a quantum circuit. Currently, Qiskit offers -two such primitives: the Sampler and the Estimator. The Estimator leverages advanced -error mitigation techniques to enhance the quality of results from noisy quantum -computers. On a noiseless quantum computer, the Estimator could instead be constructed -atop the Sampler, simplifying its role. However, given current noise levels, robust -error mitigation is essential, requiring extensive profiling through thousands or even -millions of circuit variations. Transmitting these variations across cloud environments -is inefficient, but this can be optimized using a "samplex" a domain-specific language -(DSL) program describing the way of producint these variations. The samplex enables -efficient server-side generation of variations, with results transmitted back as samples -accompanied by metadata, facilitating client-side implementation of error-mitigated -estimations. +the fundamental operations executable on a quantum circuit. Currently, Qiskit +offers two such primitives: the Sampler and the Estimator. The Estimator +leverages advanced error mitigation techniques to enhance the quality of +results from noisy quantum computers. On a noiseless quantum computer, the +Estimator could instead be constructed atop the Sampler, simplifying its role. +However, given current noise levels, robust error mitigation is essential, +requiring extensive profiling through thousands or even millions of circuit +variations. Transmitting these variations across cloud environments is +inefficient, but this can be optimized using a "samplex" — a domain-specific +language (DSL) program describing the way of producing these variations. The +samplex enables efficient server-side generation of variations, with results +transmitted back as samples accompanied by metadata, facilitating client-side +implementation of error-mitigated estimations. ## Motivation -- Why are we doing this? +The purpose of this development is addressing the growing demand within the +quantum information science community for advanced error mitigation techniques. +Users and researchers seek finer control over these techniques to improve the +reliability of quantum computations, especially on noisy quantum hardware. +Vendors like IBM have identified that users desire capabilities for precise +noise learning, twirling, and expectation value calculations. -We are pursuing this development to address the growing demand within the quantum information science community for advanced error mitigation techniques. Users and researchers seek finer control over these techniques to improve the reliability of quantum computations, especially on noisy quantum hardware. Vendors like IBM have identified that users desire capabilities for precise noise learning, twirling, and expectation value calculations. By optimizing the process with tools like the "samplex" DSL, we can enhance efficiency in generating circuit variations server-side, reduce data transmission overhead, and support robust client-side error-mitigated estimations. This approach ultimately aims to deliver higher-quality quantum computing results while meeting the sophisticated needs of the community. - What will this enable? -- What will be the outcome? -- Who will benefit? +This proposal will enable Qiskit users to perform large-scale, backend-optimized +error mitigation experiments without incurring the high network cost of +transmitting thousands or millions of circuit variations. By shifting variation +generation to the backend through a portable DSL, researchers can run advanced +techniques such as randomized compiling, Pauli or Clifford twirling, and noise +learning more efficiently. The approach preserves reproducibility via +deterministic seeds and structured metadata, while also allowing backend- +specific optimizations that remain compatible across vendors. + +Today, Qiskit users can already run large-scale error mitigation experiments, +but the process is **implicit** — it is difficult to explain and difficult to +compose, and users have no direct control over how circuit variations are +generated or how mitigation is applied. This proposal introduces the **samplex** +DSL, a portable description language that lets users explicitly define the +variation strategies applied by the backend. + +With this, researchers can tailor error mitigation to their needs, choosing, +for example, the specific forms of Pauli or Clifford twirling, or noise learning to +apply. The approach preserves backend optimizations while giving users fine-grained +control, reproducibility through deterministic seeds, and access to structured +metadata for postprocessing. ## User Benefit -- Who are the target users of this work? -- How will users or contributors benefit from the work proposed? +This proposal will primarily benefit researchers and practitioners working with +noisy quantum hardware who require precise control over error mitigation +strategies. By making the variation generation process explicit and +user-definable, it empowers users to explore and tune novel error mitigation +techniques. + +Backend and platform developers will also benefit, as the **samplex** DSL +creates a standard interface for describing variation strategies that can be +implemented consistently across vendors. This improves portability, reduces +vendor lock-in, and enables backends to apply optimizations without sacrificing +user intent. + +Finally, the broader Qiskit community, including educators and tool developers, +will gain a clearer and more composable model for error mitigation workflows, +making it easier to experiment, reproduce results, and share techniques. ## Design Proposal This is the focus of the document. Explain the proposal from the perspective of @@ -65,16 +101,49 @@ Technical reference level design. Elaborate on details such as: - Reference definition, eg., formal definitions. ## Alternative Approaches -Discuss other approaches to solving this problem and why these were not -selected. +An alternative to introducing the **samplex** DSL is to generate all circuit +variations entirely on the client side and transmit them to the backend for +execution. This approach offers maximum flexibility and complete control over +how variations are produced, since the backend would simply execute the +provided circuits without influencing their structure. Users could implement +any custom error mitigation workflow they wish, with no restrictions imposed by +backend capabilities or vendor‑specific optimizations. + +However, this approach has significant drawbacks. Large‑scale error mitigation +often requires thousands or even millions of circuit variations, making +client‑side generation impractical for real‑world workloads. Transmitting such a +large volume of circuits over the network introduces high latency, increases +execution time, and places substantial demands on both client and backend +infrastructure. It also complicates reproducibility across vendors, since each +vendor may handle large‑batch execution differently. + +By contrast, the **samplex** DSL allows users to describe their variation +generation strategies in a portable, serialized form that can be transmitted +efficiently. The backend can then expand these strategies into actual circuit +variations locally, reducing network load while preserving user control over +error mitigation techniques. ## Questions Open questions for discussion and an opening for feedback. +TBD ## Future Extensions -Consider what extensions might spawn from this RFC. Discuss the roadmap of -related projects and how these might interact. This section is also an opening -for discussions and a great place to dump ideas. -If you do not have any future extensions in mind, state that you cannot think -of anything. This section should not be left blank. +The introduction of a low‑level sampler is only the first step. The long‑term +goal is to evolve Qiskit’s compute model toward accepting a single, unified +operation—this primitive—potentially deprecating the current definition of +primitives altogether. In this model, noise learning, error mitigation, and any +other computation could be implemented directly on top of the unified primitive +abstraction. + +Future RFCs may explore implementing advanced workflows such as noise learning +natively within this computation model, as well as replacing Qiskit’s existing +compute interface with the unified approach. This shift would simplify the +execution pipeline, make workflows more composable, and provide a consistent +foundation for new quantum algorithms and techniques. + +Additional future work could explore defining domain‑specific languages beyond +**samplex**, including DSLs dedicated to calculating expectation values or +other specialized tasks. These DSLs could be layered on top of the unified +primitive to further extend Qiskit’s flexibility and expressiveness while +retaining backend portability. \ No newline at end of file From 9fe8af6d550573d553459082816296f3b17e5002 Mon Sep 17 00:00:00 2001 From: SALVADOR DE LA PUENTE Date: Thu, 14 Aug 2025 17:00:02 -0400 Subject: [PATCH 04/23] Preliminar draft to implementing estimator on top of the low level sampler. --- 0023-low-level-sampler.md | 98 ++++++++++++++++++++++++++++++--------- 1 file changed, 76 insertions(+), 22 deletions(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index 902127f..90f139e 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -74,31 +74,85 @@ will gain a clearer and more composable model for error mitigation workflows, making it easier to experiment, reproduce results, and share techniques. ## Design Proposal -This is the focus of the document. Explain the proposal from the perspective of -educating another user on the proposed features. -This generally means: -- Introducing new concepts and nomenclature -- Using examples to introduce new features -- Implementation and Migration path with associated concerns -- Communication of features and changes to users - -Focus on giving an overview of impact of the proposed changes to the target -audience. - -Factors to consider: -- Performance -- Dependencies -- Maintenance -- Compatibility +The intent of the following listing is to demonstrate how a user could leverage +the new low-level interface to implement a client-side basic estimator. + +```python +from qiskit_ibm_runtime import QiskitRuntimeService, Session +from qiskit.transpiler import PassManager +from qiskit.transpiler.passes import NoiseLearningLayering +from qiskit.circuit import QuantumCircuit, Parameter, QuantumRegister, ClassicalRegister + +# This proposal assumes the semantics implemented in samplomatic will become +# part of qiskit semantics at some moment. +from qiskit.samplex import build +from qiskit.samplex.annotations import InjectNoise, Twirl + +# The proposal wants to acknowledge the transtionary reality in which the +# primitives continue being the entry point for operating the quantum computer +# and this is a low level interface for advanced usage. +from qiskit.primitives.implementation import QuantumProgram, Executor + +import numpy as np +import matplotlib.pyplot as plt + +service = QiskitRuntimeService(name="staging-cloud") +backend = service.backend("test_heron") + +# Build a circuit for which we need to learn the noise. +circuit0 = QuantumCircuit(2) + +with circuit0.box([Twirl(), InjectNoise("my_noise")]): + circuit0.cx(0, 1) + +with circuit.box([Twirl(), BasisTransform(ref="my_basis")]): + circuit.measure_all() + +# Prepare the circuit for noise learning +pass_ = NoiseLearningLayering() +pm = PassManager(pass_) +layers = pm.run(circuit0) +template, samplex = build(layers) + +noise_learning_program = QuantumProgram(shots=1024) +noise_learning_program.append( + template, + samplex=samplex, + parameter_values=np.linspace(0, 1, 20).reshape(4, 5, 1), + noise_maps=["my_noise"], + basis_transforms={"my_basis": "XX"}, + cast_result_into_noise_map=True + cache_as="my_noise" +) + +sampling_program = QuantumProgram(shots=1024) +sampling_program.append( + circuit0, + +) + +with Session(backend=backend) as session: + executor = Executor(backend) + job = executor.run(noise_learning_program) + + # After this invocation, the result gets cached as a noise model within the + # system and some metadata is returned as part of sampling the samplex. + result = job.result() + signs = result.samplex_output["signs"] + + # This performs the low level sampling. + job = executor.run(sampling_program) + result = job.result() + counts = result.counts + +# And this section should estimate based on the results of the previous +# two programs. +expectation = mitigated_estimation(signs, counts) +``` ## Detailed Design -Technical reference level design. Elaborate on details such as: -- Implementation procedure - - If spans multiple projects cover these parts individually -- Interaction with other features -- Dissecting corner cases -- Reference definition, eg., formal definitions. +TBD ## Alternative Approaches An alternative to introducing the **samplex** DSL is to generate all circuit From af60f3c3b09700d7410dfc03a3ccdc803d7b7595 Mon Sep 17 00:00:00 2001 From: SALVADOR DE LA PUENTE Date: Fri, 15 Aug 2025 09:21:17 -0400 Subject: [PATCH 05/23] Draft for the new low-level primitive complete. --- 0023-low-level-sampler.md | 69 +++++++++++++++++---------------------- 1 file changed, 30 insertions(+), 39 deletions(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index 90f139e..515258e 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -86,7 +86,7 @@ from qiskit.circuit import QuantumCircuit, Parameter, QuantumRegister, Classical # This proposal assumes the semantics implemented in samplomatic will become # part of qiskit semantics at some moment. -from qiskit.samplex import build +from qiskit import samplex from qiskit.samplex.annotations import InjectNoise, Twirl # The proposal wants to acknowledge the transtionary reality in which the @@ -101,53 +101,44 @@ service = QiskitRuntimeService(name="staging-cloud") backend = service.backend("test_heron") # Build a circuit for which we need to learn the noise. -circuit0 = QuantumCircuit(2) +circuit = QuantumCircuit(2) -with circuit0.box([Twirl(), InjectNoise("my_noise")]): - circuit0.cx(0, 1) +with circuit.box([Twirl(), InjectNoise(ref="my_noise")]): + circuit.cx(0, 1) with circuit.box([Twirl(), BasisTransform(ref="my_basis")]): circuit.measure_all() -# Prepare the circuit for noise learning -pass_ = NoiseLearningLayering() -pm = PassManager(pass_) -layers = pm.run(circuit0) -template, samplex = build(layers) - -noise_learning_program = QuantumProgram(shots=1024) -noise_learning_program.append( - template, - samplex=samplex, - parameter_values=np.linspace(0, 1, 20).reshape(4, 5, 1), - noise_maps=["my_noise"], - basis_transforms={"my_basis": "XX"}, - cast_result_into_noise_map=True - cache_as="my_noise" -) - -sampling_program = QuantumProgram(shots=1024) -sampling_program.append( - circuit0, - -) +# Extract layers of the circuit +layers = find_unique_layers(circuit) + +# Prepare circuit for executing +template, samplex = samplex.build() with Session(backend=backend) as session: + # Learning noise + noise_learner = NoiseLearner(backend) + noise_learner_result = noise_learner.run(layers).result() + noise_map = noise_learner_result["noise_map"] + + # Preparing a quantum program for noise-aware sampling + program = QuantumProgram(shots=1024) + program.declare_noise_map("my_noise", noise_map) + program.append( + template, + samplex=samplex, + basis_transforms={"my_basis": "XX"}, + ) + + # Execute (sample) the circuit executor = Executor(backend) - job = executor.run(noise_learning_program) - - # After this invocation, the result gets cached as a noise model within the - # system and some metadata is returned as part of sampling the samplex. - result = job.result() - signs = result.samplex_output["signs"] - - # This performs the low level sampling. - job = executor.run(sampling_program) - result = job.result() - counts = result.counts + job = executor.run(program) -# And this section should estimate based on the results of the previous -# two programs. +# And this section should estimate based on the results from sampling the +# template and executing the samplex. +results = job.results() +signs = results["signs"] +counts = results["meas"] expectation = mitigated_estimation(signs, counts) ``` From 030fa8de166c465187d81f718bf96462ed5ca692 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Fri, 15 Aug 2025 14:14:55 -0400 Subject: [PATCH 06/23] Update 0023-low-level-sampler.md --- 0023-low-level-sampler.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index 515258e..c032b21 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -32,16 +32,11 @@ reliability of quantum computations, especially on noisy quantum hardware. Vendors like IBM have identified that users desire capabilities for precise noise learning, twirling, and expectation value calculations. - -- What will this enable? This proposal will enable Qiskit users to perform large-scale, backend-optimized error mitigation experiments without incurring the high network cost of transmitting thousands or millions of circuit variations. By shifting variation generation to the backend through a portable DSL, researchers can run advanced -techniques such as randomized compiling, Pauli or Clifford twirling, and noise -learning more efficiently. The approach preserves reproducibility via -deterministic seeds and structured metadata, while also allowing backend- -specific optimizations that remain compatible across vendors. +techniques more efficiently. Today, Qiskit users can already run large-scale error mitigation experiments, but the process is **implicit** — it is difficult to explain and difficult to @@ -50,9 +45,8 @@ generated or how mitigation is applied. This proposal introduces the **samplex** DSL, a portable description language that lets users explicitly define the variation strategies applied by the backend. -With this, researchers can tailor error mitigation to their needs, choosing, -for example, the specific forms of Pauli or Clifford twirling, or noise learning to -apply. The approach preserves backend optimizations while giving users fine-grained +With this, researchers can tailor error mitigation to their needs. The approach +preserves backend optimizations while giving users fine-grained control, reproducibility through deterministic seeds, and access to structured metadata for postprocessing. @@ -191,4 +185,4 @@ Additional future work could explore defining domain‑specific languages beyond **samplex**, including DSLs dedicated to calculating expectation values or other specialized tasks. These DSLs could be layered on top of the unified primitive to further extend Qiskit’s flexibility and expressiveness while -retaining backend portability. \ No newline at end of file +retaining backend portability. From 0f0e5d8c314b82ded4c498d0a53324a8face6275 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Mon, 18 Aug 2025 14:15:46 -0400 Subject: [PATCH 07/23] Include NoiseLearner import in the example. Co-authored-by: Blake Johnson --- 0023-low-level-sampler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index c032b21..419dbfd 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -73,7 +73,7 @@ The intent of the following listing is to demonstrate how a user could leverage the new low-level interface to implement a client-side basic estimator. ```python -from qiskit_ibm_runtime import QiskitRuntimeService, Session +from qiskit_ibm_runtime import QiskitRuntimeService, Session, NoiseLearner from qiskit.transpiler import PassManager from qiskit.transpiler.passes import NoiseLearningLayering from qiskit.circuit import QuantumCircuit, Parameter, QuantumRegister, ClassicalRegister From cba75afcf19e2389ef50481f7eb98ce9d8ea53cf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Mon, 18 Aug 2025 14:25:22 -0400 Subject: [PATCH 08/23] Avoid name collision. --- 0023-low-level-sampler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index 419dbfd..cfd3e33 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -107,7 +107,7 @@ with circuit.box([Twirl(), BasisTransform(ref="my_basis")]): layers = find_unique_layers(circuit) # Prepare circuit for executing -template, samplex = samplex.build() +template, samplex_ = samplex.build() with Session(backend=backend) as session: # Learning noise From 400630e7d2d038114a6808a0dc15312aef3eb6bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Mon, 18 Aug 2025 14:26:07 -0400 Subject: [PATCH 09/23] Update to disambiguating name for avoiding name collision. --- 0023-low-level-sampler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index cfd3e33..401c3e4 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -120,7 +120,7 @@ with Session(backend=backend) as session: program.declare_noise_map("my_noise", noise_map) program.append( template, - samplex=samplex, + samplex=samplex_, basis_transforms={"my_basis": "XX"}, ) From d6cd068191749db0b70ce6484e053b2dca6a7f64 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Mon, 18 Aug 2025 14:53:09 -0400 Subject: [PATCH 10/23] Clarify the primitive definition. --- 0023-low-level-sampler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index 401c3e4..aaf53b4 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -10,7 +10,7 @@ ## Summary In Qiskit, the quantum computer interface is built around primitives, which are -the fundamental operations executable on a quantum circuit. Currently, Qiskit +the fundamental operations carried on by a quantum computer on a quantum circuit. Currently, Qiskit offers two such primitives: the Sampler and the Estimator. The Estimator leverages advanced error mitigation techniques to enhance the quality of results from noisy quantum computers. On a noiseless quantum computer, the From 82f4c0cd25f08753c2f4504deb246ab123204e98 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Mon, 18 Aug 2025 14:59:03 -0400 Subject: [PATCH 11/23] Correct purpose of sending thousands/millions of circuit variations. --- 0023-low-level-sampler.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/0023-low-level-sampler.md b/0023-low-level-sampler.md index aaf53b4..19aad3a 100644 --- a/0023-low-level-sampler.md +++ b/0023-low-level-sampler.md @@ -10,15 +10,15 @@ ## Summary In Qiskit, the quantum computer interface is built around primitives, which are -the fundamental operations carried on by a quantum computer on a quantum circuit. Currently, Qiskit -offers two such primitives: the Sampler and the Estimator. The Estimator -leverages advanced error mitigation techniques to enhance the quality of -results from noisy quantum computers. On a noiseless quantum computer, the +the fundamental operations carried on by a quantum computer on a quantum circuit. +Currently, Qiskit offers two such primitives: the Sampler and the Estimator. +The Estimator leverages advanced error mitigation techniques to enhance the quality +of results from noisy quantum computers. On a noiseless quantum computer, the Estimator could instead be constructed atop the Sampler, simplifying its role. However, given current noise levels, robust error mitigation is essential, -requiring extensive profiling through thousands or even millions of circuit -variations. Transmitting these variations across cloud environments is -inefficient, but this can be optimized using a "samplex" — a domain-specific +requiring executing thousands or even millions of circuit variations to implement +certain mitigation protocols. Transmitting these variations across cloud environments +is inefficient, but this can be optimized using a "samplex" — a domain-specific language (DSL) program describing the way of producing these variations. The samplex enables efficient server-side generation of variations, with results transmitted back as samples accompanied by metadata, facilitating client-side From 5d35d70fed320c733639f6bc55f8b08a7b013bbd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Tue, 19 Aug 2025 15:30:48 -0400 Subject: [PATCH 12/23] Update and rename 0023-low-level-sampler.md to 0023-executor-primitive.md --- ...-low-level-sampler.md => 0023-executor-primitive.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) rename 0023-low-level-sampler.md => 0023-executor-primitive.md (96%) diff --git a/0023-low-level-sampler.md b/0023-executor-primitive.md similarity index 96% rename from 0023-low-level-sampler.md rename to 0023-executor-primitive.md index 19aad3a..d7ff5d1 100644 --- a/0023-low-level-sampler.md +++ b/0023-executor-primitive.md @@ -1,16 +1,16 @@ -# Low level sampler +# Executor primitive | **Status** | **Proposed/Accepted/Deprecated** | |:------------------|:---------------------------------------------| | **RFC #** | 0023 | -| **Authors** | Salva de la Puente (salva@ibm.com), Antonio Corcole, Ian Hincks | +| **Authors** | Salva de la Puente (salva@ibm.com), Antonio Corcoles, Ian Hincks | | **Deprecates** | TBD | | **Submitted** | 2025-07-30 | | **Updated** | YYYY-MM-DD | ## Summary In Qiskit, the quantum computer interface is built around primitives, which are -the fundamental operations carried on by a quantum computer on a quantum circuit. +the fundamental operations carried by a quantum computer on a quantum circuit. Currently, Qiskit offers two such primitives: the Sampler and the Estimator. The Estimator leverages advanced error mitigation techniques to enhance the quality of results from noisy quantum computers. On a noiseless quantum computer, the @@ -18,7 +18,7 @@ Estimator could instead be constructed atop the Sampler, simplifying its role. However, given current noise levels, robust error mitigation is essential, requiring executing thousands or even millions of circuit variations to implement certain mitigation protocols. Transmitting these variations across cloud environments -is inefficient, but this can be optimized using a "samplex" — a domain-specific +is inefficient, but this can be optimized using a "samplex", a domain-specific language (DSL) program describing the way of producing these variations. The samplex enables efficient server-side generation of variations, with results transmitted back as samples accompanied by metadata, facilitating client-side @@ -39,7 +39,7 @@ generation to the backend through a portable DSL, researchers can run advanced techniques more efficiently. Today, Qiskit users can already run large-scale error mitigation experiments, -but the process is **implicit** — it is difficult to explain and difficult to +but the process is **implicit**—it is difficult to explain and difficult to compose, and users have no direct control over how circuit variations are generated or how mitigation is applied. This proposal introduces the **samplex** DSL, a portable description language that lets users explicitly define the From c5525c238278fe10306b8bbb747b5f886ffa1d6d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Fri, 22 Aug 2025 14:23:28 -0400 Subject: [PATCH 13/23] Generalize the definition of the Estimator MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com> --- 0023-executor-primitive.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index d7ff5d1..52552c0 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -12,13 +12,15 @@ In Qiskit, the quantum computer interface is built around primitives, which are the fundamental operations carried by a quantum computer on a quantum circuit. Currently, Qiskit offers two such primitives: the Sampler and the Estimator. -The Estimator leverages advanced error mitigation techniques to enhance the quality -of results from noisy quantum computers. On a noiseless quantum computer, the -Estimator could instead be constructed atop the Sampler, simplifying its role. +The Estimator primitive computes expectation values from circuits and observables, while the Sampler samples the output register from quantum circuit execution. Qiskit IBM Runtime provides optimized implementations of the Qiskit primitives for IBM Quantum hardware. In particular, the Qiskit Runtime Estimator leverages advanced error mitigation techniques to enhance the quality +of results from noisy quantum computers. On a noiseless quantum computer, this +Estimator could instead be constructed atop the Sampler, simplifying its implementation. However, given current noise levels, robust error mitigation is essential, requiring executing thousands or even millions of circuit variations to implement -certain mitigation protocols. Transmitting these variations across cloud environments -is inefficient, but this can be optimized using a "samplex", a domain-specific +certain mitigation protocols. + +Advanced users might benefit from fine-grained control over the error mitigation strategy implementation, but transmitting how precisely to perform these circuit variations across cloud environments +is inefficient. We found that this can be optimized using a "samplex", a domain-specific language (DSL) program describing the way of producing these variations. The samplex enables efficient server-side generation of variations, with results transmitted back as samples accompanied by metadata, facilitating client-side From 93730f9a91792da09a70ba558dbc8e952be1cc54 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Fri, 22 Aug 2025 14:27:42 -0400 Subject: [PATCH 14/23] Remove mention to a "low-level" primitive --- 0023-executor-primitive.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index 52552c0..67ebe35 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -72,7 +72,7 @@ making it easier to experiment, reproduce results, and share techniques. ## Design Proposal The intent of the following listing is to demonstrate how a user could leverage -the new low-level interface to implement a client-side basic estimator. +the new interface to implement a client-side basic estimator. ```python from qiskit_ibm_runtime import QiskitRuntimeService, Session, NoiseLearner @@ -87,7 +87,7 @@ from qiskit.samplex.annotations import InjectNoise, Twirl # The proposal wants to acknowledge the transtionary reality in which the # primitives continue being the entry point for operating the quantum computer -# and this is a low level interface for advanced usage. +# and this is an specific interface for advanced usage. from qiskit.primitives.implementation import QuantumProgram, Executor import numpy as np @@ -170,12 +170,11 @@ TBD ## Future Extensions -The introduction of a low‑level sampler is only the first step. The long‑term -goal is to evolve Qiskit’s compute model toward accepting a single, unified -operation—this primitive—potentially deprecating the current definition of -primitives altogether. In this model, noise learning, error mitigation, and any -other computation could be implemented directly on top of the unified primitive -abstraction. +The introduction of the Executor is just the first step inevolving Qiskit's +compute model toward accepting a single, unified operation—this +primitive—potentially deprecating the current definition of primitives altogether. +In this model, noise learning, error mitigation, and any other computation could be +implemented directly on top of the unified primitive abstraction. Future RFCs may explore implementing advanced workflows such as noise learning natively within this computation model, as well as replacing Qiskit’s existing From ee503ceedc0251d7c45b07f0d317c1a54b40f4a1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Sun, 31 Aug 2025 00:46:58 -0400 Subject: [PATCH 15/23] Clarify samplex DSL description and its benefits Refactor the description of the samplex DSL for clarity and consistency. Improve the explanation of its role in error mitigation and its benefits for users and developers. --- 0023-executor-primitive.md | 53 +++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 23 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index 67ebe35..f1d61df 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -12,19 +12,23 @@ In Qiskit, the quantum computer interface is built around primitives, which are the fundamental operations carried by a quantum computer on a quantum circuit. Currently, Qiskit offers two such primitives: the Sampler and the Estimator. -The Estimator primitive computes expectation values from circuits and observables, while the Sampler samples the output register from quantum circuit execution. Qiskit IBM Runtime provides optimized implementations of the Qiskit primitives for IBM Quantum hardware. In particular, the Qiskit Runtime Estimator leverages advanced error mitigation techniques to enhance the quality -of results from noisy quantum computers. On a noiseless quantum computer, this -Estimator could instead be constructed atop the Sampler, simplifying its implementation. -However, given current noise levels, robust error mitigation is essential, -requiring executing thousands or even millions of circuit variations to implement -certain mitigation protocols. - -Advanced users might benefit from fine-grained control over the error mitigation strategy implementation, but transmitting how precisely to perform these circuit variations across cloud environments -is inefficient. We found that this can be optimized using a "samplex", a domain-specific -language (DSL) program describing the way of producing these variations. The -samplex enables efficient server-side generation of variations, with results -transmitted back as samples accompanied by metadata, facilitating client-side -implementation of error-mitigated estimations. +The Estimator primitive computes expectation values from circuits and observables, +while the Sampler samples the output register from quantum circuit execution. Qiskit +IBM Runtime provides optimized implementations of the Qiskit primitives for IBM +Quantum hardware. In particular, the Qiskit Runtime Estimator leverages advanced error +mitigation techniques to enhance the quality of results from noisy quantum computers. +On a noiseless quantum computer, this Estimator could instead be constructed atop the +Sampler, simplifying its implementation. However, given current noise levels, robust +error mitigation is essential, requiring executing thousands or even millions of circuit +variations to implement certain mitigation protocols. + +Advanced users might benefit from fine-grained control over the error mitigation strategy +implementation, but transmitting how precisely to perform these circuit variations across +cloud environments is inefficient. We found that this can be optimized using a "samplex", +a data structure encoding all information about the randomization process and describing +the way of producing these variations. The samplex enables efficient server-side generation +of variations, with results transmitted back as samples accompanied by metadata, facilitating +client-side implementation of error-mitigated estimations. ## Motivation The purpose of this development is addressing the growing demand within the @@ -44,8 +48,8 @@ Today, Qiskit users can already run large-scale error mitigation experiments, but the process is **implicit**—it is difficult to explain and difficult to compose, and users have no direct control over how circuit variations are generated or how mitigation is applied. This proposal introduces the **samplex** -DSL, a portable description language that lets users explicitly define the -variation strategies applied by the backend. +data structure, a portable object specifying explicitly encoding all information +about the randomization process itself. With this, researchers can tailor error mitigation to their needs. The approach preserves backend optimizations while giving users fine-grained @@ -59,8 +63,8 @@ strategies. By making the variation generation process explicit and user-definable, it empowers users to explore and tune novel error mitigation techniques. -Backend and platform developers will also benefit, as the **samplex** DSL -creates a standard interface for describing variation strategies that can be +Backend and platform developers will also benefit, as the **samplex** data structure +creates a standard interface for describing randomization strategies that can be implemented consistently across vendors. This improves portability, reduces vendor lock-in, and enables backends to apply optimizations without sacrificing user intent. @@ -142,7 +146,7 @@ expectation = mitigated_estimation(signs, counts) TBD ## Alternative Approaches -An alternative to introducing the **samplex** DSL is to generate all circuit +An alternative to introducing the **samplex** DAG is to generate all circuit variations entirely on the client side and transmit them to the backend for execution. This approach offers maximum flexibility and complete control over how variations are produced, since the backend would simply execute the @@ -158,7 +162,7 @@ execution time, and places substantial demands on both client and backend infrastructure. It also complicates reproducibility across vendors, since each vendor may handle large‑batch execution differently. -By contrast, the **samplex** DSL allows users to describe their variation +By contrast, the **samplex** DAG allows users to describe their variation generation strategies in a portable, serialized form that can be transmitted efficiently. The backend can then expand these strategies into actual circuit variations locally, reducing network load while preserving user control over @@ -166,7 +170,10 @@ error mitigation techniques. ## Questions Open questions for discussion and an opening for feedback. -TBD + +- Should Qiskit `quantum_info` include error simulation? +- Should Qiskit include a reference `Executor` implementation, executing Samplomatic + locally based on a noisy `StateVector`? ## Future Extensions @@ -183,7 +190,7 @@ execution pipeline, make workflows more composable, and provide a consistent foundation for new quantum algorithms and techniques. Additional future work could explore defining domain‑specific languages beyond -**samplex**, including DSLs dedicated to calculating expectation values or -other specialized tasks. These DSLs could be layered on top of the unified -primitive to further extend Qiskit’s flexibility and expressiveness while +**sampling** annotations, including DSLs dedicated to calculating expectation +values or other specialized tasks. These DSLs could be layered on top of the +unified primitive to further extend Qiskit’s flexibility and expressiveness while retaining backend portability. From 8bdedbc89a2f6349f9908e902409f1ee449dcdda Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Sun, 31 Aug 2025 00:49:53 -0400 Subject: [PATCH 16/23] Fix author list and update status in RFC 0023 --- 0023-executor-primitive.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index f1d61df..14cdb78 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -1,12 +1,14 @@ # Executor primitive -| **Status** | **Proposed/Accepted/Deprecated** | +| **Status** | **Proposedd** | |:------------------|:---------------------------------------------| | **RFC #** | 0023 | -| **Authors** | Salva de la Puente (salva@ibm.com), Antonio Corcoles, Ian Hincks | -| **Deprecates** | TBD | +| **Authors** | Salva de la Puente (salva@ibm.com) | +| | Ian Hincks (ian.hincks@ibm.com) | +| | Antonio Corcoles (adcorcol@us.ibm.com) | +| **Deprecates** | TBD | | **Submitted** | 2025-07-30 | -| **Updated** | YYYY-MM-DD | +| **Updated** | 2025-08-30 | ## Summary In Qiskit, the quantum computer interface is built around primitives, which are From 4e990cc6462bb99379fc9eb946c9fd207e3eee65 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Sun, 31 Aug 2025 10:03:00 -0400 Subject: [PATCH 17/23] Delve into the role of QuantumProgram and Executor within qiskit_ibm_runtime --- 0023-executor-primitive.md | 40 ++++++++++++++++++++++++++++++++++---- 1 file changed, 36 insertions(+), 4 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index 14cdb78..f05595e 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -91,10 +91,10 @@ from qiskit.circuit import QuantumCircuit, Parameter, QuantumRegister, Classical from qiskit import samplex from qiskit.samplex.annotations import InjectNoise, Twirl -# The proposal wants to acknowledge the transtionary reality in which the -# primitives continue being the entry point for operating the quantum computer -# and this is an specific interface for advanced usage. -from qiskit.primitives.implementation import QuantumProgram, Executor +# The proposal is aligned with IBM current push in enabling quantum information +# research through its offering and so, places the QuantumProgram and the +# Executor within a `quantum_info` module inside `qiskit_ibm_runtime` package. +from qiskit_ibm_runtime.quantum_info import QuantumProgram, Executor import numpy as np import matplotlib.pyplot as plt @@ -144,7 +144,39 @@ counts = results["meas"] expectation = mitigated_estimation(signs, counts) ``` +Both `QuantumProgram` and `Executor` are implemented deriving from the base +classes in Qiskit `QuantumProgramBase` and `ExecutorBase`, with the following +definitions: + +```python +# qiskit/primitives/containers/quantum_program.py + +from abc import abstractmethod, ABC + +class BaseQuantumProgram(ABC): + ... + +# qiskit/primitives/base/base_executor.py + +from abc import abstractmethod, ABC +from ..containers import QuantumProgram, QuantumProgramResult + +class BaseExecutor(ABC): + ... +``` + ## Detailed Design + +### Quantum program and program results +TBD + +### Samplex and samplex annotations +TBD + +### Noise learning +TBD + +### System drift between learning and mitigation TBD ## Alternative Approaches From 17b298c43d4b9c1df089850177b147ef6a9f756e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Mon, 1 Sep 2025 18:17:43 -0400 Subject: [PATCH 18/23] Refactor documentation for ExecutorProgram usage Delve into the key concepts of the Executor primitive, and its relation with samplex annotation and the samplex data structure. --- 0023-executor-primitive.md | 63 +++++++++++++++++++++++++++++--------- 1 file changed, 48 insertions(+), 15 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index f05595e..b0f313a 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -92,9 +92,9 @@ from qiskit import samplex from qiskit.samplex.annotations import InjectNoise, Twirl # The proposal is aligned with IBM current push in enabling quantum information -# research through its offering and so, places the QuantumProgram and the +# research through its offering and so, places the ExecutorProgram and the # Executor within a `quantum_info` module inside `qiskit_ibm_runtime` package. -from qiskit_ibm_runtime.quantum_info import QuantumProgram, Executor +from qiskit_ibm_runtime.quantum_info import ExecutorProgram, Executor import numpy as np import matplotlib.pyplot as plt @@ -124,8 +124,8 @@ with Session(backend=backend) as session: noise_map = noise_learner_result["noise_map"] # Preparing a quantum program for noise-aware sampling - program = QuantumProgram(shots=1024) - program.declare_noise_map("my_noise", noise_map) + program = ExecutorProgram(shots=1024) + program.define_symbol("my_noise", noise_map) program.append( template, samplex=samplex_, @@ -144,8 +144,8 @@ counts = results["meas"] expectation = mitigated_estimation(signs, counts) ``` -Both `QuantumProgram` and `Executor` are implemented deriving from the base -classes in Qiskit `QuantumProgramBase` and `ExecutorBase`, with the following +Both `ExecutorProgram` and `Executor` are implemented deriving from the base +classes in Qiskit `ExecutorProgramBase` and `ExecutorBase`, with the following definitions: ```python @@ -153,13 +153,13 @@ definitions: from abc import abstractmethod, ABC -class BaseQuantumProgram(ABC): +class BaseExecutorProgram(ABC): ... # qiskit/primitives/base/base_executor.py from abc import abstractmethod, ABC -from ..containers import QuantumProgram, QuantumProgramResult +from ..containers import ExecutorProgram, ExecutorResult class BaseExecutor(ABC): ... @@ -167,17 +167,46 @@ class BaseExecutor(ABC): ## Detailed Design -### Quantum program and program results -TBD - -### Samplex and samplex annotations -TBD +### Executor program and program results +The `Executor` primitive exposes a noise-aware compute model for running +circuits enabling noise mitigation. The circuit represents, however, just a +portion of the quantum computer operation. In the same way a classical computer +does not run ALU operations only, the quantum computer needs additional +instructions, and directives to deal with _aspects_ such as observable +measurements, randomization, batching, or shot scheduling, to mention some. The +`ExecutorProgram` interface captures all semantics needed to operate the quantum +computer. + +Once program execution is done, there is need for collecting not only computation +results, but metadata about computation, including non-sensitive intermediate and +final machine state. The `ExecutorResult` interface captures this data. + +### Samplex annotations and the samplex data structure +We discussed the need for instructions besides circuit operations. Samplex annotations +are domain specific instructions and conform a domain specific language, or _DSL_, that +augments circuit semantics to instruct the computer how to executor a randomization +protocol for enabling error mitigation techniques. Given randomization semantics are +tightly coupled to circuit operations, box annotations emerge as the natural +implementation in Qiskit. + +The samplex data structure encodes the steps for implementing randomization protocols +in a directed acyclic graph, or _DAG_. The result of executing the randomization protocol +on a circuit is the generation of potentially millions of circuit variations. Instead +of requesting the client to generate these variations and transmit them through the wire, +the `ExecutorProgram` package an optional samplex data structure to run it client-side, +saving unnecesary bandwith, and potentially performing fast template circuit hydration +withing the quantum computer runtime. ### Noise learning TBD ### System drift between learning and mitigation -TBD +Explicit separation of noise learning and execution introduces the possibility for the +system to drift in between the construction of the noise map and its application during +mitigation. Drifting means the noise characterization may be outdated by the time the user +wants to use it for error mitigation. To warrant error mitigation happens right after +learning, the user can use runtime sessions to acquire exclusive access on the system, as +shown in the example above. ## Alternative Approaches An alternative to introducing the **samplex** DAG is to generate all circuit @@ -202,10 +231,14 @@ efficiently. The backend can then expand these strategies into actual circuit variations locally, reducing network load while preserving user control over error mitigation techniques. +An intermediate solution would have been to save the user the generation of +the samplex in the client, sending the annotated circuit only. TBD into why +this option was discarded. + ## Questions Open questions for discussion and an opening for feedback. -- Should Qiskit `quantum_info` include error simulation? +- Should Qiskit `quantum_info` include noisy statevector evolution? - Should Qiskit include a reference `Executor` implementation, executing Samplomatic locally based on a noisy `StateVector`? From acdbe585e1b74536cd38db23f79eb5fb77d36eb5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Mon, 1 Sep 2025 18:33:46 -0400 Subject: [PATCH 19/23] Refine explanation on samplex generation decision Clarify the reasoning behind the decision to avoid saving user-generated samplex in the client and emphasize the importance of local generation for inspectability and debuggability. --- 0023-executor-primitive.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index b0f313a..3704a7d 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -231,9 +231,11 @@ efficiently. The backend can then expand these strategies into actual circuit variations locally, reducing network load while preserving user control over error mitigation techniques. -An intermediate solution would have been to save the user the generation of -the samplex in the client, sending the annotated circuit only. TBD into why -this option was discarded. +An intermediate solution would have been to save the user from generating the +samplex in the client, sending the annotated circuit only. However, local +inspectability and debuggability would require local generation of the samplex +DAG anyhow. More importantly, the compute model becomes simpler and honors its main +responsibillity: execution. ## Questions Open questions for discussion and an opening for feedback. From 228889940ef9cad85511fdad9d43a93a4d669b1e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Sat, 20 Sep 2025 17:42:41 +0530 Subject: [PATCH 20/23] Update 0023-executor-primitive.md Reframe to balance focus on the Executor primitive as a programming model, and introducing randomization semantics in Qiskit. --- 0023-executor-primitive.md | 185 ++++++++++++++++++++++--------------- 1 file changed, 108 insertions(+), 77 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index 3704a7d..f5f0132 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -11,72 +11,69 @@ | **Updated** | 2025-08-30 | ## Summary -In Qiskit, the quantum computer interface is built around primitives, which are -the fundamental operations carried by a quantum computer on a quantum circuit. -Currently, Qiskit offers two such primitives: the Sampler and the Estimator. -The Estimator primitive computes expectation values from circuits and observables, -while the Sampler samples the output register from quantum circuit execution. Qiskit -IBM Runtime provides optimized implementations of the Qiskit primitives for IBM -Quantum hardware. In particular, the Qiskit Runtime Estimator leverages advanced error -mitigation techniques to enhance the quality of results from noisy quantum computers. -On a noiseless quantum computer, this Estimator could instead be constructed atop the -Sampler, simplifying its implementation. However, given current noise levels, robust -error mitigation is essential, requiring executing thousands or even millions of circuit -variations to implement certain mitigation protocols. - -Advanced users might benefit from fine-grained control over the error mitigation strategy -implementation, but transmitting how precisely to perform these circuit variations across -cloud environments is inefficient. We found that this can be optimized using a "samplex", -a data structure encoding all information about the randomization process and describing -the way of producing these variations. The samplex enables efficient server-side generation -of variations, with results transmitted back as samples accompanied by metadata, facilitating -client-side implementation of error-mitigated estimations. +This RFC proposes the introduction of a new **Executor primitive** into Qiskit +as a vendor-agnostic substrate for execution. The Executor provides +infrastructure through three core components—**Executor**, **ExecutorProgram**, +and **ExecutorResult**—which capture the relationship between an execution +engine, its semantics, and its results. + +The immediate motivation is to make **randomization semantics for error +mitigation** first-class citizens in Qiskit. Today these workflows exist in an +implicit and opaque form; this RFC proposes to standardize how users express +their *intent* through annotations and portable representations. This enables +fine-grained control, reproducibility, and composability of error-mitigation +experiments while keeping provider implementations free to optimize expansion +strategies. + +It is important to note that this RFC does **not** propose adopting a specific +engine such as IBM’s Samplomatic into Qiskit. Instead, the scope is limited to +defining the substrate (Executor) and the representation of user intent. Vendor +implementations can build their own engines on top of these abstractions. +Follow-up RFCs may introduce additional semantics or reference implementations +(e.g. a noisy-statevector executor), but this proposal focuses on laying the +foundation. ## Motivation -The purpose of this development is addressing the growing demand within the -quantum information science community for advanced error mitigation techniques. -Users and researchers seek finer control over these techniques to improve the -reliability of quantum computations, especially on noisy quantum hardware. -Vendors like IBM have identified that users desire capabilities for precise +The purpose of this proposal is to address the growing demand in the quantum +information science community for advanced error-mitigation techniques. Users +and researchers seek finer control over these methods to improve the reliability +of computations on noisy quantum hardware, with interest in capabilities such as noise learning, twirling, and expectation value calculations. -This proposal will enable Qiskit users to perform large-scale, backend-optimized -error mitigation experiments without incurring the high network cost of -transmitting thousands or millions of circuit variations. By shifting variation -generation to the backend through a portable DSL, researchers can run advanced -techniques more efficiently. - -Today, Qiskit users can already run large-scale error mitigation experiments, -but the process is **implicit**—it is difficult to explain and difficult to -compose, and users have no direct control over how circuit variations are -generated or how mitigation is applied. This proposal introduces the **samplex** -data structure, a portable object specifying explicitly encoding all information -about the randomization process itself. - -With this, researchers can tailor error mitigation to their needs. The approach -preserves backend optimizations while giving users fine-grained -control, reproducibility through deterministic seeds, and access to structured -metadata for postprocessing. +Qiskit already supports large-scale mitigation experiments, but today the +process is **implicit**—difficult to explain, compose, or control. By shifting +circuit-variation generation to the backend through a portable representation, +researchers can run these workflows more efficiently and without the high +network cost of transmitting thousands of circuit variants. Making this process +explicit also enables reproducibility through seeds and access to structured +metadata for post-processing. + +To support this, we propose a new **Executor primitive**. The Executor provides +a vendor-agnostic substrate for execution where semantics are captured in an +**ExecutorProgram**. This allows providers to expose arbitrary programming +models and gives Qiskit a single, extensible foundation for advanced semantics— +with error mitigation as a leading use case, but equally applicable to future +methods such as estimation, hybrid execution, noise learning protocols, or shot +scheduling. ## User Benefit This proposal will primarily benefit researchers and practitioners working with -noisy quantum hardware who require precise control over error mitigation -strategies. By making the variation generation process explicit and -user-definable, it empowers users to explore and tune novel error mitigation -techniques. +noisy quantum hardware who require precise control over advanced execution +semantics. Error mitigation is a leading example: by making variation generation +explicit and user-definable, users can explore and tune mitigation techniques +more directly. -Backend and platform developers will also benefit, as the **samplex** data structure -creates a standard interface for describing randomization strategies that can be -implemented consistently across vendors. This improves portability, reduces -vendor lock-in, and enables backends to apply optimizations without sacrificing -user intent. +Backend and platform developers will also benefit, as the proposed +**representation** for variations and execution semantics provides a standard +interface that can be implemented consistently across vendors. This improves +portability, reduces vendor lock-in, and enables backends to apply optimizations +without sacrificing user intent. Finally, the broader Qiskit community, including educators and tool developers, -will gain a clearer and more composable model for error mitigation workflows, -making it easier to experiment, reproduce results, and share techniques. +will gain a clearer and more composable model for execution workflows, making it +easier to experiment with new techniques, reproduce results, and share methods. ## Design Proposal - The intent of the following listing is to demonstrate how a user could leverage the new interface to implement a client-side basic estimator. @@ -91,7 +88,7 @@ from qiskit.circuit import QuantumCircuit, Parameter, QuantumRegister, Classical from qiskit import samplex from qiskit.samplex.annotations import InjectNoise, Twirl -# The proposal is aligned with IBM current push in enabling quantum information +# The proposal is aligned with IBM current push in boosting quantum information # research through its offering and so, places the ExecutorProgram and the # Executor within a `quantum_info` module inside `qiskit_ibm_runtime` package. from qiskit_ibm_runtime.quantum_info import ExecutorProgram, Executor @@ -115,7 +112,7 @@ with circuit.box([Twirl(), BasisTransform(ref="my_basis")]): layers = find_unique_layers(circuit) # Prepare circuit for executing -template, samplex_ = samplex.build() +template, samplex_ = samplex.build(circuit) with Session(backend=backend) as session: # Learning noise @@ -126,11 +123,8 @@ with Session(backend=backend) as session: # Preparing a quantum program for noise-aware sampling program = ExecutorProgram(shots=1024) program.define_symbol("my_noise", noise_map) - program.append( - template, - samplex=samplex_, - basis_transforms={"my_basis": "XX"}, - ) + program.define_symbol("my_basis", "XX") + program.append(template, samplex=samplex_) # Execute (sample) the circuit executor = Executor(backend) @@ -145,7 +139,7 @@ expectation = mitigated_estimation(signs, counts) ``` Both `ExecutorProgram` and `Executor` are implemented deriving from the base -classes in Qiskit `ExecutorProgramBase` and `ExecutorBase`, with the following +classes in Qiskit `BaseExecutorProgram` and `BaseExecutor`, with the following definitions: ```python @@ -208,6 +202,28 @@ wants to use it for error mitigation. To warrant error mitigation happens right learning, the user can use runtime sessions to acquire exclusive access on the system, as shown in the example above. +### Security and privacy considerations + +The introduction of randomization semantics and metadata raises potential +security and privacy issues: + +- **Noise maps and calibration data.** These may reveal proprietary details + about a provider’s hardware or calibration process. Providers may need to + redact, aggregate, or abstract sensitive information before returning it to + users. +- **User-generated metadata.** Seeds, labels, and symbolic parameters may + contain experiment identifiers or other sensitive data. These must be stored + and transmitted securely, especially when persisted for reproducibility. +- **Cross-provider reproducibility.** Metadata required for reproducibility + (e.g., seeds, plan identifiers) should be retained, but providers remain free + to limit or sanitize additional fields that could expose internal details. +- **Documentation requirements.** Each provider should document what metadata is + returned, what may be redacted, and under what circumstances. This ensures + transparency for users while respecting provider confidentiality. + +These considerations do not affect the core `Executor` interfaces, but they are +important for implementers to address in provider-specific documentation. + ## Alternative Approaches An alternative to introducing the **samplex** DAG is to generate all circuit variations entirely on the client side and transmit them to the backend for @@ -237,6 +253,16 @@ inspectability and debuggability would require local generation of the samplex DAG anyhow. More importantly, the compute model becomes simpler and honors its main responsibillity: execution. +It is worth noting that earlier drafts of this RFC explored introducing the +`Executor` as a sampler-like primitive that would directly capture additional +semantics beyond the current `Sampler` and `Estimator`. While this approach +could have delivered short-term functionality, we concluded that it risked +creating yet another primitive with overlapping scope. Framing the design instead +around the **`Executor`** as an abstract programming model is more future-proof +and flexible: it allows different providers to expose their own semantics within a single +substrate, and it mitigates fragmenting Qiskit’s compute interface with multiple +too specialized primitives. + ## Questions Open questions for discussion and an opening for feedback. @@ -245,21 +271,26 @@ Open questions for discussion and an opening for feedback. locally based on a noisy `StateVector`? ## Future Extensions - -The introduction of the Executor is just the first step inevolving Qiskit's -compute model toward accepting a single, unified operation—this -primitive—potentially deprecating the current definition of primitives altogether. -In this model, noise learning, error mitigation, and any other computation could be -implemented directly on top of the unified primitive abstraction. - -Future RFCs may explore implementing advanced workflows such as noise learning -natively within this computation model, as well as replacing Qiskit’s existing -compute interface with the unified approach. This shift would simplify the +The introduction of the Executor is a first step toward evolving Qiskit's compute +model with a single, general substrate for execution. This primitive can live +side by side with existing primitives, offering an alternative path that +gradually demonstrates its value without requiring immediate changes to the way +Qiskit works. In this model, error mitigation, noise learning, and other forms +of computation can be expressed directly on top of the Executor abstraction. + +A natural follow-up will be to reimplement the existing `Sampler` and `Estimator` +interfaces on top of `Executor`. Doing so would show how today’s most common +workflows can be captured as lightweight profiles over the new substrate. This +would give users a migration path with familiar APIs, while enabling providers +to optimize around a single execution foundation. + +Beyond this, future RFCs may explore implementing more advanced workflows such +as noise learning natively within the Executor model. This would simplify the execution pipeline, make workflows more composable, and provide a consistent foundation for new quantum algorithms and techniques. -Additional future work could explore defining domain‑specific languages beyond -**sampling** annotations, including DSLs dedicated to calculating expectation -values or other specialized tasks. These DSLs could be layered on top of the -unified primitive to further extend Qiskit’s flexibility and expressiveness while -retaining backend portability. +Additional extensions could include domain-specific representations beyond +**randomization** annotations, such as those dedicated to calculating expectation +values or shot scheduling. These could be layered on top of the Executor to +further extend Qiskit’s flexibility and expressiveness while retaining backend +portability. From 7d740689fa0acb95a2e4c578870a9333c794c70c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Sat, 20 Sep 2025 20:42:31 +0530 Subject: [PATCH 21/23] Update 0023-executor-primitive.md Refine the demo and detailed design of the RFC. --- 0023-executor-primitive.md | 163 +++++++++++++++++++++++-------------- 1 file changed, 101 insertions(+), 62 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index f5f0132..d80a931 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -78,20 +78,24 @@ The intent of the following listing is to demonstrate how a user could leverage the new interface to implement a client-side basic estimator. ```python -from qiskit_ibm_runtime import QiskitRuntimeService, Session, NoiseLearner -from qiskit.transpiler import PassManager +from qiskit.transpiler import generate_preset_pass_manager from qiskit.transpiler.passes import NoiseLearningLayering from qiskit.circuit import QuantumCircuit, Parameter, QuantumRegister, ClassicalRegister -# This proposal assumes the semantics implemented in samplomatic will become -# part of qiskit semantics at some moment. -from qiskit import samplex -from qiskit.samplex.annotations import InjectNoise, Twirl +# This proposal assumes the randomizaton semantics implemented in Samplomatic will become +# part of Qiskit semantics. +from qiskit.circuit.annotations import BasisTransform, InjectNoise, Twirl -# The proposal is aligned with IBM current push in boosting quantum information -# research through its offering and so, places the ExecutorProgram and the -# Executor within a `quantum_info` module inside `qiskit_ibm_runtime` package. -from qiskit_ibm_runtime.quantum_info import ExecutorProgram, Executor +# IBM-proprietary Samplex becomes the vendor-agnostic RandomizationPlan. +from qiskit.circuit.annotations.rand import RandomizationPlan + +from qiskit_ibm_runtime import QiskitRuntimeService, Session + +# Vendor-specific (such as IBM) classes derive from `Base` classes defined +# in Qiskit. In particular, `QuantumProgram` and `NoiseLearningProgram` are both +# `ExecutorProgram` instances. +from qiskit_ibm_runtime import Executor, QuantumProgram +from qiskit_ibm_runtime import NoiseLearningProgram import numpy as np import matplotlib.pyplot as plt @@ -108,39 +112,46 @@ with circuit.box([Twirl(), InjectNoise(ref="my_noise")]): with circuit.box([Twirl(), BasisTransform(ref="my_basis")]): circuit.measure_all() +# Convert into ISA circuit. +isa_pm = generate_preset_pass_manager(backend=backend, optimization_level=0) +isa_circuit = isa_pm.run(circuit) + # Extract layers of the circuit -layers = find_unique_layers(circuit) +circuit_layers = NoiseLearningProgram.find_unique_layers(isa_circuit) # Prepare circuit for executing -template, samplex_ = samplex.build(circuit) +template, plan = RandomizationPlan.build(isa_circuit) with Session(backend=backend) as session: + # Instantiate the programming model primitive + executor = Executor(backend) + # Learning noise - noise_learner = NoiseLearner(backend) - noise_learner_result = noise_learner.run(layers).result() - noise_map = noise_learner_result["noise_map"] + noise_learner = NoiseLearningProgram(circuit_layers) + job = executor.run(noise_learner) + result = job.result() + + # Extrac noise map + noise_map = { layer: model for zip(circuit_layers, result } # Preparing a quantum program for noise-aware sampling - program = ExecutorProgram(shots=1024) + program = QuantumProgram(shots=1024) program.define_symbol("my_noise", noise_map) program.define_symbol("my_basis", "XX") - program.append(template, samplex=samplex_) - - # Execute (sample) the circuit - executor = Executor(backend) + program.append(template, randomization_plan=plan) job = executor.run(program) # And this section should estimate based on the results from sampling the # template and executing the samplex. -results = job.results() -signs = results["signs"] -counts = results["meas"] +result = job.result() +signs = result["signs"] +counts = result["meas"] expectation = mitigated_estimation(signs, counts) ``` -Both `ExecutorProgram` and `Executor` are implemented deriving from the base -classes in Qiskit `BaseExecutorProgram` and `BaseExecutor`, with the following -definitions: +Both `QuantumProgram` and `NoiseLearningProgram` are implemented deriving +from the base class in Qiskit `BaseExecutorProgram` and `Executor` is derived +from `BaseExecutor`, with the following definitions: ```python # qiskit/primitives/containers/quantum_program.py @@ -161,46 +172,74 @@ class BaseExecutor(ABC): ## Detailed Design -### Executor program and program results -The `Executor` primitive exposes a noise-aware compute model for running -circuits enabling noise mitigation. The circuit represents, however, just a -portion of the quantum computer operation. In the same way a classical computer -does not run ALU operations only, the quantum computer needs additional -instructions, and directives to deal with _aspects_ such as observable -measurements, randomization, batching, or shot scheduling, to mention some. The -`ExecutorProgram` interface captures all semantics needed to operate the quantum -computer. - -Once program execution is done, there is need for collecting not only computation -results, but metadata about computation, including non-sensitive intermediate and -final machine state. The `ExecutorResult` interface captures this data. - -### Samplex annotations and the samplex data structure -We discussed the need for instructions besides circuit operations. Samplex annotations -are domain specific instructions and conform a domain specific language, or _DSL_, that -augments circuit semantics to instruct the computer how to executor a randomization -protocol for enabling error mitigation techniques. Given randomization semantics are -tightly coupled to circuit operations, box annotations emerge as the natural -implementation in Qiskit. - -The samplex data structure encodes the steps for implementing randomization protocols -in a directed acyclic graph, or _DAG_. The result of executing the randomization protocol -on a circuit is the generation of potentially millions of circuit variations. Instead -of requesting the client to generate these variations and transmit them through the wire, -the `ExecutorProgram` package an optional samplex data structure to run it client-side, -saving unnecesary bandwith, and potentially performing fast template circuit hydration -withing the quantum computer runtime. +### Executor, ExecutorProgram, and ExecutorResult +The `Executor` primitive introduces a general substrate for execution in +Qiskit. A quantum circuit alone represents only part of the operation of a +quantum computer. Just as a classical computer requires instructions beyond ALU +operations, a quantum computer requires additional directives to govern +*aspects* such as observable measurements, randomization, batching, or shot +scheduling. The `ExecutorProgram` interface captures these semantics in a +portable form. + +Execution produces not only raw measurement data but also metadata about the +run, including reproducibility details and non-sensitive machine state. The +`ExecutorResult` interface provides this data in a normalized detailed here: + +TBD: insert Python class definition. + +Providers may include additional metadata (backend id, layout, noise +diagnostics, etc.) but may redact or aggregate sensitive calibration data. Each +provider is responsible for documenting what fields it returns. + +### Randomization annotations and plans +In addition to circuit operations, users need a way to express semantics for +error mitigation. **Annotations** (e.g., `Twirl`, `InjectNoise`) act as +domain-specific instructions bound to circuit regions. These form a +domain-specific language (DSL) that augments circuit semantics to express +*intent*, such as running a randomization protocol. + +Annotations are compiled into a **Randomization Plan** (vendor-agnostic version +of IBM Samplomatic's “samplex” data structure), a portable data structure describing +how to generate circuit variations. The plan is constructed **after +transpilation/layout**, ensuring that annotations refer to stable circuit regions. It +is serializable and can be transmitted efficiently to the backend. Providers then +expand the plan into potentially millions of concrete circuit variants server-side, +reducing network load and preserving reproducibility. + +The plan, together with user-defined symbols (e.g., noise maps, measurement +bases), is packaged inside the `ExecutorProgram`. This allows fast template +hydration within a provider’s runtime without requiring clients to generate or +transmit large batches of circuits. ### Noise learning -TBD +Noise learning is a provider-specific capability where the system characterizes +its own error profile. Learned artifacts such as a **noise map** can be returned +in metadata or bound into an `ExecutorProgram` as symbols (e.g., +`program.define_symbol("my_noise", noise_map)`). This RFC does not standardize a +specific noise-learning engine; it only ensures the `ExecutorProgram` can carry +such symbols in a portable way. + +TBD: how an ExecutorProgram is serialized? ### System drift between learning and mitigation -Explicit separation of noise learning and execution introduces the possibility for the -system to drift in between the construction of the noise map and its application during -mitigation. Drifting means the noise characterization may be outdated by the time the user -wants to use it for error mitigation. To warrant error mitigation happens right after -learning, the user can use runtime sessions to acquire exclusive access on the system, as -shown in the example above. +Separating noise learning from execution raises the risk of **system drift**: +the characterization may become outdated between the time a noise map is built +and when it is applied in mitigation. To reduce this risk, providers may offer +*session-like constructs* that keep system state stable across a sequence of +runs. In the IBM Runtime, for example, sessions can provide exclusive access so +that noise learning and subsequent mitigation are performed back-to-back. + +This RFC does not mandate sessions or exclusivity; these remain provider-owned +features. The important point is that the `ExecutorProgram` substrate can +represent both noise-learning and noise-mitigated execution, and users can +combine them in a controlled workflow when supported. + +### Relation to existing primitives +While this RFC does not replace existing primitives, it introduces a substrate +that could host them. In particular, `Sampler` and `Estimator` can be +re-implemented as thin profiles on top of the `Executor` abstraction. This would +allow users to keep their familiar APIs while providers optimize around a single +execution foundation. Such a reimplementation is left to future RFCs. ### Security and privacy considerations From 0d6acf3ae48e59f84a1629c61be4ab91967972e0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Tue, 23 Sep 2025 10:14:18 +0530 Subject: [PATCH 22/23] Update 0023-executor-primitive.md Co-authored-by: Samuele Ferracin --- 0023-executor-primitive.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index d80a931..d77f326 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -131,8 +131,8 @@ with Session(backend=backend) as session: job = executor.run(noise_learner) result = job.result() - # Extrac noise map - noise_map = { layer: model for zip(circuit_layers, result } + # Extract noise map + noise_map = { layer: model for zip(circuit_layers, result) } # Preparing a quantum program for noise-aware sampling program = QuantumProgram(shots=1024) From 1787c5bf200fa06591abdf4554a5a12c93983da2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Salvador=20de=20la=20Puente=20Gonz=C3=A1lez?= Date: Tue, 23 Sep 2025 10:33:29 +0530 Subject: [PATCH 23/23] Highlight lazy randomization expansion. --- 0023-executor-primitive.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/0023-executor-primitive.md b/0023-executor-primitive.md index d77f326..f351b82 100644 --- a/0023-executor-primitive.md +++ b/0023-executor-primitive.md @@ -264,7 +264,7 @@ These considerations do not affect the core `Executor` interfaces, but they are important for implementers to address in provider-specific documentation. ## Alternative Approaches -An alternative to introducing the **samplex** DAG is to generate all circuit +An alternative to introducing the randomization plan DAG is to generate all circuit variations entirely on the client side and transmit them to the backend for execution. This approach offers maximum flexibility and complete control over how variations are produced, since the backend would simply execute the @@ -280,16 +280,21 @@ execution time, and places substantial demands on both client and backend infrastructure. It also complicates reproducibility across vendors, since each vendor may handle large‑batch execution differently. -By contrast, the **samplex** DAG allows users to describe their variation +By contrast, the randomization plan allows users to describe their variation generation strategies in a portable, serialized form that can be transmitted efficiently. The backend can then expand these strategies into actual circuit variations locally, reducing network load while preserving user control over error mitigation techniques. +Yet another alternative would have been sending a circuit template and a set +of parameters on the wire for server parametrization although server expansion +of the plan enables lazy generation of parameters where new parameters can be +generated "on the fly" while other already-parametrized circuits are running. + An intermediate solution would have been to save the user from generating the -samplex in the client, sending the annotated circuit only. However, local -inspectability and debuggability would require local generation of the samplex -DAG anyhow. More importantly, the compute model becomes simpler and honors its main +plan in the client, sending the annotated circuit only. However, local +inspectability and debuggability would require local generation of the reandomization +plan anyhow. More importantly, the compute model becomes simpler and honors its main responsibillity: execution. It is worth noting that earlier drafts of this RFC explored introducing the