Not every useful quantum workflow is a universal gate-model circuit. Neutral-atom analog Hamiltonian simulation, quantum annealing, and specialized quantum-classical hybrid solvers expose different programming contracts and different operating risks.
Amazon Braket documents Analog Hamiltonian Simulation as a paradigm where a program is defined by time-dependent and space-dependent Hamiltonian parameters rather than a sequence of gates [R115]. D-Wave's Ocean tools and Leap hybrid solvers expose optimization workflows based on quadratic and nonlinear models rather than gate circuits [R116]. These systems need the same operational seriousness as gate-model QPUs, but the artifacts and validation methods differ.
64.1 Workflow taxonomy
View diagram source
flowchart TB
QuantumWorkflow[Quantum workflow] --> Gate[Gate model]
QuantumWorkflow --> Analog[Analog Hamiltonian simulation]
QuantumWorkflow --> Annealing[Annealing / quadratic models]
QuantumWorkflow --> HybridSolver[Managed hybrid solver]
QuantumWorkflow --> FTEstimate[Fault-tolerant estimate]A platform should not force all quantum work into a circuit-shaped abstraction. It should expose workload-specific contracts.
64.2 Analog Hamiltonian contract
View diagram source
flowchart LR
Problem[Physical / graph problem] --> Geometry[Atom geometry]
Geometry --> Hamiltonian[Hamiltonian schedule]
Hamiltonian --> Discretize[Device discretization]
Discretize --> Run[AHS run]
Run --> Measurements[Measurements]
Measurements --> Interpret[Domain interpretation]The artifact is not a gate list. It is a physical program: geometry, drive fields, detuning schedules, interaction assumptions, and device discretization.
64.3 Annealing and hybrid optimization contract
View diagram source
flowchart LR
BusinessProblem[Business problem] --> Model[Quadratic / nonlinear model]
Model --> Constraints[Constraints and penalties]
Constraints --> Solver[Quantum-classical solver]
Solver --> Samples[Samples / candidates]
Samples --> Feasibility[Feasibility check]
Feasibility --> Decision[Decision support]The core risk is not circuit depth. It is formulation quality: variables, constraints, penalty weights, scaling, and interpretation.
64.4 Validation by contract type
View diagram source
flowchart TB
Validation[Validation] --> GateVal[Gate model validation]
Validation --> AnalogVal[Analog validation]
Validation --> AnnealVal[Annealing validation]
GateVal --> CircuitMetrics[Depth, fidelity, counts]
AnalogVal --> PhysicalMetrics[geometry, schedule, observable]
AnnealVal --> OptMetrics[feasibility, objective, gap]Do not reuse the wrong metrics. AHS validation should emphasize physical-program consistency and observable interpretation. Annealing validation should emphasize model formulation, feasibility, and baseline comparison.
64.5 Evidence package variants
View diagram source
erDiagram
EVIDENCE_PACKAGE ||--|| WORKLOAD_CONTRACT : includes
WORKLOAD_CONTRACT ||--o{ ARTIFACT : defines
WORKLOAD_CONTRACT ||--o{ VALIDATION : requires
WORKLOAD_CONTRACT {
string workload_type
string schema_version
string target_profile
string budget_policy
}
ARTIFACT {
string artifact_type
string hash
string uri
}Artifact examples:
| Workload | Required artifacts |
|---|---|
| Gate model | source, circuit, transpiled circuit, target snapshot, shot results |
| AHS | geometry, Hamiltonian schedule, discretized program, device properties, measurement results |
| Annealing | model, constraints, penalty policy, solver parameters, samples, feasibility report |
| Hybrid solver | problem model, solver version, run parameters, candidates, classical baseline |
64.6 Cost and capacity risks
View diagram source
flowchart LR
Workload[Non-gate workload] --> Hidden[Hidden expansion]
Hidden --> Capacity[Capacity usage]
Hidden --> Cost[Cost]
Hidden --> Interpretability[Interpretability risk]Managed hybrid solvers can obscure how much work occurs under the hood. This is useful for productivity and risky for governance. Require cost and solver-parameter reporting.
64.7 Baseline selection
View diagram source
flowchart TB
Result[Quantum result] --> Baselines{Baselines}
Baselines --> Exact[Exact small instance]
Baselines --> Heuristic[Classical heuristic]
Baselines --> Relaxation[Relaxation / bound]
Baselines --> Prior[Prior production method]For optimization, a result is only meaningful relative to a baseline and a constraint-feasibility check. For analog simulation, compare to tractable small systems, known limits, or experimentally validated observables.
64.8 Routing across workload families
View diagram source
flowchart LR
Request[Problem request] --> Classifier{Problem structure}
Classifier --> Circuit[Gate-model path]
Classifier --> AHS[AHS path]
Classifier --> Anneal[Annealing path]
Classifier --> Classical[Classical path]
Circuit --> Evidence[Evidence]
AHS --> Evidence
Anneal --> Evidence
Classical --> EvidenceThe platform should sometimes say: this is not a quantum workload. That is a feature, not a failure.
64.9 Governance differences
View diagram source
flowchart TB
Governance[Governance] --> Common[Common controls]
Governance --> Specific[Workload-specific controls]
Common --> Owner[Owner]
Common --> Budget[Budget]
Common --> Evidence[Evidence]
Specific --> Physics[Physical parameters]
Specific --> Formulation[Optimization formulation]
Specific --> Solver[Solver version]Common controls cover ownership, budget, access, evidence, and review. Specific controls cover the scientific or mathematical structure of the workload.
64.10 Operating rule
Abstraction should follow physics and problem structure.
View diagram source
flowchart LR
Problem[Problem] --> Contract[Native contract]
Contract --> Target[Appropriate target]
Target --> Evidence[Appropriate evidence]A good platform supports gate, analog, annealing, and hybrid workloads without pretending they are the same thing.