15 Mock Backend Strategy¶

Purpose¶

This chapter defines the role and design principles of mock backends in v0.1.

Core Requirement¶

Mock backends must exercise the architecture meaningfully without pretending to be complete hardware implementations.

Role of Mock Backends¶

Mock backends are a conformance and developer-enablement mechanism. They exist to prove that the canonical core can drive multiple hardware families without embedding hardware-specific assumptions into the core model layer.

Mock backends SHALL:

accept canonical UQCI-side program and bundle inputs
implement the standard backend flow
return standard RunResult objects
expose representative diagnostics
remain lightweight enough for repository-native tests and examples

Mock backends SHALL NOT claim physical fidelity or production readiness.

In v0.1, mock backends are not incidental examples. They are part of the reference strategy for proving that the canonical core, bundle model, and driver contract can operate across more than one technology family.

Standard Backend Flow¶

Every mock backend in the reference repository SHOULD exercise the following stages:

validate_ir
allocate_resources
schedule
compile
run
diagnostics

This flow is intentionally uniform so that future backends can vary in implementation detail without changing the canonical contract.

Current v0.1 Repository Scope¶

The current repository includes two runnable mock backends:

SuperconductingMockBackend
NeutralAtomMockBackend

It also includes a reserved placeholder for a future ion-trap mock backend. This combination is deliberate: v0.1 proves architectural diversity without claiming complete platform coverage.

Superconducting Mock¶

The superconducting mock backend SHOULD represent a microwave-driven gate model with measurement and optional flux or coupler semantics. Representative behaviors include:

qubit drive channels for single-qubit microwave control
readout channels for measurement capture
optional coupler or flux hints for two-qubit interactions
timing slots consistent with resonator-style measurement windows

The purpose is not to simulate an exact superconducting stack, but to make superconducting-specific resource and scheduling assumptions explicit and testable.

Neutral-Atom Mock¶

The neutral-atom mock backend SHOULD represent optical control and imaging-oriented readout. Representative behaviors include:

optical control resources for site or zone addressing
Rydberg-style entangling semantics or blockade-inspired constraints
imaging-style measurement or occupancy capture
array or site topology rather than qubit-line assumptions

This backend demonstrates that the same canonical model can cover a non-microwave platform without changing the UQCI core.

Why Mocks Exist in v0.1¶

Mock backends exist in v0.1 for four reasons:

to validate the separation between canonical models and backend realization
to keep tests and examples runnable without real hardware dependencies
to expose backend lifecycle stages in an inspectable form
to create a stable path toward future semi-real or real adapters

Deterministic Execution¶

Mock execution SHOULD produce deterministic or reproducible pseudo-random results. The repository SHOULD prefer reproducibility over realism so that:

tests remain stable
examples are easy to verify
diagnostics remain comparable across runs

When pseudo-random behavior is used, the seeding rule SHOULD be explicit.

Limits of the Mock Strategy¶

Mock backends are intentionally limited. They should not be interpreted as:

full physical simulators
production control systems
vendor certification artifacts
exhaustive models of pulse-native hardware behavior

They are architecture and conformance tools first.

Extensibility Principle¶

The mock backend strategy SHALL leave room for a future ion-trap backend and additional platform families. For that reason, mock backend APIs SHOULD emphasize common lifecycle stages and standard outputs rather than hard-coded assumptions about one platform's signal vocabulary.