Quantum systems
QSHL
Quantum Self-Healing Language
Connecting quantum program intent with execution evidence.
QSHL is evolving toward a vendor-neutral assurance layer that investigates whether the intended experiment survives compilation, provider transformation, physical execution, and result interpretation.
Experimental quantum assurance researchExplore execution assurance
Program intentExpress expectations
- Program structure
- Resource constraints
- Correction intent
QSHL assuranceConnect intent to checks
- Execution contracts
- Structural checks
- Evidence boundaries
Execution evidenceExamine what returned
- Compiled structure
- Measured outcomes
- Decoder behavior
Existing compiler and contract toolingBroader assurance remains research
The problem
Did the intended experiment survive execution?
A quantum experiment can pass through source translation, compilation, provider transformations, hardware execution, retrieval, decoding, and interpretation before it becomes a scientific claim.
A successful submission is not enough to establish that the resulting execution still represents the experiment the researcher intended.
QSHL's expanding research question is how to connect explicit expectations with inspectable execution evidence, and distinguish structural integrity from measured correction performance.
Where QSHL sits
Assurance alongside the quantum stack.
QSHL is intended to complement platforms such as CUDA-Q, Qiskit, and Amazon Braket, not replace their compilers, logical runtimes, or decoder ecosystems.
Researchers define intent
The experiment begins with the program, expected structure, and conditions under which its result can support a claim.
Platforms execute work
Quantum software and provider infrastructure remain responsible for their own compilation and execution paths.
QSHL examines evidence
The assurance direction connects intended structure with available compiled-program and execution evidence.
Claims keep their scope
Structural checks, hardware execution, and logical-performance improvement remain distinct questions.
NVIDIA's CUDA-Q Logical preview expands logical and QEC workflows. Increasingly capable platforms reinforce QSHL's direction toward independent assurance rather than another competing compiler stack. This describes an architectural role, not completed integrations, a partnership, or endorsement.
From compiler to assurance
The compiler is infrastructure for a larger question.
QSHL began by investigating whether reliability constraints could become part of the quantum programming model. Its Rust compiler made ownership, coherence budgets, and correction intent explicit concerns of the program.
Static analysis, deterministic simulation, hardware execution, circuit reconstruction, and decoder experiments created an experimental path from source intent to measured results.
That work exposed a broader assurance problem: source-level checks alone cannot establish what survived downstream transformations. The compiler remains one source of intent, structure, and expectations for verification.
What exists today
Research infrastructure with concrete execution paths.
The existing tooling includes a Rust compiler and a separate Python provider and contract-analysis toolchain. Physical-QPU work uses that Python workflow, not an independently demonstrated Rust submission path.
| Capability | Current state | Scope |
|---|---|---|
| Quantum ownership checks | Implemented in the Rust compiler. | Covers the currently tested misuse cases in the compiler corpus. |
| Coherence-budget analysis | Implemented as static analysis. | Models declared coherence constraints; it does not guarantee physical hardware timing. |
| OpenQASM 3 | Text emission implemented. | Backend execution remains configuration-specific. |
| QIR | Text emission implemented. | External QIR execution is not currently established. |
| Simulator path | Controlled recovery experiments supported. | Results apply to defined small-code/error-model configurations. |
| Rigetti lowering | Used in the physical-QPU workflow. | Exercised with one provider/device family. |
| Results & decoder paths | Result processing and deferred decoding implemented. | No optimal-matching claim. |
| Native execution manifests | Emitted by native lowering. | Record entangler expectations, physical pairs, and readout mapping for supported lowering paths. |
| Experiment-contract checks | Implemented in the Python toolchain. | Inspect selected emitted and retrieved compiled-program structure; not a general semantic-equivalence proof. |
Syndrome-generation and deferred-correction paths support controlled small-code experiments. Decoder comparison work uses a greedy decoder and an exact small-code reference; it does not establish a scalable optimal-matching decoder.
Hardware execution
QSHL-emitted circuits reached physical quantum hardware.
QSHL-emitted circuits were executed on Rigetti Cepheus-1-108Q through Amazon Braket, demonstrating an end-to-end path from compilation and circuit emission to physical QPU execution and result processing.
Evidence progression
From compiler capability to measured result.
- Compiler & Runtime
Compilation, static checks, emission, simulation, and result-processing paths are present.
- Physical QPU Execution
QSHL-emitted circuits reached the tested Rigetti hardware through Amazon Braket.
- Structural Reproduction
Archived campaign artifacts reproduced the expected circuit structure and experiment setup.
- Correction Experiment
A distance-3 configuration and deferred-decoding path were exercised.
- Measured Result
The tested configuration produced little or no meaningful logical-performance improvement.
What the experiments taught us
The pipeline reached the QPU. The tested correction configuration did not materially improve logical performance.
Executing a correction workflow and demonstrating useful logical improvement are different technical achievements.
Compiler-to-hardware execution was demonstrated.
The tested workflow connected compilation, circuit emission, native Rigetti lowering, physical QPU execution, and result processing.
Little or no meaningful logical-performance improvement.
The tested distance-3 correction and deferred-decoding configuration did not materially improve the selected logical outcome on the tested hardware.
The correction result applies to the tested circuit, decoder, mapping, device, and campaign. It does not negate the demonstrated compiler-to-hardware pipeline. Nor does successful execution prove that every downstream transformation preserved the intended experiment. Independent structural checks and scoped performance measurements are both needed.
Execution integrity
Connect the contract with the execution.
The emerging assurance architecture links program expectations to transformed structure, retrieved evidence, decoder behavior, and the claims drawn from a result.
Concept architecture
An assurance role across the execution chain.
This is the research direction, not a demonstration of a completed cross-stack platform.
- Program intent
Define the experiment and its expected structure.
- QSHL contract / assurance
Express the expectations to be checked.
- Quantum software stack
Use the selected platform's own tooling.
- Provider transformation
Examine available compiled-program structure.
- Hardware execution
Execute the provider-supported experiment.
- Execution evidence
Retain available structure, results, and context.
- QSHL verification
Compare evidence with the contract and bound the claim.
Existing experiment contracts inspect selected properties such as entangling structure and readout-basis requirements. The normal contracted analysis path rejects missing compiled-program evidence or failed structural checks before reporting metrics.
This is fail-closed behavior for those checks, not proof of full semantic equivalence. Connectivity checks depend on supplied topology and parsable operands; excess entanglers can be warnings unless stricter expectations are supplied.
An unverified analysis bypass also exists. Extending these scoped gates into comprehensive execution reconstruction and correction-validity enforcement remains a research task.
Current research boundary
Experimental quantum assurance research.
Existing compiler, contract-checking, simulation, decoder, and hardware research support the assurance direction. They do not yet establish a production-ready vendor-neutral verification platform.
Concrete tooling. Broader assurance ahead.
QSHL retains its functioning experimental compiler-to-hardware pipeline while developing independent execution assurance. Selected structural checks are implemented; comprehensive cross-stack coverage remains open.
- Leaked-qubit handling currently produces a warning rather than a hard rejection.
- No formal soundness or completeness proof is claimed for the checker.
- Hardware execution covers the tested Rigetti device family; it is not cross-device validation.
- The tested correction configuration did not establish useful logical error correction.
- QIR support currently covers text emission only.
- Structural checks are not a general proof that two programs are semantically equivalent.
- No general fault tolerance or production fault-tolerant execution is established.
Where it goes next
Independent verification, grounded in evidence.
These are research and product directions, not completed capabilities of a production assurance platform.
Vendor-neutral contracts
Investigate portable execution expectations and cross-stack verification without duplicating the underlying platforms.
Reproducible execution evidence
Develop broader reconstruction and evidence preservation so experimental claims can be independently examined.
Hardware-aware analysis
Study how calibration and device evidence can inform expected-versus-observed comparisons without assuming a hardware-independent gain.
Correction validity
Extend syndrome and decoder comparisons toward correction-validity checks, and investigate feedback-driven reliability only where evidence supports it.
Technical resources
Public technical brief in preparation.
A concise brief is being prepared to explain the evolution toward execution assurance, existing compiler and contract tooling, hardware and structural-reproduction work, the scoped correction result, and future research boundaries.