Optimization, Sampling, and Decision Workflows

Optimization and sampling workloads are attractive because they map naturally to business language: routing, scheduling, allocation, design, portfolio construction, and constraint satisfaction. They are also dangerous because almost every organization already has strong classical heuristics. A quantum workflow must therefore be evaluated against operational baselines, not against toy examples.

D-Wave documents Ocean as a suite of tools for using quantum computers and hybrid solvers [R56], and its hybrid documentation distinguishes direct QPU submission from hybrid solvers that can accept broader quadratic and nonlinear models [R57]. Gate-based workflows often use variational approaches such as QAOA, which Qiskit Algorithms documents as a SamplingVQE-derived algorithm with a depth parameter controlling the ansatz repetition count [R52].

29.1 The decision-workflow pattern

Diagram loads as you read

29.1 The decision-workflow pattern · Figure 1

View diagram source

flowchart LR
    Decision[Decision problem] --> Model[Math model]
    Model --> Baseline[Classical baseline]
    Model --> Quantum[Quantum candidate]
    Quantum --> Samples[Samples / candidate solutions]
    Samples --> Repair[Constraint repair]
    Repair --> Score[Objective scoring]
    Baseline --> Compare[Decision comparison]
    Score --> Compare
    Compare --> Action[Operational decision]

The output is usually not “the answer.” It is a set of candidate solutions with scores, constraint status, uncertainty, and comparison to existing methods.

29.2 Model forms

Optimization teams need a translation layer from domain models to solver-ready forms.

Diagram loads as you read

29.2 Model forms · Figure 2

View diagram source

flowchart TB
    Domain[Domain problem] --> MILP[MILP / CP-SAT]
    Domain --> QUBO[QUBO]
    Domain --> Ising[Ising Hamiltonian]
    Domain --> Nonlinear[Nonlinear model]
    QUBO --> Annealing[Annealing / hybrid solver]
    Ising --> Gate[Gate-based variational workflow]
    MILP --> Baseline[Classical baseline]
    Nonlinear --> Hybrid[Hybrid decomposition]

Model-choice table:

Form	Strength	Risk
MILP / CP-SAT	strong classical baselines	may not map cleanly to QPU
QUBO	natural for annealing and some hybrid solvers	penalties can be brittle
Ising Hamiltonian	natural for QAOA-style workflows	compilation and measurement cost
nonlinear model	expressive for business problems	solver behavior can be opaque
custom hybrid decomposition	can exploit structure	more engineering complexity

29.3 Constraint strategy

Constraints are where many optimization demonstrations fail. Penalty weights can make feasible solutions hard to find or make objective quality meaningless.

Diagram loads as you read

29.3 Constraint strategy · Figure 3

View diagram source

flowchart TB
    Constraints[Constraints] --> Hard[Hard-coded in encoding]
    Constraints --> Penalty[Penalty terms]
    Constraints --> Repair[Post-solve repair]
    Constraints --> Reject[Reject invalid samples]
    Hard --> Validity[Validity profile]
    Penalty --> Validity
    Repair --> Validity
    Reject --> Validity

Constraint decision record:

Illustrative listing · yaml

constraint_strategy:
  problem_id: string
  constraints:
    - name: string
      type: hard_encoded|penalty|repair|reject
      penalty_weight: float|null
      validation_test: string
      violation_cost: string
  feasibility_target: float
  repair_policy: string|null

A solution that requires extensive repair may still be useful, but it should not be reported as a raw solver win.

29.4 Penalty tuning loop

Diagram loads as you read

29.4 Penalty tuning loop · Figure 4

View diagram source

flowchart LR
    Weights[Penalty weights] --> Solve[Solve / sample]
    Solve --> Feasible[Feasibility rate]
    Solve --> Objective[Objective quality]
    Feasible --> Tune[Tune weights]
    Objective --> Tune
    Tune --> Weights

Penalty tuning metrics:

Metric	Interpretation
feasible sample rate	how often constraints are satisfied
best feasible objective	decision quality among usable samples
invalid high-score rate	whether penalties are too weak
all-same-sample rate	whether penalties dominate objective
repair distance	how much post-processing changes solutions

Penalty tuning should be part of the experiment log, not an invisible preprocessing step.

29.5 Sampling as an asset

Some quantum and quantum-inspired workflows are better understood as candidate-generation systems than exact optimizers.

Diagram loads as you read

29.5 Sampling as an asset · Figure 5

View diagram source

flowchart TB
    Sampler[Sampler] --> CandidateSet[Candidate set]
    CandidateSet --> Diversity[Diversity analysis]
    CandidateSet --> Feasibility[Feasibility analysis]
    CandidateSet --> Elite[Elite selection]
    Elite --> LocalSearch[Classical local search]
    LocalSearch --> Decision[Decision proposal]

Candidate-set report:

