{"id":"46668780-e9f5-4dbd-b94c-9fc873873d34","arxiv_id":"2506.13436","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A portable Docker-based microservice framework for vendor-independent access to quantum hardware, demonstrated on three hosting environments with a simulator backend.","lead":"Q-AIM is an open-source Docker-based software framework that provides a single access point for managing and interacting with quantum computers. It lets small research groups host and expose their own quantum hardware over local or cloud networks without rebuilding integration software.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The prototype tests only QasmSimulator-backed qasm/pauli endpoints; the claimed pulse-level access and seamless real-hardware integration are not implemented, so the central multi-abstraction claim is unsupported.","rationale":"The reader's identified weakest assumption is that the Qiskit simulator faithfully represents real quantum hardware. That concern is valid and is part of what I see, but the more precise load-bearing gap is internal to the paper: the claimed multi-abstraction capability, especially pulse-level access, is not implemented in the documented prototype. The API exposes only circuit-level qasm and pauli endpoints, and all end-to-end tests use QasmSimulator. Thus the unique contribution relative to prior QCaaS work is not demonstrated, independent of whether the simulator is a faithful stand-in. The portability evaluation itself is reasonable: deploying the same Docker image on a laptop, an on-premise cluster node, and a small cloud instance does support the lightweight and portable claims. The memory footprint figure and the qualitative deployment results are appropriate for a prototype. The missing real-hardware test is acknowledged by the authors and deferred to future work, so this is a limitation rather than a fatal flaw. A conditional acceptance remains the right posture, contingent on release of the code and on a demonstration against a real backend or at least a backend adapter that exercises a non-simulator interface. I therefore recommend no change to the reader's CONDITIONAL verdict, while sharpening the reason: the abstraction-level claim is currently unsupported by the prototype's endpoint surface.","tokens_in":13893,"tokens_out":3582,"duration_ms":37637,"concrete_test":"Deploy the Q-AIM container and enumerate the exposed API routes via /openapi.json; confirm whether any endpoint accepts pulse schedules or backend-level instructions. Then point the existing qasm endpoint at a real Qiskit backend and run the Listing 2 example end-to-end through the same API without modifying endpoint code. If no pulse-level route exists, or if the real-backend run requires new adapter code, new endpoints, or changes to result handling, the multi-abstraction and seamless-integration claims are overstated.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that Q-AIM exposes a quantum resource at multiple abstraction levels with fine-grained access control, and that this integration workflow is portable across hosting paradigms. The load-bearing premise is not merely that a simulator behaves like hardware; it is that the API's backend boundary and abstraction-level endpoints actually match real device interfaces. Section 5.4 lists only four quantum endpoints: /api/qc/qasm/{upload, code} and /api/qc/pauli/{upload, code}, all served by Qiskit's QasmSimulator. Sections 2.3 and 4.4 motivate the work precisely by the need for low-level, pulse-level access, stating that existing QCaaS offerings use higher abstraction and that this work addresses 'the exact opposite... interaction on pulse-level.' Yet no pulse-level or machine-instruction endpoint is implemented or tested, so the stated differentiator from existing quantum-service platforms is absent from the prototype. Portability across three Docker hosts is demonstrated, but the portability of the integration layer to real hardware is not: real backends add authentication, calibration data, job queues, device-specific result types, and hardware-specific IR requirements that the simulator path sidesteps. The conclusion explicitly defers integration of 'the first real quantum computing device' to future work, confirming that the headline integration claim remains untested.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Q-AIM, a Dockerized microservice framework intended to give research groups a portable, open-source way to expose and manage quantum computing hardware. The proposed architecture uses an API gateway, Keycloak-based authentication and role management, a FastAPI backend, an Angular frontend, and containerized services. A prototype implementing OpenQASM and Pauli-representation endpoints on top of Qiskit's QasmSimulator was deployed on a local machine, an on-premise cluster node, and a Google Cloud instance, and the paper reports a memory footprint below 3 GB. Based on these deployments, the authors claim that Q-AIM is lightweight, portable, customizable, and capable of integrating quantum resources at multiple abstraction levels, from algorithmic down to pulse-level access.","tokens_in":14100,"tokens_out":3105,"duration_ms":35961,"significance":"If the central claims were fully supported, Q-AIM would be a useful contribution for small academic groups that want to own and operate small quantum devices: the paper ships a concrete open-source artifact, demonstrates deployment on three distinct hosting paradigms, integrates standard identity management, and provides a reproducible Docker Compose setup. The deployment evidence and the cAdvisor-based resource measurement are genuine strengths. However, the current evaluation is narrowly scoped: all quantum endpoints are backed by a local simulator, no pulse-level or machine-instruction endpoint is implemented, and no performance, concurrency, or scaling measurements are reported. As it stands, the paper is best read as a prototype description with promising architecture, rather than a validated integration workflow for real quantum hardware.","major_comments":[{"comment":"The central differentiator claimed in the introduction and Section 2.3 is low-level, pulse-level access to quantum hardware, described as 'the exact opposite' of higher-abstraction QCaaS offerings. However, the prototype in Section 5.4 exposes only four quantum endpoints, /api/qc/qasm/{upload, code} and /api/qc/pauli/{upload, code}, all served by Qiskit's QasmSimulator. No pulse-level, waveform, or machine-instruction endpoint is implemented or tested. The claim of providing access 'on different levels of abstraction' (abstract, Section 1 contributions) is therefore not supported by the presented prototype. The authors should either implement and test a low-level endpoint or explicitly rescope the claim to circuit/gate-level abstraction and describe pulse-level access as future work.","section":"§5.4 (API), cf. §2.3 and §4.4"},{"comment":"All end-to-end tests are performed against a Qiskit simulator, as stated in Section 5.4: 'Since real quantum hardware is not available for testing, the API utilizes simulators to query as endpoints instead.' Real backends introduce authentication mechanisms, calibration data, job queues, device-specific result formats, and hardware-specific IR constraints that the simulator path sidesteps. The conclusion explicitly defers 'the first real quantum computing device' to future work. Consequently, the headline claim of seamless integration of quantum resources is not yet demonstrated. A concrete improvement would be to validate the same endpoints against a remotely hosted Qiskit backend (e.g., IBM Quantum or a cloud-accessible simulator with device-like constraints) and to report what adaptations were required.","section":"§5.4, §7 (Conclusion)"},{"comment":"The evaluation demonstrates successful deployment on three hosts, but it does not quantify the portability or scalability claims. There are no end-to-end execution benchmarks, no comparison of results across the three environments, no concurrency or throughput measurements, and no stress tests. The statement in Section 6.2 that the setup 'can be scaled to more powerful instances, enabling it to handle more demanding workloads' is asserted rather than measured. The authors should add quantitative evaluation, for example request latency, throughput under concurrent users, and resource utilization across environments, or clearly label these claims as architectural expectations rather than validated results.","section":"§6.1, §6.2 (Evaluation)"},{"comment":"The lightweight claim rests on the observation that the container 'utilized less than 3 GB of memory in our configuration.' This is not sufficiently precise: it is unclear whether this is peak RSS, average memory, host-level memory including cAdvisor and all service containers, or only the Q-AIM application containers, and no time window or measurement method is given. Since memory footprint is a central contribution, the metric should be defined and reported in a reproducible way, ideally with a breakdown per microservice and a comparison against a baseline configuration.","section":"§6.2, Fig. 6"}],"minor_comments":[{"comment":"The terms 'vendor-independent' and 'open-source' are used repeatedly, but the prototype depends on Qiskit for execution and on a specific Pauli-to-OpenQASM parser. Please clarify the intended scope: vendor-neutral API design versus vendor-neutral implementation.","section":"Abstract and Introduction"},{"comment":"The paper alternates between describing 'the Q-AIM Docker image' and the multi-container Docker Compose deployment. Since portability is claimed for the image, please state explicitly which component is the portable unit (the compose project, the API image, or the entire stack) and how users are expected to redistribute it.","section":"§5.1, Listing 1"},{"comment":"The screenshots in Figure 5 are too small to read in the PDF; the endpoint names, code editor contents, and result plots are not legible. Consider enlarging the figure or splitting it into subfigures for the different UI panels.","section":"§5.3, Fig. 5"},{"comment":"The statement that 'the consistent behavior observed across different systems and settings underscores the portability' would be stronger if the paper reported what was actually compared, for example identical result objects or identical execution outputs, rather than only the fact that the stack started successfully.","section":"§6.2"},{"comment":"Reference [41] is an unpublished thesis and is used to introduce the Pauli representation format. Since this format is a user-facing feature, please provide a citable, accessible description or repository link in the reference.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a software-engineering contribution rather than a new physics result, and its main novelty over existing QCaaS gateway work is the focus on low-level, hardware-proximate access. That differentiator is currently unimplemented, and the evaluation is deployment-only. I see no integrity concerns, but the abstract and introduction overstate what the prototype demonstrates; a revision that honestly scopes the claims and adds even one hardware-backed or device-constrained backend test would substantially strengthen the paper. The fit with the journal's scope is reasonable if the work is framed as an infrastructure/prototype paper."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a competent software-engineering paper, not a research breakthrough. The genuinely useful bit is a working microservice stack – Keycloak auth, FastAPI, NGINX, Angular – that exposes a Qiskit simulator as a stand-in for a quantum device, with role-based access. Deploying the same Docker image on a laptop, a cluster node, and a Google Cloud VM is a legitimate, reproducible result. The memory footprint measurement (under 3 GB with caching) is fine for what it is. The paper is honest that real hardware is missing and that device integration is future work.\n\nThe soft spots are real. The intro and Section 4 claim access at multiple abstraction levels, 'from algorithmic to pulse-level.' But the prototype implements exactly two input formats (OpenQASM and a Pauli representation) and every execution goes through Qiskit's QasmSimulator. There is no pulse-level endpoint, no machine-instruction path, no calibration data, no job queue. So the stated differentiator from existing QCaaS/serverless work is a sketch, not a demonstrated feature. The evaluation measures portability of Docker, not portability of the integration layer to real hardware. That distinction matters, because real backends add hardware-specific IR, result types, auth, and queues that the simulator path sidesteps.\n\nThe related-work contrast is slightly oversold. Prior serverless and API-gateway papers already cover dockerized access to quantum resources at a higher level; the novelty here is the low-level orientation and specific combination, which is a plausible niche. The paper should say 'we plan to do pulse-level,' not imply the prototype does it. On citations: the self-citations to their parser library and prior VQE work are used appropriately, no problem.\n\nBottom line: the engineering is solid, the paper is readable, and it is a useful reference for a small group that wants a protected endpoint in front of a quantum device. But the evaluation section does not support the abstraction-level claims in the title and intro. It deserves peer review with major revision: release the code, add a real-device integration or an explicit hardware-interface adapter contract, and trim the claims to match the implementation.","headline":"A competent Dockerized prototype for exposing a Qiskit simulator as a protected quantum resource; portability is shown, but pulse-level and real-hardware integration are deferred, so the headline abstraction-level claim is unsupported.","tokens_in":14612,"tokens_out":2450,"would_cite":false,"duration_ms":22508,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that one containerized microservice stack, Q-AIM, can serve as a portable, vendor-independent gateway to a quantum computer, running on a laptop, an on-premise server, or a cloud instance.","keywords":["quantum computing","quantum hardware integration","containerization","microservices","API gateway","access management","quantum computing as a service","vendor independence"],"falsifier":"Attach a real quantum device (or a hardware emulator that accepts pulse-level commands) to the unmodified Q-AIM container and run the same workflows; if any part of the image, the API, or the authentication flow must be altered to reach the device, the portability and vendor-independence claims fail. A simpler check: attempt to submit a pulse-level program through the gateway today—the claimed abstraction range predicts such an endpoint should exist, and its absence would show the low-level access claim is not yet implemented.","tokens_in":13726,"feed_emoji":"⚛️","tokens_out":8943,"duration_ms":80890,"temperature":0.7,"pith_summary":"The paper proposes Q-AIM, an open-source integration workflow that lets a research group connect its own quantum hardware to users through a single, portable access point. The claim is that one containerized microservice stack can expose a quantum resource at several abstraction levels, with role-based access control, while remaining light and vendor-independent enough to run on a personal computer, an on-premise server, or a small cloud instance. The paper supports this with a prototype deployed on all three hosting paradigms and measured to use under 3 GB of memory in its tested configuration. The motivation is that small academic groups buying quantum devices currently spend their own time building integration software, and a common open-source platform would remove that redundant work. The end-to-end demonstrations run against a circuit simulator rather than physical hardware, so the portability claims are validated for the software layer only.","feed_headline":"One container runs a full quantum access workflow","feed_subtitle":"For groups buying their own quantum hardware, one image replaces the usual in-house integration work.","key_machinery":"The load-bearing mechanism is the encapsulated, containerized microservice architecture centered on an API gateway. The gateway is a superset of a reverse proxy: it assigns ports, forwards requests, and enforces authentication, authorization, and access control before any request reaches a microservice. Behind it sit a database, an identity and access management service, an API application, a web frontend, a reverse proxy, and an optional monitoring service, each an independently replaceable container. The classical quantum-computing workflow is itself treated as a self-contained black-box component inside this stack, so users at different abstraction levels—from high-level circuit code down to hardware-near representations—interact only with the gateway. This structure is what lets the same image run unchanged on different hosting paradigms and lets administrators grant fine-grained access by role and group.","core_discovery":"Q-AIM is a software framework intended to be the missing integration layer for small quantum computers: a single, open-source, containerized microservice stack that wraps the entire classical quantum-computing workflow (circuit definition, transpilation, job submission, result retrieval) as a black box and exposes it through one API gateway. The gateway is the only entry point; it terminates HTTPS, runs authentication and role-based authorization, and forwards requests to internal services that talk to the quantum resource. The paper claims this design is vendor-independent, portable across a personal laptop, an on-premise server, and a cloud instance, and light enough to run in under 3 GB of memory in the tested configuration. Access is granted at different abstraction levels through supported input formats (OpenQASM and a Pauli representation), with internal and external user groups receiving different roles and permissions. Because no real hardware was available, all end-to-end demonstrations run against a circuit simulator that stands in for the quantum endpoint.","pith_inferences":["The clearest next test is to connect the unmodified container to a physical quantum device; if that requires only a backend swap, the vendor-independence claim is confirmed, and if it requires driver-level changes, the claim needs revision. This test is not reported in the paper.","The prototype's supported inputs stop at circuit-level representations (OpenQASM and Pauli), so the advertised pulse-level interaction is presently a design goal rather than a demonstrated capability; building and testing a pulse-level endpoint would be the direct way to close that gap.","The role model of internal and external groups could be extended to federated access across institutions, so multiple universities could share one device using their own identity providers—an application the paper mentions only in passing.","Since the simulator backend hides hardware-specific latencies and failure modes, a realistic hardware test may also reveal that error handling and timeout behavior in the gateway need to be tuned; that is an empirical question the current evaluation cannot answer."],"forward_implications":["A group that deploys the Q-AIM image once can move from a laptop to a server or cloud instance by copying the image, with no per-environment changes.","Administrators can give internal and external users different roles, so a device can be opened to students or collaborators without exposing the supporting infrastructure.","Users can submit jobs as OpenQASM or as a Pauli representation and receive results and metadata through the same web interface, suggesting the abstraction-level promise is exercised at the circuit-representation level.","Because all services ship in one reproducible image, different institutions can share and redeploy the same tailored configuration, lowering the barrier to cross-institution collaboration.","The measured memory footprint below 3 GB indicates the framework itself is not the cost driver on small cloud instances, leaving room for larger simulator workloads."],"supporting_citations":[{"why":"supplies the container platform that underlies the portability and single-command deployment claims.","marker":"[8]"},{"why":"documents the lightweight Linux container technology the microservice architecture is built on.","marker":"[30]"},{"why":"supports the claim that containerized images give reproducible, distributable research environments.","marker":"[32]"},{"why":"provides the identity and access management service used for authentication and role-based authorization.","marker":"[35]"},{"why":"provides the web frontend framework in which the user interface and permission handling are implemented.","marker":"[37]"},{"why":"is the circuit simulator that stands in for quantum hardware in every end-to-end test.","marker":"[46]"},{"why":"defines the OpenQASM input format that the API accepts and processes.","marker":"[16]"},{"why":"is the library that converts Pauli-representation input into OpenQASM and ships with the API image.","marker":"[42]"}],"fun_headline_variants":["One container runs the full quantum access stack","Quantum integration, simplified to a single API","Q-AIM: vendor-neutral quantum middleware in a box","A lightweight, portable layer for quantum hardware","From circuit to result, one unified gateway"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole portability and abstraction-level argument depends on the circuit simulator used for every end-to-end test behaving like a real quantum device in the ways that matter—interface, timing, and control demands—so the same container will work unchanged when physical hardware is attached.","fun_headline_variants_meta":{"raw":{"variants":["One container runs the full quantum access stack","Quantum integration, simplified to a single API","Q-AIM: vendor-neutral quantum middleware in a box","A lightweight, portable layer for quantum hardware","From circuit to result, one unified gateway"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000218,"raw_usage":{"total_tokens":1431,"prompt_tokens":929,"completion_tokens":502,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":545,"completion_tokens_details":{"reasoning_tokens":433}},"tokens_in":545,"tokens_out":502,"duration_ms":5476,"temperature":1.0,"reasoning_tokens":433,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T19:59:59.119134+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Attach a real quantum device (or a hardware emulator that accepts pulse-level commands) to the unmodified Q-AIM container and run the same workflows; if any part of the image, the API, or the authentication flow must be altered to reach the device, the portability and vendor-independence claims fail. A simpler check: attempt to submit a pulse-level program through the gateway today—the claimed abstraction range predicts such an endpoint should exist, and its absence would show the low-level access claim is not yet implemented.","supporting_citations":[{"cited_title":"Docker: Open platform for developing, shipping, and running applications,","cited_arxiv_id":null,"evidence_quote":"supplies the container platform that underlies the portability and single-command deployment claims."},{"cited_title":"Docker: lightweight linux containers for consistent development and deployment,","cited_arxiv_id":null,"evidence_quote":"documents the lightweight Linux container technology the microservice architecture is built on."},{"cited_title":"Containers for computational reproducibility,","cited_arxiv_id":null,"evidence_quote":"supports the claim that containerized images give reproducible, distributable research environments."},{"cited_title":"Keycloak docker image,","cited_arxiv_id":null,"evidence_quote":"provides the identity and access management service used for authentication and role-based authorization."},{"cited_title":"Angular - the modern web framework,","cited_arxiv_id":null,"evidence_quote":"provides the web frontend framework in which the user interface and permission handling are implemented."},{"cited_title":"Qiskit aer QasmSimulator backend,","cited_arxiv_id":null,"evidence_quote":"is the circuit simulator that stands in for quantum hardware in every end-to-end test."},{"cited_title":"Open quantum assembly language,","cited_arxiv_id":null,"evidence_quote":"defines the OpenQASM input format that the API accepts and processes."},{"cited_title":"Qasmparserlibrary,","cited_arxiv_id":null,"evidence_quote":"is the library that converts Pauli-representation input into OpenQASM and ships with the API image."}],"review_version":2}