⬆️ Adopt QDMI 1.4 in MQT Core

🤖 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

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

• #2359: native multi-program adoption, with Client/bundled-device, Qiskit, PennyLane, and provider children. Preserve concurrent single-program fallback, including #2349 and successor fixes.
• QDMI #523: program-capability design, with Core #2365 and provider requirement studies. Keep #2219/#2162 compiler-only work separate.
• #2360: canonical static-license deployment, shared optional injection, docs, provider migration, and optional access/status checks. No legacy provider SPANK implementation remains after migration.
• #2361: availability-based scheduling design. Revisit the previously proposed boolean and reservation policy before implementation; this does not block #2360.
• QDMI #524: public replacement for simulator capability metadata; Core #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.
• #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.

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.