07 DeviceSpec

Purpose

This chapter defines the DeviceSpec model.

Role

DeviceSpec is the normative device-declaration sidecar. It describes backend capability and execution-relevant structure without collapsing the canonical model into vendor-native implementation detail.

In the reference Word drafts, devicespec.json is the artifact that expresses device class, topology, logical channels, native operations, clocking information, and resource constraints. This repository preserves that role.

Device Identity and Platform Type

A conforming DeviceSpec should identify the target device or backend family clearly enough for validation, planning, and diagnostics. At minimum, the model should describe:

• device identity
• platform type
• optional vendor or implementation labels when useful

Platform type is especially important because it anchors capability interpretation across hardware families such as superconducting, ion-trap, neutral-atom, spin, or photonic platforms.

Required Contents

A conforming DeviceSpec should describe:

• backend family or platform type
• addressing model and topology
• available channels or logical control resources
• native operation capability
• timing properties and scheduling constraints
• readout and calibration-related metadata when relevant

The source drafts also imply the following structural categories:

• topology information, typically expressed as nodes and edges or an equivalent addressing graph
• logical channels and carrier classifications
• native operation capability declarations
• timing and clock information
• explicit constraints and concurrency limits

Channels and Logical Control Resources

The channel layer in DeviceSpec should describe logical control resources rather than pretending that all platforms expose the same physical interface.

Representative channel-related information includes:

• channel identifiers
• carrier types such as microwave, rf, optical, dc, virtual, or readout
• optional frequency ranges
• optional time resolution
• exclusivity or locking behavior
• resource tags for scheduling or diagnostics

This representation is meant to support execution planning across very different hardware families without flattening them into one carrier model.

Native Operations and Timing

DeviceSpec should describe which operations are natively supported by the target device or backend. Representative fields include:

• operation name
• target arity or target count
• carrier association when relevant
• implementation hints when relevant

Timing-related content should describe the backend timing envelope in a way that validators and schedulers can consume. Typical timing information includes:

• minimum slot or tick resolution
• optional global clock information
• support for absolute timing
• support for relative timing

Constraints and Readout Context

The reference drafts treat constraint information as execution-relevant, not descriptive ornament. DeviceSpec may therefore capture constraints such as:

• coupling conflicts
• blockade radius restrictions
• shared motional or beam resources
• readout multiplexing limits
• exclusivity zones or resource locks

Readout and calibration-related fields may also appear when they help define the capability envelope, but they should remain declarative rather than replacing CalSet.

Examples Of Platform Diversity

Typical platform families include:

• superconducting
• ion trap
• neutral atom
• spin
• photonic

The model must be capable of representing all of them without assuming that microwave, optical, RF, or imaging semantics are globally universal.

Normative Rule

DeviceSpec is not merely documentation. It is an execution-relevant declaration used by validators, planners, schedulers, lowering logic, and backend drivers.

It should therefore be stable enough to support:

• legality checks
• scheduling decisions
• routing or placement hints where applicable
• capability-aware export and lowering behavior
• reproducible bundle interpretation

Boundary Rule

DeviceSpec should describe capability and constraint envelopes, not every vendor-private implementation detail. Vendor-native realization remains the responsibility of backend modules and driver-specific compilation logic.

This boundary is important to the architecture. UQCI remains canonical, DeviceSpec remains declarative, and backend-native realization remains downstream of both.