⬆️ Adopt QDMI 1.4 in MQT Core

[burgholzer]

🤖 AI text below 🤖

Elevator pitch

Adopt released QDMI 1.4 in Core 4.1 through independent, testable workstreams. Stable ABI cleanup, driver replacement, and native batching must not wait for an unsettled program-capability model or scheduler policy.

Release boundaries

• Core v4.0 uses released QDMI 1.3.x. Do not merge QDMI 1.4 ABI changes into that release.
• Core 4.1 release artifacts must use a released QDMI 1.4 tag, not a development or PR commit. Candidate revisions are permitted for development validation only.
• Program capabilities are a priority for QDMI 1.4/Core 4.1, but not a release blocker. Release the settled streams without them if the design is not ready.
• Shared static Slurm deployment and both provider migrations target Core 4.1/MQSF. They remain technically independent of QDMI 1.4. Keep the working Quantum Week setup and limit immediate changes to necessary fixes.
• Availability-based scheduler implementation is unscheduled pending its design. QDMI v2 stack changes are out of scope.

Independent PR workstreams

Topic	QDMI	Core
Metadata cleanup	#512 → #513, rooted on v1.4	#2233 on v4.1, independently of driver replacement
Replaceable drivers	#511 rooted on v1.4	v4.1 → #2229 → #2230 → #2231, without compiler or cleanup ancestry
Multi-program jobs	#509 with the existing program-format enum	#2373 on v4.1 contains the low-level extraction from #2226; SDK consumers follow independently
Program capabilities	#508 behind the design gate	#2226 on v4.1 is independent of #2219; #2227 bridges both
Compiler-only capabilities	No QDMI 1.4 dependency	main → #2219 → #2162 targets Core 4.0 after compiler contract review and validation

QDMI numbers in the table refer to https://github.com/Munich-Quantum-Software-Stack/QDMI. The PRs remain independent. Their root bases use the dedicated development branches; PR head commits and existing validation history are preserved. Retargeting alone is not fresh validation. Individual PRs still require current mergeability, contract review, and CI.

Core #2227 alone uses the temporary integration base codex/qdmi-capability-integration, which combines #2219 and #2226 for testing. It contains neither #2162 nor native batching. Retarget #2227 to v4.1 after both foundations are available there. This integration base is not a prerequisite for either foundation.

Keep mechanical consumer adaptations with the API change that requires them. A file living under MLIR does not make a mechanical runtime adaptation an independent compiler feature. Use temporary integration branches only to test two unmerged prerequisites, not to impose a serial merge order on independent foundations.

Tracking and handoffs

• ✨ Adopt native multi-program QDMI jobs across Core and SDK plugins #2359: native multi-program adoption, with Client/bundled-device, Qiskit, PennyLane, and provider children. Preserve concurrent single-program fallback, including ⚡ Submit PennyLane QDMI jobs concurrently #2349 and successor fixes.
• QDMI #523: program-capability design, with Core 💡 Define compiler and SDK requirements for QDMI program capabilities #2365 and provider requirement studies. Keep ♻️ Define target compilation with payload specifications #2219/✨ Legalize control flow for selected payloads #2162 compiler-only work separate.
• ✨ Centralize static-license QDMI deployment and optional SPANK injection #2360: canonical static-license deployment, shared optional injection, docs, provider migration, and optional access/status checks. No legacy provider SPANK implementation remains after migration.
• 💡 Design QDMI availability-based Slurm scheduling #2361: availability-based scheduling design. Revisit the previously proposed boolean and reservation policy before implementation; this does not block ✨ Centralize static-license QDMI deployment and optional SPANK injection #2360.
• QDMI #524: public replacement for simulator capability metadata; Core ⬆️ Replace private DDSIM capability metadata after QDMI standardization #2367 adopts it after agreement.

Existing PRs already track the stable metadata/driver changes. Do not add redundant wrapper issues for each PR.

Settled decisions

• Native batching initially uses the existing format enum, independently of descriptor/capability design.
• ✨ Add an optional packaged QDMI Driver extension #2230 remains a private MQT default-driver discovery/configuration extension. Standard Client discovery/configuration belongs to QDMI v2, not this migration.
• Unknown topology or gate-set facts fail during target inference. Do not infer all-to-all connectivity or unrestricted operations from missing data.
• DDSIM's private all-to-all/controlled-family workarounds remain until an agreed public replacement exists. gphase is zero-arity; controlled support is not limited to mcx/mcp.
• Optional launch validation reuses today's Core open and IDLE/BUSY check with released QDMI 1.3.x. It is not an acceptance/readiness guarantee. If safety tests are not ready, static migration ships without it, not with a legacy plugin.
• Follow current AGENTS.md, MLIR guidance, and the glossary for terminology.

History and publication

Preserve PR identities, useful commits, legitimate human attribution, and review discussions. Rescope in place where practical. Do not create archive branches. Before an authorized rewrite, refresh the remote head and use an exact force-with-lease; do not overwrite concurrent work. Sign and verify commits. Do not request reviews automatically.

Acceptance

• Each active PR has one coherent responsibility and an accurate base/dependency description.
• Every stack builds and passes its relevant tests independently against its target branch; old-head validation is not counted for new heads.
• Verify parameterized Client tests are present after a clean build. First-build GoogleTest discovery can run before bundled catalogues are staged: compare mqt-core-qdmi-test --gtest_list_tests with ctest --show-only. Discovery ordering must be fixed before relying on that first-build CI count; local validation in this restructuring refreshed discovery after staging.
• Native batching preserves optional shots, byte-exact programs, indexed results, lifecycle, cancellation, retrieval, and concurrent single-program fallback.
• Installed runtime, CMake consumers, wheels, and sdists have a complete, correctly licensed dependency closure.
• Canonical docs describe tested behavior and released dependency combinations.
• Optional unsettled features do not block the released QDMI 1.4/Core 4.1 combination.

Development branches and ownership

Core main remains the Core 4.0 development line; v4.1 holds later integration. QDMI v1.4 isolates the next minor release from develop.

Workstream	Lead
Release branches; metadata, driver and batching foundations	@burgholzer
Compiler capabilities and Core/QDMI capability integration	@simon1hofmann
Shared static Slurm deployment	@flowerthrower
Braket adoption and provider requirements	@flowerthrower
IQM adoption and provider requirements	@marcelwa

Core #2131 and #2219 → #2162 target 4.0 without QDMI 1.4. QDMI #523 remains a separate standard-design gate, not a prerequisite for merging the independently reviewed compiler model. General QDMI architecture/onboarding documentation is tracked in QDMI #527. SC26 remains the next planning horizon; no additional implementation scope is implied.

End-to-end interface validation

Before the interface change merges, link a working Core consumer and a demonstration with at least one existing provider, preferably both where applicable. Compatibility evidence suffices when a provider needs no changes. Development revisions may support these tests; published artifacts must use released dependencies.