Cross-cutting Concepts

In this section, we describe concepts whose implementation concerns many building blocks across the stack. More specifically, this includes concepts that can be implemented on either of the three layers (or on a combination of them), and tools that depend on all layers.

Fault Tolerance

Noise is deemed one of the most severe limitations of today's quantum computing devices¹. Many methods in Quantum Error Correction, Quantum Error Mitigation and Quantum Error Suppression have been developed to reduce noise with different techniques. Experts suggest that several methods will likely be combined to achieve optimal performance. These methods vary greatly in the mathematical concepts behind them as well as the environments they can be used.

Within the FullStaQD reference architecture, we identify three typical places for implementing fault tolerance measures:

1. Firmware-bundled: Some hardware vendors suggest that they want to bundle highly optimised and highly device-specific error correction and supression techniques within their device firmware (see Physical Layer). Such measures would effectively be hidden in the device such that higher layers could treat the quantum device's logical qubits as physical qubits with an improved error rate.

2. Compilation: Researchers often frame Quantum Error Correction as a compilation step that maps logical operations to their physical, fault-tolerant implementations. Such an approach could be implemented as a compilation pass within the System Layer's Compiler. As the Compiler can access figures of merit from its compilation target, QEC compilation passes can implement their mapping while respecting the physical device's topology and fidelities.
   

   Similarly, some Quantum Error Suppression and Quantum Error Mitigation techniques could be injected into the program through compilation passes. This allows the compiler to apply them automatically while still being able to tailor them to the target device.

3. Application-specific: Some Quantum Error Mitigation and Quantum Error Correction techniques are highly application-specific and could be implemented along with the Use Case implementation in the Application Layer. Common primitives and utilities for implementing these techniques can also be part of Quantum SDKs and related libaries (see Application Layer).

Monitoring

Large-scale deployments of quantum software systems will require extensive monitoring to allow operators to ensure smooth operation of these systems. Such monitoring will be most useful when it captures montoring data (such as logs and metrics) across all components that run live during the execution of quantum software workloads, and when individual datapoints can be traced to the corresponding workloads.

Monitoring will require a separate data collection building block that all layers can access. For the extraction of logs and metrics, two common patterns are to be expected:

• Data-producing components can implement routines that directly send metrics and logs to the data collection component. This would make such components depend on the data collection interface, which is only likely for tighly integrated systems or when a common data collection interface emerges.
• Lightweight wrapper components can extract logs and metrics from individual data-producing components. This approach introduces some overhead but decouples the data collection component from the rest of the stack.

Besides data collection, there will need to be an interface that allows operators to access monitoring data. Such a component could be a standalone tool, or it could be bundled with integration tooling in the Application Layer or the data collection component itself.

Authentication and Metering

In cloud and HPC environments where multiple users can submit workloads, access to resources needs to be controlled through an authentication mechanism and resource usage must be recorded to enable billing or budgeting.

Design and Development Support Tooling

Some quantum software tools are not directly part of the implementation of quantum software stacks but instead aim to support their design and development process. A key characteristic of these tools is that they are not fully automated but instead support a developer's implementation decisions. Furthermore, many of these tools go across the boundaries of individual layers to enable a holistic treatment of the quantum software stack.

Typical examples for Design and Development Support Tooling include:

• Low-code tools for assembling quantum applications (e.g. the ProvideQ Toolbox's visual problem decomposition tools, Kipu Quantum Workflows based on CAMUNDA, or the QuaST Decision Tree)
• Agentic AI Tools supporting the the choice of components and algorithms, or supporting the implementation of business use cases with quantum algorithms (e.g. Kipu Quantum's Paqari AI Agent)
• Integrated Development Environments (IDEs) (e.g. the IBM Quantum Composer for editing OpenQASM and Qiskit programs)
• Visualisation tools for inspecting the results of quantum computations, intermediary results or monitoring data
• Testing, benchmarking and verification tools