💡 Define compiler and SDK requirements for QDMI program capabilities

[burgholzer]

🤖 AI text below 🤖

Lead: @simon1hofmann. Cross-repository coordination: @burgholzer.

Elevator pitch

Keep compiler target facts and SDK submission guarantees consistent without freezing the QDMI draft or coupling all MLIR work to its release.

Current state

#2219 defines a compiler payload model; #2226 independently adopts QDMI metadata; #2227 connects both on a temporary integration-only base. The separate compiler stack is #2219 → #2162. The compiler-only contract is reviewed for Core 4.0 independently of the QDMI standard proposal. The runtime and adapter proposals remain Core 4.1 work.

Work and decisions

• Separate hardware target facts, serialization/export constraints, classical execution features, and service compilation guarantees.
• Trace producers and consumers in mlir/Compiler, QDMI Client, and both SDK plugins.
• Use Qiskit QuantumCircuit and PennyLane tapes as independent compiler-entry cases. Include an incremental PennyLane path that does not require the full compiler collection.
• Keep ♻️ Define target compilation with payload specifications #2219/✨ Legalize control flow for selected payloads #2162 compiler-only where settled; place QDMI ABI adoption and ✨ Build target environments from QDMI payloads #2227 behind the parent design gate.
• Audit glossary terminology and provide concrete success/failure examples before adding more public types.

Dependencies and release boundary

Parent: 💡 Design program-format and execution-capability contracts. Related existing classical-control tracker: #2131. Release coordination: #2093.

Acceptance and validation

• A requirement/ownership matrix and counterexamples are contributed to the parent decision.
• Unknown target facts fail at inference; no downstream pass invents unrestricted capability.
• The planned bridge has two explicit prerequisites, not an artificial whole-repository PR chain.
• Accepted semantics have focused compiler and SDK test plans. No implementation is presented as agreed merely because it exists in a draft.

Non-goals

Blocking v4.0 on QDMI 1.4; rewriting unrelated MLIR work; making payload capabilities a mandatory Core 4.1 feature.

Compiler and SDK requirements

• Describe capabilities of a selected target/program-format combination, not the whole syntax of the serialization language.
• Use a bounded OpenQASM/QIR-informed vocabulary; keep vendor-specific serializers and lowering outside the generic feature set.
• Demonstrate both Qiskit circuit/primitive and PennyLane tape/measurement workflows. Preserve supported control flow, lower it where feasible, and reject impossible cases.
• Compare client-side compilation with service-side compilation without imposing one universal native/verbatim boundary.
• Review ♻️ Define target compilation with payload specifications #2219 → ✨ Legalize control flow for selected payloads #2162 for Core 4.0 through ✨ Declare target classical-control capabilities and reject unsupported programs #2131. Keep ✨ Adopt exact QDMI 1.4 payload contracts across Core #2226 and ✨ Build target environments from QDMI payloads #2227 on the independent QDMI 1.4/Core 4.1 design path.
• Supply concrete requirements and failures to QDMI #523; the full QDMI capability model remains a release priority, not a blocker.