TL;DR for operators
A robot’s current camera view may show what it is doing without revealing how much of its assigned task it has completed. In a paired evaluation of five frozen progress reward models, supplying the correct active-subtask context reduced mean absolute progress error by 77–82%. The improvement occurred on 93.3% of annotated subtask intervals. These results come from manually supplied context, not autonomous inference.1
The proposed autonomous system, ProgressCompass, instead identifies task context, scores local progress, verifies completion, and maintains a record of completed steps. It reduces its frozen RoboMeter-4B backbone’s error from approximately 25.4 to 9.3, a 63% reduction.
For robotics operators and system architects, the result supports evaluating context management and verified state transitions before assuming the scoring model must be retrained. The evidence concerns offline progress estimation, however, not demonstrated improvements in robot-control success. Additional model calls also create inference costs that the study does not establish for production environments.
A camera can recognize an action without knowing its place in the task
Consider a robot repeatedly moving objects through a prescribed sequence. Its camera captures each movement, but a particular arrangement of objects may appear more than once. The same visible action could indicate that the robot has just started, is completing a later repetition, or has returned to an earlier configuration.
A monitoring system must distinguish these possibilities to report meaningful overall progress.
A progress reward model (PRM) estimates task completion from observed execution. Such models can recognize local visual activity yet assign an incorrect global completion percentage if the relevant history is missing or misinterpreted.
The central problem is therefore not simply whether enough visual observations are available. It is whether the system extracts the specific historical information needed to interpret the current frame.
For an operations team relying on automated progress reports, confusing those two capabilities can produce premature completion records, incorrect workflow advancement, or misleading estimates of work remaining.
Five frozen models improve sharply when given the correct subtask
The researchers construct ContextProgress-Bench from 24 manually selected robotic manipulation tasks, with five execution episodes per task. The resulting dataset contains 120 videos, 71,708 frames, and 552 annotated subtask intervals.
Their principal diagnostic experiment evaluates five PRMs on the same annotated intervals under different contextual conditions.
| Progress reward model | Without context MAE | Oracle-context MAE | Self-chained context MAE |
|---|---|---|---|
| ProgressLM | 17.95 | 4.18 | 16.70 |
| Robo-Dopamine | 15.59 | 3.43 | 4.66 |
| RoboMeter | 25.42 | 4.91 | 11.39 |
| TOPReward | 30.95 | 6.70 | 9.42 |
| VLAC | 24.43 | 4.50 | 17.13 |
Source: Section 3.1, Table 1. MAE measures average absolute progress error on a 0–100 scale; lower is better. Oracle context uses manually specified active-subtask information and correct global positioning. Self-chained estimates instead use the model’s previous subtask endpoint.
The oracle-context condition reduces MAE by 77–82% across all five models. Importantly, the underlying model parameters remain frozen.
The self-chained results expose a second problem. Even when a model can score a subtask accurately, an incorrect estimate of where that subtask begins can propagate through subsequent progress calculations.
ProgressLM illustrates the consequence: its oracle-context MAE is 4.18, but its self-chained error remains 16.70. Accurate local scoring does not guarantee accurate cumulative progress.
These paired experiments strongly suggest that contextual positioning accounts for substantial error. They do not perfectly isolate a single textual-context intervention: Appendix C documents model-specific differences in some frame-sampling and inference configurations. The results are best interpreted as controlled diagnostic comparisons under the paper’s evaluation protocol.
Three different historical facts can change the meaning of a frame
The benchmark identifies three forms of context dependence.
State Recall occurs when progress depends on a previously observed condition that is no longer visible. The monitor must recover the relevant historical state to interpret what is happening now.
Sequence Tracking concerns the active position within an ordered procedure. A visually recognizable operation may have different implications depending on which earlier steps have been completed.
Recurrence Disambiguation arises when similar actions repeat. A model must distinguish the first occurrence from later repetitions rather than assigning identical progress to visually similar frames.
These categories explain why simply supplying more historical frames does not necessarily resolve the problem. Historical information must be selected and interpreted relative to the instruction and the current task position.
The paper’s theoretical analysis formalizes this ambiguity. When identical current observations can correspond to different true progress states, an estimator restricted to the current observation faces an irreducible error floor.
For an ordered task with equally weighted steps, global progress depends on both the number of completed steps and completion within the active step. ProgressCompass’s corresponding error bound separates task-position error from local progress-estimation error.
The theory provides a conditional advantage when both errors are sufficiently controlled. It does not establish that every model with unrestricted access to full observation history must suffer the same error floor.
ProgressCompass moves context identification outside the reward model
The oracle experiment supplies the correct active step and boundaries. A deployed monitor would have to identify these itself.
ProgressCompass addresses that requirement through four cooperating components:
| Component | Responsibility |
|---|---|
| Orienter | Identifies the active subtask and specifies the expected observable transition |
| Frozen PRM | Estimates local progress within the identified subtask |
| Verifier | Checks whether the proposed completion transition actually occurred |
| Navigator | Maintains the task plan and advances the recorded position only after verification |
The implementation uses Qwen3.5-27B for orientation, Qwen3.5-9B for verification and navigation, and RoboMeter-4B as the frozen progress scorer.
When the PRM proposes that a subtask is complete, the Verifier checks the observed evidence against the expected transition. The Navigator records completion only after acceptance.
This prevents a high local progress score from automatically becoming a durable claim that the workflow has advanced.
On the benchmark, the autonomous system lowers RoboMeter’s MAE from approximately 25.4 to 9.3 and raises Spearman correlation between predicted progress and execution time from 0.53 to 0.93. It closes approximately 78% of the gap between standalone RoboMeter and oracle-context performance.
The remaining gap is informative: the autonomous system must estimate the task decomposition, active position, and completion boundaries that the diagnostic experiment supplies manually.
Explicit transitions make verification consequential
The study’s expected-transition ablation tests whether describing the anticipated observable change helps the system verify completion.
Removing that information from the Verifier increases subtask-end error from 8.6 to 17.2 and overall MAE from 9.3 to 17.5. Episodes stalled with an unverified subtask rise from 7 to 40. Removing expected-transition information from both Orienter and Verifier raises overall MAE further to 18.3, with 45 stalled episodes.
This ablation supports a specific architectural choice: verification benefits from checking an explicit predicted outcome, not simply asking whether a task appears complete.
The paper also evaluates 15 held-out negative executions involving early stopping, extra steps, and instruction-execution mismatch. On early-stop cases, ProgressCompass records mean deviation of 7.3, compared with 32.7 for RoboMeter and 50.3 for TOPReward. For unrelated instructions, it maintains zero progress. These tests support instruction-consistent monitoring under constructed deviations, but do not characterize the full range of operational failures.
A separate scheduling experiment reduces average processing time per episode from 114.7 to 39.5 seconds, with estimation metrics unchanged within reported bootstrap intervals. That improvement comes from processing independent episodes concurrently; it does not remove the sequential dependencies within an individual episode.
The deployment decision concerns state management as much as scoring
Cognaptus interpretation: For a robotics engineering team monitoring repetitive, multistep manipulation, the findings suggest testing whether inaccurate progress reports originate in local visual scoring or in incorrect task-state identification before investing in model retraining.
A plausible architecture would maintain the active instruction, relevant historical facts, expected completion evidence, and a verified record of completed steps. An uncertain completion proposal would trigger verification or human review rather than immediately advancing the recorded task state.
This interpretation extends beyond the directly demonstrated experiments. ProgressCompass was evaluated on prerecorded trajectories from deliberately selected context-dependent tasks, not through closed-loop control of deployed industrial robots. The study does not establish whether better progress estimates improve robot success rates, production throughput, or safety.
There are also operational tradeoffs. The Verifier is itself a vision-language model and can make mistakes. Additional orientation and verification calls increase computational demand, while the reported concurrency improvement does not establish the cost or latency of a live, sequential monitoring loop.
A production evaluation would therefore need to measure incorrect state advances, missed completions, recovery after verification failures, human-intervention rates, end-to-end latency, and total inference cost under the actual workflow distribution.
Better progress estimates require an accountable task state
ProgressCompass demonstrates that a substantial share of robotic progress-estimation error can arise from missing or incorrectly maintained task context, even when an existing model can score local activity.
The result is consequential for system design: a stronger scorer cannot, by itself, establish which earlier steps actually occurred. Context identification, completion verification, and durable state updates deserve evaluation as distinct responsibilities.
The paper provides substantial offline evidence for that separation. Whether it delivers reliable and economical improvements in physical robotic operations remains the next question.
Cognaptus: Automate the Present, Incubate the Future.
-
Jianshu Zhang and Keliang Wu and Chengxuan Qian and Xiyuan Yang and Ce Zhang and Ariel Tian and Anbang Liu and Haoran Lu and Han Liu (2026). ProgressCompass: Embodied Progress Reward Models Are Lost Without the Right Context. arXiv:2609.36684. https://arxiv.org/abs/2609.36684 ↩︎