03 Layered Architecture¶

Purpose¶

This chapter defines the layered architecture of the reference framework.

Design Principle¶

The reference Word drafts state the governing principle succinctly: unify control information, not the physical carrier. This repository preserves that principle as a normative architectural rule.

Superconducting, ion-trap, neutral-atom, spin, photonic, and simulator-oriented backends may therefore share a common control plane while preserving technology-specific execution details.

Layers¶

QOS Layer¶

The QOS layer contains runtime concerns such as session management, job submission, scheduling, resource management, auditing, and orchestration. It is the system-level context in which canonical programs are validated, bundled, exported, scheduled, and executed.

UQCI Layer¶

The UQCI layer contains canonical program objects, validation semantics, bundle semantics, and backend-independent execution intent. This is the layer where semantic meaning is defined and preserved.

OpenQASM Layer¶

The OpenQASM layer provides compatibility bindings, export profiles, and toolchain interchange. It is an exchange representation, not the canonical semantic kernel.

Backend Layer¶

The backend layer performs legality checks, resource allocation, scheduling, compilation, execution, and diagnostics according to concrete hardware or simulator semantics.

Cross-Technology Interpretation¶

The architecture is intentionally designed to support different physical realization routes without pretending they are physically identical. Representative backend families discussed in the source drafts include:

superconducting systems using microwave drive, flux-style control, and resonator readout
ion-trap systems using optical and RF control with fluorescence-style measurement
neutral-atom systems using optical tweezers, Rydberg interactions, and imaging-style readout

These examples illustrate that a shared control plane does not require a shared carrier vocabulary at the physical layer.

Required Separation¶

The following separations are normative:

canonical protocol semantics must remain outside backend-specific modules
compatibility/export logic must remain separate from canonical object ownership
runtime/orchestration concerns must not be conflated with OpenQASM export logic
device and calibration details must remain in sidecar artifacts and backend logic

Reference Flow¶

The layered path implied by the Word drafts is:

UQCI canonical program -> optional OpenQASM compatibility export -> backend driver lowering -> execution

In repository practice, that path is embedded in a broader QOS workflow:

UQCI program -> validation -> bundle formation -> compatibility export when needed -> backend planning -> execution -> standard results

This flow ensures that portability and exchange remain available without allowing compatibility artifacts to redefine semantic ownership.

Architectural Outcome¶

The architectural outcome is a framework that is:

semantically canonical at the protocol layer
flexible at the backend layer
practical at the compatibility layer
open to future runtime expansion at the QOS layer