16 Non-Goals¶

Purpose¶

This chapter explicitly states what the current version does not attempt to solve.

Core Requirement¶

Non-goals must be documented clearly to prevent architectural drift and over-claiming.

General Principle¶

This specification and reference repository are intentionally narrow in v0.1. The aim is to establish a coherent canonical protocol layer, normative sidecar artifacts, compatibility export rules, and executable reference tooling. It is not to solve every layer of a production quantum operating system.

Explicit Non-Goals for v0.1¶

The following items are out of scope for the current version:

real hardware integration with production devices
a complete OpenQASM parser or full OpenQASM 3 implementation
a universal pulse compiler for all backend families
complete routing, placement, and optimization pipelines
production-grade runtime orchestration or cluster scheduling
vendor certification, compliance claims, or formal standards-body adoption
GUI tooling, dashboards, or operator consoles

The repository also does not attempt, in v0.1, to standardize every future artifact hinted at in extension discussions such as routing patches, diagnostics traces, or backend capability catalogs.

Architectural Clarifications¶

The repository does not claim that OpenQASM alone is sufficient to represent all runtime semantics. It also does not claim that QOS is reducible to a text language. QOS remains the systems and orchestration viewpoint, UQCI remains the canonical protocol layer, and OpenQASM remains a compatibility and exchange layer.

Likewise, the repository does not claim that one physical control vocabulary can erase the differences between superconducting, ion-trap, neutral-atom, photonic, or future platforms.

The repository also does not treat mock backends as evidence that hardware integration is solved. Their purpose is to validate the architecture, not to stand in for production control stacks.

Documentation and Scope Discipline¶

The migration from Word drafts to repository-native Markdown does not mean every appendix, long listing, or illustrative note should become normative main-body prose. v0.1 remains disciplined by:

keeping full machine-readable schemas in repository schema files
keeping runnable examples in examples/
keeping backend implementation detail in code and backend-focused docs
keeping the main specification focused on architecture, contracts, and artifact roles

Why These Non-Goals Matter¶

These exclusions protect the architecture from two common failures:

over-centralizing everything into a single textual export format
overfitting the canonical core to one backend family too early

By documenting these limits explicitly, the repository remains implementable, testable, and standardization-friendly.