Field	Purpose
sample count	defines search effort
unique sample count	measures diversity
feasible count	measures constraint handling
best objective	supports decision value
objective distribution	shows tail behavior
repair distance	shows raw vs processed quality
baseline comparison	prevents isolated claims

Diversity can be valuable even when the best solution is not better than the classical incumbent.

29.6 Hybrid decomposition

Large optimization problems usually need decomposition. The quantum component may solve subproblems, generate candidates, improve neighborhoods, or diversify search.

Diagram loads as you read

29.6 Hybrid decomposition · Figure 6

View diagram source

flowchart LR
    Large[Large problem] --> Decompose[Decompose]
    Decompose --> SubA[Subproblem A]
    Decompose --> SubB[Subproblem B]
    Decompose --> SubC[Subproblem C]
    SubA --> Quantum[Quantum / hybrid solve]
    SubB --> Classical[Classical solve]
    SubC --> Quantum
    Quantum --> Merge[Merge candidates]
    Classical --> Merge
    Merge --> Improve[Classical improvement]
    Improve --> Large

Hybrid-design questions:

Question	Why it matters
What subproblem is sent to the QPU or hybrid solver?	defines value of quantum component
How are boundaries chosen?	affects solution quality
How are subproblem results merged?	avoids local inconsistency
What classical improvement is applied?	prevents unfair comparisons
What is the ablation?	isolates quantum contribution

29.7 Gate-based optimization workflow

Gate-based optimization often follows a parameterized circuit loop.

Diagram loads as you read

29.7 Gate-based optimization workflow · Figure 7

View diagram source

sequenceDiagram
    participant Model as Ising/QUBO model
    participant Circuit as QAOA circuit builder
    participant OptimizerActor as Optimizer
    participant QPU as Backend
    participant Eval as Evaluator
    Model->>Circuit: build cost operator
    OptimizerActor->>Circuit: propose parameters
    Circuit->>QPU: execute sampled circuit
    QPU->>Eval: counts
    Eval->>OptimizerActor: expected cost + uncertainty
    Eval->>Model: candidate solutions

Operational concerns:

Concern	Mitigation
depth grows with repetitions	set target-specific depth caps
cost landscape is noisy	use robust optimizers and replicated evaluations
output bitstrings violate constraints	use encoding, penalty, or repair strategy
sample count drives cost	use adaptive shot allocation
objective evaluation is custom	version scoring code as an artifact

29.8 Annealing and hybrid-solver workflow

Annealing-style and hybrid optimization services often expose a higher-level modeling interface than gate-based circuits.

Diagram loads as you read

29.8 Annealing and hybrid-solver workflow · Figure 8

View diagram source

flowchart TB
    Model[QUBO / BQM / constrained model] --> Submit[Submit to solver]
    Submit --> Solver[QPU or hybrid solver]
    Solver --> Samples[Sample set]
    Samples --> Decode[Decode variables]
    Decode --> Validate[Validate constraints]
    Validate --> Score[Score candidates]
    Score --> Report[Decision report]

Decision report sections:

Section	Content
model translation	domain-to-solver mapping
solver configuration	target, time limit, parameters
candidates	best, diverse, and feasible samples
baseline	incumbent classical method
business constraints	hard and soft constraints
sensitivity	response to parameter and penalty changes
recommendation	action, defer, or reject

29.9 Portfolio evaluation

Optimization experiments should be managed as a portfolio. Most will not beat mature classical methods. Some may produce useful candidate diversity, better warm starts, or improved performance in restricted regimes.

Diagram loads as you read

29.9 Portfolio evaluation · Figure 9

View diagram source

quadrantChart
    title Optimization workload portfolio
    x-axis Low strategic value --> High strategic value
    y-axis Low quantum readiness --> High quantum readiness
    quadrant-1 Scale trials
    quadrant-2 Research only
    quadrant-3 Archive
    quadrant-4 Prepare baseline
    Routing: [0.65, 0.42]
    Scheduling: [0.55, 0.50]
    Materials search: [0.80, 0.62]
    Generic portfolio demo: [0.30, 0.35]

Use portfolio reviews to reallocate budget from weak demos to workloads with real decision value.

29.10 Chapter checklist

Require the following before approving an optimization or sampling experiment:

formal problem model,
named classical incumbent,
constraint strategy,
penalty-tuning log,
candidate-set report,
ablation isolating the quantum component,
cost and runtime comparison,
decision threshold,
exit criteria.

Diagram loads as you read

29.10 Chapter checklist · Figure 10

View diagram source

flowchart LR
    Model[Model] --> Review[Optimization review]
    Baseline[Baseline] --> Review
    Constraints[Constraints] --> Review
    Candidates[Candidate report] --> Review
    Ablation[Ablation] --> Review
    Review --> Decision{Fund next trial?}