{"id":"318f10a7-11de-42f8-a5ea-31c68698ce10","arxiv_id":"2608.09492","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":5,"one_line_summary":"TempoWAM adapts the replanning frequency of world action models based on an online estimate of task progress, reducing inference calls on easy tasks and improving success on hard tasks.","lead":"This paper proposes TempoWAM, a system that lets robot action models decide on their own when to stop and replan, instead of always executing a fixed number of steps. It estimates how far along a task the robot is and uses that estimate to save computation on easy stages and replan more often on hard ones.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The experiments never isolate the progress signal: when the monitor is accurate, Eq. 6 gives r̃_t ≈ 1 by construction, so all adaptive behavior is produced by calibration, and the only component informed by success is the cross-episode δ′ update, which Table 7 shows tracks success gaps.","rationale":"The reader's verdict identifies a related circularity but centers on the validity of time-based progress labels. My concern is more specific and more load-bearing: even if the monitor is a perfect estimator of normalized time, the decision rule of Eq. 6-7 collapses to a constant ratio, so the entire adaptive behavior must come from the calibration factors. The cross-episode δ′ update is the only component that receives success feedback, and Table 7 shows it moves to match each task's gap from the target success rate. This makes the hard-task improvements (open_microwave, pack hand cream) confounded with a simple success-gated controller that replans more after failures. The proposed ablation directly settles whether the RPM's progress estimate contributes anything beyond that feedback. The mirrored-sequence experiment is not a substitute: it shows only that a deliberately contradictory sequence prevents time-label fitting, not that normal-task predictions reflect genuine semantic progress rather than a visual time proxy. Because the paper's headline claim is causal ('progress drives the improved trade-off'), and no experiment isolates that cause, the rejection is warranted; adding the δ′-ablation plus a label-validity check could make the claim testable in a revision.","tokens_in":11479,"tokens_out":4309,"duration_ms":48476,"concrete_test":"Run the full TempoWAM on RoboTwin open_microwave, turn_switch, and the real-robot pack hand cream task with the cross-episode success-gated update disabled (η = 0, δ′ = 1.0) while keeping the offline κ_task and intra-episode EMA. If the success gains vs. Baseline-24 (e.g., +30 points on open_microwave, +13.3 on pack hand cream) disappear or shrink sharply, the gains are caused by the success-feedback calibration, not by the RPM progress estimate, and the paper's central claim fails. If the gains persist, the concern is resolved.","verdict_should_be":"REJECT","load_bearing_attack":"The central claim is that estimated task progress, not fixed step counts or success feedback, drives the improved trade-off. That claim is not supported because the decision rule is degenerate for an accurate monitor. Under labels y_u = u/T_ep, a well-trained monitor has v_t ≈ u_t/T_ep, so ρ_cur = (v_t − v_{t−1})/n_t ≈ 1/T_ep and ρ_need = max((1 − v_{t−1})/(T_ep − u_t), 0.2/T_ep) ≈ 1/T_ep; hence the raw ratio r̃_t in Eq. 7 is ≈ 1 at every decision step. Therefore the 'continue if r_t ≥ 1' rule cannot produce any adaptive replanning except through κ_final = κ·δ′. The offline κ_task rescales the monitor to time labels, and the online EMA absorbs per-step noise, but the only term that can shift hard-task behavior is the cross-episode success-gated update (Eq. 10), which is explicitly adjusted toward a target success rate s*. Table 7 confirms that δ′ relaxes on tasks already solved (click_bell, click_alarmclock: δ′ = 0.68) and tightens on below-target tasks (turn_switch 0.98, open_microwave 0.94), recovering 7 and 30 points. Thus the reported successes on hard tasks—open_microwave 53→83, pack hand cream 50→63.3—are plausibly produced by a success-feedback controller, not by a progress signal. The mirrored-sequence diagnostic only shows that an adversarial aliased sequence prevents time-label fitting; it does not establish that, on the actual tasks, the monitor estimates genuine task advancement rather than a visual proxy of elapsed time. Since all labels are u/T_ep, no experimental result distinguishes progress-driven replanning from time-driven replanning plus success-gated calibration.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes TempoWAM, an execution-layer module for World Action Models that replaces a fixed execution horizon with an adaptive one. A Recurrent Progress Monitor (RPM) is trained to predict normalized time progress u/T_ep, and an Adaptive Execution Protocol (AEP) compares the monitor's progress rate with a required rate, using per-task and cross-episode calibration factors. The paper reports experiments on RoboTwin, LIBERO, and a real robot, claiming consistent improvement of the efficiency-success trade-off and plug-and-play transfer across WAM backbones.","tokens_in":11811,"tokens_out":9434,"duration_ms":105908,"significance":"If the progress-based mechanism worked as described, TempoWAM would be an attractive lightweight contribution: it requires no backbone modification, adds only a few percent overhead per decision, and the paper includes a broad multi-benchmark evaluation, cost measurements, and a diagnostic of time-based labels. However, the central claim is not supported: the decision rule is degenerate under the chosen training labels, and the results that remain are driven by calibration factors rather than by an independent progress signal. The paper's value as a progress-aware execution scheme is therefore not established, though the calibrated success-feedback controller may still be a useful heuristic.","major_comments":[{"comment":"For a monitor that reproduces its training labels (Eq. 12), v_{t-1} ≈ u_t/T_ep and v_t ≈ (u_t+n_t)/T_ep at every decision step after the first, so ρ_cur ≈ 1/T_ep and ρ_need ≈ 1/T_ep; the raw ratio r̃_t in Eq. (7) is therefore ≈ 1 by construction until the floor term at the very end of the episode. The 'continue if r_t ≥ 1' rule in Eq. (11) then cannot produce any adaptive replanning except through κ_final. Because κ is an EMA of r̃_t (Eq. 9) and δ′ is a success-gated update (Eq. 10), the replanning behavior is controlled by calibration, not by a comparison of two independent progress rates. This undermines the central claim that execution decisions are driven by task progress.","section":"§3.4, Eqs. (6)–(7) and (11)"},{"comment":"The evidence attributes the gains to the success-feedback loop. Final δ′ is 0.68 on tasks already at 100% success and 0.94–0.98 on tasks below target, so the cross-episode update (Eq. 10) is doing the work of trading off efficiency vs success. No experiment isolates the progress signal: Table 8 ablates training losses, not the decision rule, and Fig. 5, which disables δ′, reports no success rate or call counts. The rising κ in Fig. 5 is an EMA of the monitor's own raw ratios, so it shows only that a filtered version of a biased monitor output changes, not that task advancement is being measured.","section":"§4.4, Table 7 and Fig. 5"},{"comment":"The supervision target y_u = u/T_ep is a clock, not a semantic measure of task progress. In-distribution the monitor can fit this label using the step index or any time-correlated visual feature, so the raw ratio degeneracy of Comment 1 is not a mere theoretical concern. The mirrored-sequence experiment in Fig. 6 shows only that contradictory labels prevent fitting; it does not show that, on the actual tasks, the monitor's output responds to genuine lack of advancement, such as repeated unsuccessful grasps, object slip, or a frozen scene. Without an out-of-distribution test of the monitor's progress response, the claimed progress-aware property is not established.","section":"§3.5, Eq. (12), and §4.4 mirrored-sequence diagnostic"},{"comment":"The empirical claims are statistically fragile and partially overstated. On LIBERO the average success is unchanged (97.25 vs 97.25), and on RoboTwin the overall gains are 1.18 (clean) and 0.28 (randomized) points with no confidence intervals or significance tests reported. Real-robot numbers are 30 trials per task: for example, pick-and-place 93.3% vs 96.7% is one trial, and pack-hand-cream 50.0% vs 63.3% is four trials. The headline reductions are based on one task each. The claim that TempoWAM consistently improves the efficiency-success trade-off is stronger than the presented evidence.","section":"§4.2–4.3, Tables 1, 3, 5"},{"comment":"The cross-backbone plug-and-play experiment with Motus is under-specified. The RPM is trained on demonstration trajectories of the backbone WAM, but no information is given about whether Motus demonstrations or action distributions were used, how the action encoder handles a different action space, or how many trials the two Motus tasks use. Since plug-and-play transfer is one of the three advertised properties, this experiment needs a precise protocol before it can support the claim.","section":"§4.1 and Table 4"}],"minor_comments":[{"comment":"The floor term 0.2/T_ep is introduced without motivation or sensitivity analysis, and its effect near task completion is never studied.","section":"§3.4, Eq. (6)"},{"comment":"The column headers ('Motus SR (%)↑' and 'TempoWAM SR (%)↑') are unclear; the table should separate clean and random settings for each method.","section":"Table 4"},{"comment":"The text mentions DEHP without a citation; please add the reference.","section":"Related Work"},{"comment":"The notation u_t is used in Eq. (6) but is only defined in prose before the equation; it should be stated explicitly before the equation appears.","section":"§3.4"},{"comment":"Both figures would benefit from axis labels and error bars: Fig. 5 reports episode-level means without variance, and Fig. 6 does not define the plotted quantity on the vertical axis.","section":"Figures 5 and 6"}],"recommendation":"reject","confidential_remarks":"The main reason for rejection is the degenerate decision rule: with time-based labels, the raw progress-rate ratio is ≈1 by construction, so the adaptive behavior is produced by calibration and success feedback, not by an independent progress signal. The empirical results are modest and not statistically supported. If the authors can introduce a non-degenerate progress signal and provide an ablation that isolates it from the success-gated controller, a resubmission could be reconsidered."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe thing to know: this is a well-executed study of a real problem, but the central claim is not supported. The authors train a progress monitor on normalized time labels u/T_ep, then compare a current progress rate to a required rate derived from the same monitor. When the monitor is accurate, both rates are 1/T_ep, so the raw ratio is 1 at every decision step. Adaptive behavior then has to come from the calibration factors, and the only term that carries success information is the cross-episode, success-gated update of delta-prime. The paper's own Table 7 shows delta-prime relaxing on already-solved tasks and tightening on below-target tasks. That is a success-feedback controller, not a progress signal.\n\nCredit where earned: the problem is genuine. Fixed chunk horizons waste computation on easy stages and fail on hard stages. The plug-and-play framing is clean, the monitor is cheap, and the experiments are unusually broad: LIBERO, RoboTwin, a real robot, and a second backbone without retraining. They compare two adaptive baselines, report calls and steps alongside success, include a cost analysis, and ablate the losses. The mirrored-sequence diagnostic is a thoughtful self-check, even if it does not prove what they claim: failing to fit palindromic labels does not show that the monitor on normal tasks tracks task advancement rather than elapsed time or a visual proxy.\n\nSoft spots, in order. First, the circularity is load-bearing. The reported gains on hard tasks -- open_microwave 53 to 83, pack hand cream 50 to 63.3 -- are plausibly produced by the success-gated update. To fix this, the authors need an experiment with delta-prime held fixed, or a comparison against a time-indexed monitor with the same calibration. Second, the real-robot evidence is thin: 30 trials per task, no error bars. Third, no code or data is released, so the calibration behavior cannot be audited independently. These are serious enough to prevent acceptance as is.\n\nWho is this for? Researchers working on action chunking, adaptive execution, and WAM deployment. A serious referee should engage with it; it deserves revision, not desk rejection. My recommendation: send it to review, with the clear expectation that the authors must demonstrate that the progress estimate is not merely a time index and that the success-gated calibration is not the primary cause of the reported gains.","headline":"A clean plug-and-play execution scheme whose central progress-signal claim is undone by a decision rule that collapses into success-gated calibration.","tokens_in":12467,"tokens_out":3930,"would_cite":false,"duration_ms":44783,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper proposes TempoWAM, a plug-and-play execution layer that decides when to replan a world action model from estimated task progress instead of a fixed step count.","keywords":["adaptive execution","world action model","task progress estimation","replanning","action chunking","robot manipulation","recurrent progress monitor","efficiency-success trade-off"],"falsifier":"Run TempoWAM on a task that is visually periodic or contains repeated states at different true progress values, with a ground-truth progress detector; if the monitor reports high progress while the manipulation has not advanced, or replan decisions ignore true progress, the time-based supervision is not carrying genuine progress information. Alternatively, reproduce the paper's mirrored-sequence test on a normal task and show that the monitor still fits the labels, which would indicate it is reading the step index rather than visual state.","tokens_in":11174,"feed_emoji":"🤖","tokens_out":8797,"duration_ms":84179,"temperature":0.7,"pith_summary":"World Action Models generate a chunk of future actions, and a robot normally executes a fixed number of them before calling the model again. TempoWAM argues that a fixed execution horizon is a poor match for execution dynamics, because a chunk can stay reliable through easy stages but degrade quickly in hard ones. It replaces the fixed rule with a learned Recurrent Progress Monitor that estimates how much of the task would be completed if the remaining actions were executed, and an Adaptive Execution Protocol that replans whenever the estimated progress rate falls below the rate needed to finish. If the method works, chunk-based robot policies become more efficient and more successful without retraining the policy itself. The paper reports gains on LIBERO, RoboTwin, and a real dual-arm platform, including a 26.9% reduction in model calls on easy real-robot tasks and a 13.3-point success increase on difficult ones, and includes a diagnostic showing the time-based progress labels are valid only when the task is progress-monotonic.","feed_headline":"Replan when progress stalls, not by fixed step counts","feed_subtitle":"TempoWAM cuts easy-task WAM calls 26.9% and raises hard-task success by 13.3 points without retraining.","key_machinery":"The carrying object is the pair of a Recurrent Progress Monitor (RPM) and an Adaptive Execution Protocol (AEP). RPM is a lightweight GRU-based network that fuses frozen visual features of the base WAM, a recurrent encoding of the candidate action prefix, the previous progress estimate, and the task instruction to predict the progress that executing the prefix would reach. AEP turns that estimate into a decision by comparing progress per step to the per-step rate required to finish the task, then applies a calibration factor $\\kappa$ that is fit offline per task and adapted online by an intra-episode EMA and an inter-episode success-gated update; execution continues when the calibrated ratio is at least 1 and replans otherwise.","core_discovery":"The central claim is that the right time to replan a world action model is when the remaining action chunk stops advancing the task, and that this can be detected online. TempoWAM implements this as an execution-layer add-on: the monitor takes the current observation, task instruction, remaining actions, and execution history to predict the progress $v_t \\in [0,1]$ that would be reached by the candidate prefix, and the protocol compares the observed progress rate $\\rho^{\\mathrm{cur}}_t = (v_t - v_{t-1})/n_t$ to a required rate $\\rho^{\\mathrm{need}}_t = \\max((1-v_{t-1})/\\max(\\bar{T}_{\\mathrm{ep}} - u_t, n_t), 0.2/\\bar{T}_{\\mathrm{ep}})$. A scale-free ratio $\\tilde{r}_t = \\rho^{\\mathrm{cur}}_t / \\rho^{\\mathrm{need}}_t$, divided by a per-task calibration factor with online adaptation, decides between continued execution and replanning. The paper shows that on LIBERO, RoboTwin, and real-robot tasks this consistently improves the efficiency-success trade-off against fixed horizons, that simply shortening the horizon does not reproduce the gains, and that the same monitor transfers to a second WAM backbone without retraining.","pith_inferences":["The boundary condition the paper identifies implies that applying TempoWAM to periodic or visually aliased tasks would require phase-based or semantic progress labels, since time-based labels would be contradictory.","A direct extension is to apply the same progress-ratio gate to non-WAM chunked policies, such as plain action-chunking transformer policies; if gains persist, the mechanism is a general execution-layer property rather than a world-model-specific one.","The success-gated inter-episode update is effectively a controller that trades success for efficiency by moving a single threshold; setting the target success rate per deployment could place a robot at any chosen point on the efficiency-success frontier.","The paper's mirrored-sequence diagnostic can be turned into a screening test: before deploying TempoWAM on a new task, train the monitor on time-flipped demonstrations and check that predictions become uncorrelated with labels, to verify the task is progress-monotonic."],"forward_implications":["On tasks where chunks stay reliable, TempoWAM extends chunk reuse and reduces WAM inference calls without hurting success; on tasks where chunks degrade, it replans earlier and improves success.","A fixed shorter horizon, such as replanning every 12 steps instead of 24 on RoboTwin, does not match the improvement, so the gain comes from the timing of replanning rather than from replanning more often.","Because the monitor is trained only on demonstrations and uses the WAM's frozen visual features, the scheme is plug-and-play and transfers to a different WAM backbone with no retraining.","The monitor adds 3.54% of one optimized WAM call per decision with visual encoding, and 0.34% when reusing shared features, so the decision rule is cheap relative to the calls it saves or triggers."],"supporting_citations":[{"why":"Provides the frozen FastWAM backbone whose chunks TempoWAM executes and whose visual features the monitor reuses.","marker":"Yuan et al. 2026"},{"why":"Provides the RoboTwin 2.0 simulation benchmark that supplies the 50 tasks for the main simulation evaluation.","marker":"Chen et al. 2025"},{"why":"Provides the LIBERO benchmark and its four suites used to evaluate success and call reduction.","marker":"Liu et al. 2023"},{"why":"The second WAM backbone used to test plug-and-play transfer of TempoWAM without retraining.","marker":"Bi et al. 2026"},{"why":"Auto-Horizon adaptive execution baseline that reads predictive limit from action self-attention; TempoWAM must beat it on calls and success.","marker":"Wang et al. 2026a"},{"why":"AAC adaptive action chunking baseline based on action entropy; the comparison shows entropy-based replanning does not match progress-based decisions.","marker":"Liang et al. 2026"}],"fun_headline_variants":["Replan when task progress stalls, not on step counts","Adaptive WAM execution: 26.9% fewer inferences on easy tasks","Progress-based replanning improves WAM success by 13.3 points","Know when to replan: monitor progress, not steps"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the time-based progress label $y_u = u/T_{\\mathrm{ep}}$ is a valid measure of task advancement, so the monitor learns genuine progress rather than a step index or elapsed-time proxy, and that comparing the monitor's own progress rate to a required rate gives an independent signal for replanning.","fun_headline_variants_meta":{"raw":{"variants":["Replan when task progress stalls, not on step counts","Adaptive WAM execution: 26.9% fewer inferences on easy tasks","Progress-based replanning improves WAM success by 13.3 points","Know when to replan: monitor progress, not steps"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000432,"raw_usage":{"total_tokens":2251,"prompt_tokens":1042,"completion_tokens":1209,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":658,"completion_tokens_details":{"reasoning_tokens":1133}},"tokens_in":658,"tokens_out":1209,"duration_ms":11662,"temperature":1.0,"reasoning_tokens":1133,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T16:25:41.505123+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run TempoWAM on a task that is visually periodic or contains repeated states at different true progress values, with a ground-truth progress detector; if the monitor reports high progress while the manipulation has not advanced, or replan decisions ignore true progress, the time-based supervision is not carrying genuine progress information. Alternatively, reproduce the paper's mirrored-sequence test on a normal task and show that the monitor still fits the labels, which would indicate it is reading the step index rather than visual state.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"AAC adaptive action chunking baseline based on action entropy; the comparison shows entropy-based replanning does not match progress-based decisions."}],"review_version":1}