{"id":"d67122c6-51c9-4dfb-a1d9-221254235a69","arxiv_id":"2608.05646","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"A per-instance selector for exact QAOA simulation filters compatible simulator configurations and ranks them with features or analytical work estimates, covering all 31 oracle-solvable test requests with 27/31 near-optimal picks.","lead":"RASP-QAOA chooses which of ten exact QAOA simulator configurations to run for each new problem instance, after first checking which configurations are compatible with the request. On a fresh 60-request test on H200 GPUs it completed all 31 requests that any configuration could complete, selecting a near-fastest option in 27 of 31 cases.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The §4.1 memory-compatibility model is load-bearing: because oracle-solvable uses the same A_a predicate, a false-negative exclusion would remove a request from the denominator; the paper never audits the false-negative side of the calibrated 768 MiB/per-amplitude estimates.","rationale":"The reader's weakest assumption and my analysis converge on Section 4.1. I do not see a reason to escalate beyond CONDITIONAL: the fresh set is content-disjoint, the timeout-resampling and validation checks are reported, and the paper explicitly separates learned and analytical paths. But the false-negative audit is necessary because otherwise the headline coverage count is defined relative to the policy's own compatibility predicate. If the audit is added and passes, the condition is satisfied. If it fails, the verdict should move to REJECT for the current claim; my recommendation of UNCHANGED reflects the reader's existing CONDITIONAL rather than a stronger objection. I also flag the supplement dependency: exact coefficients are not in the manuscript, so the audit cannot be reproduced from the text alone.","tokens_in":11174,"tokens_out":8532,"duration_ms":91494,"concrete_test":"False-negative audit for §4.1: for every fresh request in the 19 no-compatible-action group and every action–request pair in the 10 no-completion group, relax the memory condition alone and execute the otherwise admissible action under the same 300 s cap on the H200, using a measured peak-memory oracle (e.g., maximum RSS / HBM utilization per process) instead of the calibrated estimate; record R_a and V_a. Then rebuild C(x) from the measured-compatible set and recompute coverage, top-1, top-2, geometric-mean regret, and normalized PAR10. If any previously excluded action yields Y=1 and changes any headline count, the calibrated model has a clinically relevant false-negative rate and the 31/31 statement must be reconditioned; if the audit is all-negative and counts are unchanged, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"RASP-QAOA's decision and its evaluation both start from the pre-execution compatibility predicate A_a(x). Section 3.1 defines C(x) = {a : A_a(x)=1}, the policy selects only from C(x), and the 60-request evaluation labels a request oracle-solvable only if at least one action satisfies those same request conditions and completes/validates. Section 4.1 implements the memory component of A_a with calibrated estimates (768 MiB process base plus per-amplitude bytes; QTensor contraction boundary), with exact coefficients delegated to the supplement. The evaluation probes the false-positive direction (10 requests with candidates but no strict completion; removing resource conditions loses 2 coverage cases) but never probes false negatives. If the calibrated bytes-per-amplitude or contraction boundary overestimates peak memory, an action that would actually complete within the cap is excluded from C(x); the request then falls into the 19 no-candidate or 10 no-completion group rather than the 31-request denominator, and the '31/31 coverage, 27/31 top-1, 1.051 regret' counts are unchanged by construction. The central empirical claim is therefore exactly as strong as the estimator's absence of false negatives, a condition the manuscript does not test. This is not a claim of any intentional overreach; it is a missing validation step on the most load-bearing component.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper formulates exact QAOA simulation selection as choosing among ten complete executable actions, each specified by a representation, adapter, precision mode, and memory policy. RASP-QAOA first filters actions using semantic, precision, deployment, and memory compatibility, then orders the surviving actions by learned scores when they are in a fixed development support, or by analytical work estimates otherwise. On a fresh 60-request H200 test it reports 31/31 coverage of the oracle-solvable requests, 27/31 top-1, 31/31 top-2, geometric-mean regret 1.051, and a failure-penalized PAR10 score 0.0396 times that of development-selected CUAOA. A separate 30-request crossover with overlapping actions tests whether structural features improve ordering. The paper concludes that resource-aware representation selection is valuable for exact QAOA simulation at n <= 35, p <= 5.","tokens_in":11444,"tokens_out":8487,"duration_ms":93257,"significance":"If the headline results hold, the paper makes a useful empirical contribution: it demonstrates a clean decomposition of simulator selection into compatibility filtering, learned ordering, analytical fallback, and separate validation, and it evaluates this decomposition on a content-disjoint fresh test. The strengths are the explicit action-key formulation, the repeated timeout checks, bootstrap intervals with the request as the independent unit, the deployment-horizon sensitivity analysis, and the authors' transparency about the single-action learned support and the secondary status of the earlier benchmark. The main limitation is that the central evaluation conditions on the same compatibility predicate used by the selector, so the headline coverage and ranking counts are exactly as strong as the calibrated memory model's false-negative behavior, which is not audited.","major_comments":[{"comment":"Because all 40 development labels are CUAOA, A_phi is the singleton {cuaoa_gpu}, so on the 60-request fresh test the learned branch D(x)=C(x)∩A_phi contains at most one action. The 19 learned-path successes are therefore compatibility-driven CUAOA selection, not evidence of learned ranking among competing actions. All direct evidence for feature-based per-instance ordering comes from the 30-request crossover with n=20, p=2 and three overlapping actions. This is a real scope limitation on the central 'per-instance selection' claim: the broad test validates portfolio construction and analytical fallback, while the ordering claim rests on a single fixed-(n,p) crossover. The authors are transparent about this, but the abstract and introduction could mislead; I recommend either adding multi-action regions to the fresh test or explicitly stating in the abstract that feature-based ordering is validated only in the controlled crossover region.","section":"§4.2, §6.1, §6.3"}],"minor_comments":[{"comment":"Please specify explicitly whether the normalized per-request PAR10 ratios are computed over all 60 requests or only over the 31 oracle-solvable requests; the current text can be read either way, and the interpretation of the 0.0396 figure depends on it.","section":"§5, Table 2"},{"comment":"Clarify how the nine independent exact checks map onto the 31 oracle-solvable requests; if they cover only a subset, state which validation criterion is used for the remaining requests and whether cross-action agreement alone is considered sufficient.","section":"§5"},{"comment":"The exact coefficients of the memory-compatibility model appear only in the supplement; since C(x) is the central predicate, please include them in the main text or in a versioned code artifact so that the false-negative audit can be reproduced independently.","section":"§4.1"},{"comment":"The claim that a depth-1 structural stump exactly matches gradient boosting is reported without a confidence interval or resampling summary; on a 30-request sample, please report the stability of this exact match, for example by bootstrapping the decision agreement.","section":"§6.3"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is honest and methodical, and the central gap is testable rather than fatal. The false-negative audit of the memory-compatibility model is the key requirement; the narrowness of the learned-ordering evidence is a second important limitation that can be addressed by qualification or by adding multi-action regions."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is a careful, honest paper on per-instance action selection for exact QAOA simulation. The genuinely new part is the action-level framing: choices fix representation, adapter, precision, and memory policy, and compatibility is determined before any ranking. The analytical work estimates for out-of-support actions are a sensible fallback, and the component-resolved evaluation on a fresh 60-request H200 test is well executed. Request content is disjoint from development, timeout-heavy rows are rechecked with independent processes, within-action resampling stabilizes the top-k counts, and a separate crossover isolates the contribution of structural features. The paper is also unusually transparent about its limits, including the fact that the learned support in the primary test is a single action.\n\nThe headline empirical claim—31/31 coverage, 27/31 top-1, 1.051 geometric-mean regret on the 31 oracle-solvable requests—is convincing as reported. The paper correctly separates portfolio coverage from ranking quality and reports successful-selection regret and failure-penalized PAR10 without conflating them.\n\nThe main soft spot is the §4.1 memory-compatibility model. Both the policy and the evaluation denominator use the same A_a(x) predicate: a request is oracle-solvable only if at least one action passes the calibrated memory check and then completes. If the 768 MiB process base, per-amplitude bytes, or QTensor contraction boundary overestimates true peak memory, an action that would actually fit is excluded from C(x), and the request drops into the no-candidate group. The coverage counts are unchanged by construction. The paper probes the false-positive direction (compatible actions that fail to complete) but never audits false negatives. That is a missing validation step on the most load-bearing component, not evidence of overreach. The exact coefficients are deferred to a supplement I have not seen; they should be public for reproduction.\n\nA secondary limitation: the feature-ranking evidence outside the crossover is thin, since the primary test's learned support is just cuaoa_gpu. The 30-request crossover at fixed n=20, p=2 helps, but it is a narrow region. The calibration and validation checks living in the supplement is acceptable, but they need to be present for the paper to be fully assessable.\n\nThis paper is for people building QAOA simulation tooling and for algorithm-selection researchers who care about domain-specific compatibility constraints. It deserves a serious referee. I would accept it with a request that the supplement be included and the memory model's false-negative behavior be checked or at least explicitly discussed as a threat to the coverage interpretation.","headline":"Solid, honest empirical study of per-instance action selection for exact QAOA simulation; the load-bearing memory-compatibility model needs a false-negative audit before the coverage numbers are taken at face value.","tokens_in":11973,"tokens_out":3228,"would_cite":true,"duration_ms":31275,"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 exact QAOA simulation should be chosen as a complete executable action, and that a compatibility-first selector covers all 31 solvable fresh-test requests and ranks first or second in all 31.","keywords":["QAOA simulation","per-instance algorithm selection","resource-aware selection","exact simulation","representation selection","memory compatibility","learned portfolio","analytical work estimates"],"falsifier":"Take the 60 fresh requests and re-run the selector while perturbing the calibrated memory coefficients within their calibration uncertainty (for example, varying the fixed process base around 768 MiB and the per-amplitude byte counts by ±10%), and check whether the 31-request oracle set and the 31/31 coverage partition remain unchanged. Separately, on the ten requests with compatible candidates but no strict completion, raise the execution cap and memory budget for those candidate actions; if any then completes and validates, the original compatibility model would have misclassified a feasible action as infeasible under the stated budget.","tokens_in":10942,"feed_emoji":"⚛️","tokens_out":13821,"duration_ms":117584,"temperature":0.7,"pith_summary":"Exact simulation of the quantum approximate optimization algorithm (QAOA) can run on very different computational representations—full state vectors, tensor contraction, causal-neighborhood evaluators, fixed-weight subspaces—whose feasible regions depend on graph structure, depth, precision, and memory. This paper argues that choosing a \"backend name\" is too coarse to make that decision, because the executable choice also fixes the representation, adapter, precision mode, and memory policy. It introduces RASP-QAOA, a two-stage selector that first prunes the candidate set by semantic, precision, deployment, and memory compatibility, then ranks the survivors with instance features when available and analytical work estimates otherwise. On a content-disjoint 60-request H200 test at $n\\leq 35$, $p\\leq 5$, it covers all 31 requests for which at least one admissible action completes and validates, ranks first or second in all 31, and obtains a failure-penalized score 0.0396 times that of the development-selected full-state baseline. A structural crossover shows the ordering gains come from graph-structure features, not from classifier complexity.","feed_headline":"Per-request simulator choice covers all 31 solvable QAOA runs","feed_subtitle":"For quantum approximate optimization (QAOA) simulation, per-request pruning and ranking covers all 31 solvable runs.","key_machinery":"The central object is the complete executable action key $a=(i,\\kappa)$: a representation–adapter identity paired with a configuration that fixes precision, memory policy, and execution flags. It carries the argument because compatibility is decided at this key level—two full-state actions with different precision modes have different memory envelopes and numerical guarantees, and a fixed-weight implementation exists only when the mixer preserves the relevant subspace. The mechanism is the two-stage decomposition: the compatibility predicate $A_a(x)=S\\wedge P\\wedge D\\wedge M$ defines the candidate set $C(x)$ using only pre-execution information (circuit checks, precision checks, deployment checks, and calibrated peak-memory estimates such as a calibrated process base plus per-amplitude bytes for full-state actions and a contraction boundary for tensor contraction), and the ordering stage applies the priority rule that feature-ranked actions from the learned support $D(x)=C(x)\\cap \\mathcal{A}_\\phi$ are chosen when available, with analytical work proxies ordering compatible actions outside that support. This decomposition separates the question of which representations may compete from the question of which should be tried first.","core_discovery":"The paper's central claim is that per-instance selection over complete executable action keys—not backend names—is the right formulation for exact QAOA simulation in the $n\\leq 35$, $p\\leq 5$ regime it tests. An action key $a=(i,\\kappa)$ pairs a representation–adapter identity with a configuration fixing precision, memory policy, and execution flags; the compatibility predicate $A_a(x)=S\\wedge P\\wedge D\\wedge M$ blocks actions that cannot implement the requested semantics, precision, deployment, or memory budget. The selector's rule prioritizes the intersection of the compatible set with the learned-support set $D(x)=C(x)\\cap \\mathcal{A}_\\phi$, using a 30-dimensional request descriptor, and falls back to representation work proxies ($p\\binom{n}{k}$ for fixed-weight simulation, $m^{O(dp)}$ for local evaluation, contraction-width terms for tensor methods, and $2^n$-scaling terms for full state) when no learned-supported action survives. On the fresh test the policy completes every one of the 31 oracle-solvable requests, reaches top-1 on 27 and top-2 on all 31, with 1.051 geometric-mean regret; the four top-1 misses are successful selections in the second 5% timing-equivalent group. The crossover result—structural features change 16 of 30 decisions and a depth-1 stump matches gradient boosting—supports the conclusion that the gains belong to representation-aware compatibility and instance features rather than to classifier sophistication.","pith_inferences":["The compatibility-first action-key recipe is a general pattern for numerical toolchains: prune by exact semantic and resource constraints before any learned ranking, and keep an analytical fallback for out-of-support candidates; it should transfer beyond QAOA to any simulator ecosystem with multiple precision and memory modes.","The stability of the candidate set under repeated timeouts suggests the ten candidate-without-completion requests are genuine resource or implementation limits, so the next practical gain will come from adding a new representation for sparse/dense or fixed-cardinality regimes rather than from a better ranker.","Because a depth-1 structural stump reproduces the gradient-boosting decisions on the crossover, the ordering signal is probably captured by a few thresholds on graph-structural features; an interpretable rule could be extracted and tested on broader instance families.","The paper's explicit scope boundary invites a natural test: run the same action-key selection at $n=36$–$40$ on the same GPU stack to see whether the calibrated memory coefficients still predict the candidate set, or whether the per-amplitude memory base changes with problem size."],"forward_implications":["QAOA tooling should expose action keys—representation, adapter, precision, memory policy—rather than backend names, since compatibility and cost can change while the backend name stays fixed.","A new simulator representation can enter the portfolio before any timing data is collected: compatibility checks plus a representation work proxy give it an analytical ordering, and it moves into learned support only after development observations.","Coverage and ranking are separate metrics: a selector can cover every solvable request while still sitting in the second timing group on 4 of 31 requests, so evaluation should report both.","Reported rankings are tied to a deployment horizon; cold start, eight-use amortization, and steady state can change which action is fastest, so fair comparison must state the reuse assumption.","The demonstrated regime is exact expectation-value simulation at $n\\leq 35$, $p\\leq 5$ on the tested GPU stack; other objectives, mixers, approximate methods, or hardware require their own action definitions, validation conditions, and timing calibration."],"supporting_citations":[{"why":"Defines the QAOA circuit whose exact simulation is the paper's target problem.","marker":"Farhi, Goldstone, and Gutmann 2014"},{"why":"Introduces constraint-preserving mixers and the reduced fixed-weight basis used by two portfolio actions.","marker":"Hadfield et al. 2019"},{"why":"Supplies the tensor-contraction simulator whose contraction boundary is used in the analytical work estimate.","marker":"Lykov et al. 2021"},{"why":"Documents high-depth full-state speedups that motivate the internal full-state actions' cost model.","marker":"Lykov et al. 2023"},{"why":"Supplies the full-state GPU simulator used as the development-selected baseline for coverage and PAR10 comparisons.","marker":"Stein et al. 2024"},{"why":"Frames algorithm selection as mapping instance information to a procedure, the basis for the per-instance formulation.","marker":"Rice 1976"},{"why":"Provides the learned portfolio selection precedent that motivates feature-based ordering over a support set.","marker":"Xu et al. 2008"},{"why":"Surveys algorithm selection methods and defines the expected-performance framework the paper instantiates.","marker":"Kotthoff 2014"},{"why":"Documents the deployed full-state adapter's precision and memory behavior for one action definition.","marker":"NVIDIA 2026"},{"why":"Documents another full-state backend action and its GPU execution path.","marker":"Qiskit Aer Contributors 2026"}],"fun_headline_variants":["Per-request QAOA pick: all 31 solvable runs","Per-request QAOA pick: 31/31 solvable, 27 top-1","Resource-aware QAOA selector covers all 31 solvable","No one-size QAOA: per-instance choices cover all solvable"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the calibrated pre-execution memory model—a fixed process base plus a per-amplitude byte count for full-state actions and a contraction boundary for tensor contraction—predicts which actions can actually complete; errors in those coefficients would change the candidate set, and the ten requests with candidates but no completion show the prediction is not already exact.","fun_headline_variants_meta":{"raw":{"variants":["Per-request QAOA pick: all 31 solvable runs","Per-request QAOA pick: 31/31 solvable, 27 top-1","Resource-aware QAOA selector covers all 31 solvable","No one-size QAOA: per-instance choices cover all solvable"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001095,"raw_usage":{"total_tokens":4655,"prompt_tokens":1115,"completion_tokens":3540,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":731,"completion_tokens_details":{"reasoning_tokens":3460}},"tokens_in":731,"tokens_out":3540,"duration_ms":25407,"temperature":1.0,"reasoning_tokens":3460,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-08T04:55:20.482400+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take the 60 fresh requests and re-run the selector while perturbing the calibrated memory coefficients within their calibration uncertainty (for example, varying the fixed process base around 768 MiB and the per-amplitude byte counts by ±10%), and check whether the 31-request oracle set and the 31/31 coverage partition remain unchanged. Separately, on the ten requests with compatible candidates but no strict completion, raise the execution cap and memory budget for those candidate actions; if any then completes and validates, the original compatibility model would have misclassified a feasible action as infeasible under the stated budget.","supporting_citations":[{"cited_title":"Performance Evaluation and Acceleration of the","cited_arxiv_id":null,"evidence_quote":"Supplies the tensor-contraction simulator whose contraction boundary is used in the analytical work estimate."},{"cited_title":"Fast Simulation of High-Depth","cited_arxiv_id":null,"evidence_quote":"Documents high-depth full-state speedups that motivate the internal full-state actions' cost model."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the full-state GPU simulator used as the development-selected baseline for coverage and PAR10 comparisons."}],"review_version":1}