Dynamic Circuits and Runtime Control

Static circuits are only one point in the quantum programming design space. As systems mature, more useful workloads will depend on mid-circuit measurement, reset, conditional logic, timing constraints, feed-forward, and eventually real-time decoder interaction.

Dynamic control changes operations. It introduces timing SLOs, controller capability profiles, compiler restrictions, and new failure modes. OpenQASM 3 explicitly includes timing concepts and pulse-level calibration hooks, while QIR and adaptive profiles aim to represent richer hybrid control across compilers and targets [R110] [R112]. CUDA-Q's recent realtime direction similarly reflects the need to connect QPUs, controllers, CPUs, and GPUs in tighter loops [R111].

62.1 Static versus dynamic execution

flowchart TB
    Static[Static circuit] --> CompileOnce[Compile once]
    CompileOnce --> ExecuteAll[Execute all gates]
    ExecuteAll --> MeasureEnd[Measure at end]

    Dynamic[Dynamic circuit] --> CompileProfile[Compile with control profile]
    CompileProfile --> Segment[Execute segment]
    Segment --> MidMeasure[Mid-circuit measure]
    MidMeasure --> Branch[Classical branch / feed-forward]
    Branch --> Segment

Dynamic execution requires both quantum operations and bounded-latency classical decisions.

62.2 Runtime-control taxonomy

flowchart LR
    Control[Runtime control] --> Param[Near-time parameter binding]
    Control --> Mid[Mid-circuit measurement]
    Control --> Reset[Conditional reset]
    Control --> Branch[Classical branch]
    Control --> Loop[Bounded loop]
    Control --> Decode[Decoder feedback]

Each class requires a capability declaration. A platform should not say “dynamic circuits supported” without specifying which features and timing envelopes are supported.

62.3 Capability profiles

flowchart TB
    Program[Program] --> Required[Required control profile]
    Target[Target] --> Offered[Offered control profile]
    Required --> Match{Compatible?}
    Offered --> Match
    Match -- yes --> Compile[Compile]
    Match -- no --> Reject[Reject or rewrite]

A control profile should include:

62.4 Timing as an API constraint

OpenQASM's timing constructs exist because relative timing and delays matter for hardware-independent design intent [R110]. Runtime systems need a similar operational view.

sequenceDiagram
    participant Q as Qubit operation
    participant M as Measurement
    participant C as Controller
    participant G as Conditional gate
    Q->>M: produce measurement signal
    M->>C: classify result
    C->>G: branch decision
    G-->>Q: execute conditional operation

The timing budget includes measurement integration, signal transport, classification, branch decision, instruction dispatch, and operation start.

62.5 Failure modes

flowchart TB
    DynamicFailure[Dynamic failure] --> Late[Feedback too late]
    DynamicFailure --> Wrong[Incorrect branch condition]
    DynamicFailure --> Unsupported[Unsupported operation in branch]
    DynamicFailure --> Drift[Timing drift]
    DynamicFailure --> Compiler[Compiler/profile mismatch]
    DynamicFailure --> Evidence[Incomplete trace]

Failures in dynamic circuits can be silent. A branch may execute but violate the timing intent. Evidence packages must capture timing metadata, branch traces when feasible, and target control profile hashes.

62.6 Dynamic-circuit admission control

flowchart LR
    Request[Dynamic workload] --> Profile[Extract required profile]
    Profile --> Target[Compare target profile]
    Target --> Timing[Check timing SLO]
    Timing --> Cost[Estimate shots and queue]
    Cost --> Decision{Admit?}
    Decision -- yes --> Run[Run]
    Decision -- no --> Rewrite[Rewrite / reschedule]

Admission should reject workloads that a target can nominally compile but cannot execute within timing or evidence requirements.

62.7 Evidence for dynamic runs

flowchart TB
    DynamicRun[Dynamic run] --> Circuit[Static structure]
    DynamicRun --> Branches[Branch specification]
    DynamicRun --> Profile[Control profile]
    DynamicRun --> Timing[Timing report]
    DynamicRun --> Counts[Observed outputs]
    DynamicRun --> Diagnostics[Controller diagnostics]

Evidence should answer:

• Which branches were possible?
• Which branches were observed?
• What timing constraints were declared?
• Which controller and target profile executed the workload?
• Were any shots dropped or classified late?

62.8 Dynamic control and error correction

flowchart TB
    Rounds[Repeated syndrome-extraction rounds] --> Stream[Syndrome stream]
    Stream --> Decoder[Pipelined decoder]
    Decoder --> Frame[Pauli-frame updates]
    Frame --> Feedforward[Feed-forward when required]
    Frame --> Readout[Interpret logical readout]

Fault-tolerant systems need repeated syndrome extraction and decoding throughput that keeps up with the syndrome stream. A decoder can have a latency longer than one extraction round while operating as a pipeline. Corrections can often be tracked in a classical Pauli frame; feed-forward must meet the deadline of the logical operation that actually depends on it. The dynamic-control discipline developed for NISQ-era circuits helps support these logical-qubit operations. [R126]

62.9 Compiler implications

flowchart LR
    Source[Source program] --> IR[Intermediate representation]
    IR --> Profile[Control profile lowering]
    Profile --> Schedule[Timing-aware schedule]
    Schedule --> Executable[Executable artifact]

Dynamic circuits make IR choice operational. A representation that cannot express timing, measurement, classical control, or profile restrictions cannot preserve intent across toolchains.

62.10 Operating rule

Dynamic control is not a feature checkbox. It is a contract among program, compiler, controller, hardware, and evidence system.

flowchart LR
    Program[Program] --> Contract[Control contract]
    Contract --> Compiler[Compiler]
    Contract --> Controller[Controller]
    Contract --> Hardware[Hardware]
    Contract --> Evidence[Evidence]

When the contract is explicit, dynamic circuits become an engineering capability. When it is implicit, they become a source of irreproducible results.

Additional technical sources: [R5].